Проверка на RecId

все еще хуже: max (enum) -> 250

[Alks]

Цитата:

Изначально опубликовано mazzy

Нет, уж!
Огромное спасибо за вопросы!

Побольше бы таких неожиданных и интересных.

Вот вот! Мне тоже понравилось какая ниточка распуталась из простого вопроса. Если не ошибаюсь где то тут видел раздел "глюки и фичи аксапты", куда предлагали складывать подобные замечательные замечательности, из-за которых начинающие программисты рано седеют. (там что то было про глюк при извлечении из контейнера по три штуки в цикле было, сейчас не смог найти).
Как раз материальчик для того раздела.

[Alks]

Всё таки нашел тот топик и еще раз заценил тот глюк с контейнером.
Решил расследовать причины такого странного поведения контейнера и написал следующий Job:
(крайне рекомендуется запустить и насладится результатом всем, кто пользовался или собирается пользоваться ф-ей conDel)

PHP код:

static void Job5(Args _args)
{
    int k; // длина контейнера
    int d; // число элементов для удаления "за раз"
    int i, s;
    container con;
    void checkContainer()
    {
        con = conNull();
        for ( i = 1; i <= k; i++ )
            con += i;
        s = k mod d;
        for ( i = 1; i <= k div d; i++ )
            con = conDel( con, 1, d );
        if ( conLen( con ) != s )
        {
            info( "нач. длина " + int2str( k ) + "; удаляем по " + int2str( d ) + " эл. за раз в цикле " + int2str( k div d ) + " итераций; " +
                  "в конце должно статься " + int2str( s ) + " эл.; реально осталось " + int2str( conLen( con ) ) + " эл.!" );
        }
    }
    ;

    for ( k = 1; k <= 100; k++ )
    {
        for ( d = 1; d <= k; d++ )
        {
            checkContainer();
        }
    }
} 


Результаты ошеломляют.
Особенно рекомендую посмотреть нижнюю часть инфолога.
Причина видимо кроется в том, что контейнеры как и любая нормальная динамическая структура выделяет память под свои элементы если в нём не хватает места не по одному элементу, а порциями. Как видно в X++ начальное значение этой порции равно 50 элементов, именно с этого количества элементов в контейнере начинаются страшные глюки. Соответственно в любом контейнере хранятся два параметра - n - реальное число элементов в массиве и m - число элементов под которое выделена память. m может быть больше или равно n.
Так вот такое ощущение что conDel в каком то месте ошибочно вместо n обращается к m или наоборот!

[Yury]

real a = -257;
boolean b = a;
;
info(strfmt("%1", b));

if (b)
{
info("все-таки true");
}

[Logger]

static void TestEnum(Args _args)
{
int i, i2;
real r, r2;
real a = -257;
boolean b;// = a;
//NoYes b;// = a;
;
b = a;
info(strfmt("b = %1", b));
// проверяем что же реально хранится в переменной b и видим что там
// лежит 255, которое расценивается как true в условии if, но !
// которое strFMT не умеет преобразовывать в строку "Да" или в строку "Нет"
i = b;
r = b;

b = true; // а здесь уже будет лежать единичка
info(strfmt("b = %1", b));
i2 = b; // так что strFMT отработает нормально
r2 = b;
info(strFMT('реальное содержимое при копировании в int %1 ; %2 ', i, i2));
info(strFMT('реальное содержимое при копировании в real %1 ; %2 ', r, r2));

}

А все из-за того что фактически вместо boolean используется shortint и при присваивании происходит простое копирование в памяти без проверки типов.

[kashperuk]

Ну, похоже, что проблемы с преобразованием int в boolean решили между 3.0 и 2009.

[Logger]

Цитата:

Сообщение от kashperuk

Ну, похоже, что проблемы с преобразованием int в boolean решили между 3.0 и 2009.

В каком-то из KR пофиксили.

[db]

Взял свой же джоб из предыдущих сообщений на 3.0 KR2 все ок. Более свежих версий под рукой сейчас нет, проверьте у кого есть - не раз были случаи что исправленное ранее всплывало снова и снова.

А вообще в очередной раз "порадовала" скорость исправления. Признав ошибку критической правили полтора года и то после неоднократных повторных пинаний

[Logger]

Цитата:

Сообщение от db

Взял свой же джоб из предыдущих сообщений на 3.0 KR2 все ок. Более свежих версий под рукой сейчас нет, проверьте у кого есть - не раз были случаи что исправленное ранее всплывало снова и снова.

Если вы про job9 Проверка на RecId

то у меня он выдал 4 раза "ok", как я понимаю, это означает что бага исправлена.
Ax KR3 (build 7609)

"все ок." - вы имели в виду что бага исправлена ? Или что джоб продолжает ругаться ?

[db]

исправлена