Показать сообщение отдельно
Старый 11.12.2013, 00:20   #15  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от ta_and Посмотреть сообщение
Я от системы ожидаю адекватного поведения на мои ошибки.
У любой системы есть способы ее использования, на которые она рассчитана, и способы, на которые она не рассчитана. Enumerator'ы коллекций не рассчитаны на то, что по ходу работы с ними коллекция будет изменяться. Под отладчиком видно, что изменение коллекции приводит к тому, что enumerator начинает ссылаться на "левый" кусок памяти (в отладчике виден мусор вместо текущего значения). Т.е. изменение коллекции "сбивает" некий указатель, который используется enumerator'ом, и в следующий раз он обращается к области памяти, которая не имеет к коллекции никакого отношения. Я лично подозреваю, что "дураконезащищенность" enumerator'ов была реализована намеренно для повышения производительности их работы. Про эту их особенность просто надо знать - подобно тому, как надо знать про особенности клиент-серверного взаимодействия и то, что некоторые вызовы обрабатываются локально, а некоторые - путешествуют по сети до другого компа и обратно.
Цитата:
Сообщение от ta_and Посмотреть сообщение
В приведенной документации (кстати по 2012) закономерно говорится, что в таких случаях будет выдано исключение.
В приведенной документации говорится, что CLR изначально не позволяла менять коллекцию при одновременной работе с enumerator'ом, и из-за этого в AX 2012 внесли аналогичные изменения в ядро, чтобы коллекции вели себя одинаково при выполнении кода Х++ как в интерпретаторе, так и в CIL. Никто там не говорит, что всем надоели программистские ошибки, и поэтому работу с enumerator'ами ужесточили.
Цитата:
Сообщение от ta_and Посмотреть сообщение
А если эта хрень написана в 900 строках кода с вызовами разных побочных методов и дополнительных циклов, то искать эту ошибку очень весело.
В стандартном приложении той же 2009-й такой "хрени" просто нет: там либо используется enumerator, и коллекция внутри цикла работы с ним не меняется, либо используется iterator, и коллекция внутри цикла работы с ним может меняться, а может и не меняться (часть совсем legacy-кода, видать, написана, когда enumerator'ов в ядре еще не было).
За это сообщение автора поблагодарили: mazzy (2), Link (4).