bug в ax3kr3 confind

[SHiSHok]

Рбнаружил в KR3 такой очень неприятный баг: если в контейнере содержится пустое строковое, то confind при поиске значения отсутствующего в контейнере выдает позицию пустой строки!
как с таким багом люди на KR3 работают (или я может чего то не знаю)? в каком релизе все нормально работает?

static void Job167(Args _args)
{
    container   c = [3,5,"","",8];
    int         i;
;
    i = confind(c,2);   // found 3  bug!
    i = confind(c,3);
    i = confind(c,4);  // found 3  bug!
    i = confind(c,5);
}

[Bishop]

В AX 4.0 SP2 уже исправлено.
Проверил у себя на AX 3.0 KR3 - действительно работает некорректно!
Причем, если в контейнере искомый элемент стоит дальше пустого значения, то все равно confind() возвращает индекс первого пустого значения.
Похоже, редко confind() применяли (и применяют) к контейнерам с разнотиповыми элементами...
Еще, поиск пустой строки в контейнере всегда возвращает первый нестроковый элемент... (в той же AX 3.0 KR3):
c = ["A","B",1,2,3,""]
confind(c, "") = 3

[kashperuk]

Проверил в АХ 2009. Там уже все ОК.
Честно говоря, с таким поведением немного стремно было бы работать.

Хотя, confind не такая уж и частая операция, если так подумать.

[SHiSHok]

Цитата:

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

Хотя, confind не такая уж и частая операция, если так подумать.

не сказал-бы, если посмотреть в АОТ

[SHiSHok]

свою функцию корректного поиска в контейнере то написали, но не хотелось бы таким способом исправлять ошибку.
есть идеи как минимальными затратами устранить баг?

[Владимир Максимов]

Вообще-то, с ошибкой будет искать и собственно пустую строку

i = confind(c,"");   // found 1  bug!

Напрашивающийся вариант решения - это сравнение базовых типов. Того значения, которое ищем и того, которое нашли.

Другой вариант - вместо пустой строки записывать некий спец.символ. Например, num2char(1). Как ни странно, но num2char(0) ведет себя также как и пустая строка.

Да, кстати, в AX2.5 этого глюка не было.

==========================================
Ну, и еще один вариант поиска, правда, не для всех типов данных

print strScan(","+con2str(c)+",",strFmt(",%1,",2),1,1000);
print strScan(","+con2str(c)+",",strFmt(",%1,",3),1,1000);
print strScan(","+con2str(c)+",",strFmt(",%1,",""),1,1000);
pause;

[gl00mie]

Цитата:

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

есть идеи как минимальными затратами устранить баг?

Откажитесь от хранения в контейнере данных, по которым вы осуществляете поиск Вообще, много раз уже с этими контейнерами возникали косяки, я лично, если нужно что-то куда-то "складывать" по ходу работы и потом это искать/доставать, использую Set или Map.

[SHiSHok]

Цитата:

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

Откажитесь от хранения в контейнере данных, по которым вы осуществляете поиск

быстрый анализ показал : контейнер используют (c confind) порядка 170 объектов (среди них \Classes\ClassFactory , \Classes\Queue , \Classes\NumberSeqReference , и еще много интересных обьектов).
Т.о. можно сказать что под вопросом функционирование всего приложения в KR2,3.
Как я понимаю, линейка версии 3 больше не поддерживается и не фиксится?

Цитата:

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

если нужно что-то куда-то "складывать" по ходу работы и потом это искать/доставать, использую Set или Map.

а может и они уже неправильно работают

[Bishop]

Цитата:

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

Откажитесь от хранения в контейнере данных, по которым вы осуществляете поиск Вообще, много раз уже с этими контейнерами возникали косяки, я лично, если нужно что-то куда-то "складывать" по ходу работы и потом это искать/доставать, использую Set или Map.

Есть случаи, когда Set и Map не подходят, в отличие от контейнера:
1) требуется хранить разнотиповые значения (это можно обойти использованием в качестве ключа тех же контейнеров);
2) требуется хранить повторяющиеся элементы;
3) требуется хранить значения в порядке поступления, а не в сортированном виде;
Ну, и еще, контейнеры удобнее передавать между классами и просматривать их содержимое в дебаггере.

Цитата:

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

быстрый анализ показал : контейнер используют (c confind) порядка 170 объектов (среди них \Classes\ClassFactory , \Classes\Queue , \Classes\NumberSeqReference , и еще много интересных обьектов).
Т.о. можно сказать что под вопросом функционирование всего приложения в KR2,3.

Данная ошибка в AX 3.0 KR3 confind() возникает только при наличии в контейнере разнотиповых данных.
Если вы найдете в стандартной аксапте место применения confind() к контейнеру, потенциально содержащему разные типы, тогда можно ставить под вопрос...
Думаю, что не найдете

[SHiSHok]

Цитата:

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

Данная ошибка в AX 3.0 KR3 confind() возникает только при наличии в контейнере разнотиповых данных.

пока мы тоже к этому выводу пришли. но не только когда в контейнере разнотиповые данные, а при работе с разными типами при помощи контейнера. т.е. вариант confind([3,5,0,0,8],''); неправильно работает.

Цитата:

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

Если вы найдете в стандартной аксапте место применения confind() к контейнеру, потенциально содержащему разные типы, тогда можно ставить под вопрос...
Думаю, что не найдете

раз у народа работает KR3 и никто до сих пор этого глюка не заметили, то надеюсь что не найду. А вот в функционале наших поставщиков этих контейнеров... очень любили они их (собственно там и напоролся).

[gl00mie]

Цитата:

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

Есть случаи, когда Set и Map не подходят, в отличие от контейнера:
1) требуется хранить разнотиповые значения (это можно обойти использованием в качестве ключа тех же контейнеров);

Я отдельно упомянул, что рассматривается вариант, когда требуется искать в "накопленных" данных. Слабо представляю ситуацию, когда требуется искать среди разнотипных значений.

Цитата:

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

2) требуется хранить повторяющиеся элементы;
3) требуется хранить значения в порядке поступления, а не в сортированном виде;

List

Цитата:

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

Ну, и еще, контейнеры удобнее передавать между классами и просматривать их содержимое в дебаггере.

Заметьте, что контейнеры передаются по значению, в связи с чем их удобно передавать между уровнями (клиентом и сервером), в то время как на одном уровне их передача порождает лишние накладные расходы. А для отладки можно и классы-коллекции запаковать в контейнер, благо это не так часто нужно.

[Logger]

Интересно, а имеет смысл требовать хотфикса для этого глюка или из-за окончания поддержки трешки это бессмысленно ? Если не ошибаюсь гарантировался выпуск фиксов только для критичных багов.

[Bishop]

Цитата:

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

Я отдельно упомянул, что рассматривается вариант, когда требуется искать в "накопленных" данных. Слабо представляю ситуацию, когда требуется искать среди разнотипных значений.

Я лишь намекнул, что обсуждаемый здесь глюк в confind() как раз выявлен в ситуации использования контейнера с "ассорти". И совет отказаться от контейнеров в пользу Map или Set при поиске данных некорректен для данного случая.
Я сам слабо представляю такую ситуацию. И то, что это выявлено (по крайней мере, на axforum) в конце 2009 года, говорит само за себя.

[kashperuk]

Цитата:

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

Интересно, а имеет смысл требовать хотфикса для этого глюка или из-за окончания поддержки трешки это бессмысленно ? Если не ошибаюсь гарантировался выпуск фиксов только для критичных багов.

Я думаю, что шансов его получить - очень мало.
В будущее мы смотрим, назад не оглядываемся

[SHiSHok]

Цитата:

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

Я думаю, что шансов его получить - очень мало.
В будущее мы смотрим, назад не оглядываемся

Баг я бы сказал критичный и многие клиенты еще долго будут на 3-й версии работать. Но, учитывая как из мелкософта тяжело все выбивается, думаю что финал 3й версии останется с дыркой