Здравствуйте, vdimas, Вы писали:

V>Возьми рефлектор и подсчитай кол-во наследников IEnumerable<T> и IEnumerable в публичных классах фреймворка, которые при этом не реализуют ICollection?. Там всего десяток (ДЕСЯТОК!!!) таких классов на 16 загруженных в рефлектор основных фреймворковых либ со многими тысячами классов.

А библиотеки FW 2 вообще очень слабо заточены под программирование с использованием итераторов и лямбд. Но даже это особенно не мешает получать преимущество от их использования.

V>Ну а теперь открой наследников ICollection (ICollection<T>)...

В библиотеках FW2 вообще много странностей — вроде всяких GetDirectories, которые возвращают массив строк. Зачем на них равняться?

V>Всё ясно, малость поторопился отвечать, не вникнув в сказанное и не проверив лично...

Самокритично.

V>Не, ну действительно, сколько мест в проекте, где реально требуются ленивые вычисления списков?

Разумеется, с точки зрения человека, который не умеет пользоваться X, мест в проекте, где требуется X равно нулю.

V>Для таких обычных сценариев просто пишут i=i+1 (или i=func(i) в том месте, где данные обрабатываются, а не тот наворот что ты представил вокруг банального i=i+1, и всё это с целью инжектить обработку данных в их источник.

"Наворот" был представлен в таком виде, чтобы его легче было понять — как оказалось напрасно.

V>Принципиальное отличие ICollection — в св-ве Count, что позволяет избегать Log2(N) перераспределений памяти, имелась ввиду именно эта эффективность.

Принципиальное отличие IEnumerable в том, что память можно вовсе не перераспределять.

V>Ну это же свинство городить такой огород из 2-х объектов (реально) и 2-х делегатов ради банального маппинга.

Это в языке без данных средств придется все это городить вручную. Особенности реализации к выразительности языка никакого отношения не имеют.

V>Маппинг должен выглядеть так a = map(b);

Маппинг так выглядеть не должен. Где само отображение, а?

V>В С++/CLI я могу оперировать как дотнетными делегатами, так непосредственно ф-иями, последнее увеличивает быстродействие в разы именно на алгоритмах обработки большого кол-ва данных (скажем, в области обработки сигналов).

Особенности реализации делегатов к выразительности языка не имеют отношения. В том же Nemerle в аналогичном коде никаких делегатов не будет.

K>>Это не мой пример. В моем примере inclist это функция.
V>ну и? ф-ия, полученная путём карринга, которая возвращает объект IEnumerable, у которого надо позвать еще метод, чтобы получить другой объект — непосредственно целевой итератор... А почему не сразу целевой итератор возвращается? Не издержки ли выразительности...

Не нужно притворяться, что это просто пример в концентрированной форме представляющий выразительные средства C# отсутствующие в C++ и демонстрирующие, что C# не подмножество C++. Вы высказались поспешно, с кем не бывает. Нужно иметь мужество свою ошибку признать.

V>Аналогичное (и гораздо более широко применимое в плане типов) замыкание в С++:
V>

V>template<typename T, typename IteratorT>
V>struct MapIterator : IteratorT {
V>  typedef T FuncT(IteratorT::element_type);

V>  FuncT map;
V>  MapIterator(const IteratorT& it, FuncT f) : __super(it), map(f) {}
V>  T operator*() { return map(__super::operator*()); }
V>}

V>//tempate<typename T>
V>//T Inc(T arg) { return T+1; }

V>template<typename IteratorT>
V>MapIterator<IteratorT::element_type, IteratorT> inclist(IteratorT it)
V>{ return MapIterator<IteratorT::element_type, IteratorT>(it, _1+1); } // либо раскомментировать выше и вставить "Inc" вместо "_1+1"
V>

Отличная демонстрация разницы в выразительности, спасибо, как раз то что нужно.

K>>Я так понимаю, что мы приходим к противоречию. С одной стороны, на C++ конечно можно написать то же, что и на C#, если иметь в виду полноту языка по Тьюрингу, но тогда слова "и еще в несколько раз больше" не верны. С другой стороны, если говорить о выразительности языка нельзя игнорировать итераторы
V>итераторы на любой вкус, а учитывая возможность переопределения синтаксиса — так еще и на любой синтаксис итерирования.

Строго говоря, то что в STL — вообще не итераторы. Просто их так называют.

K>> и лямбды,
V>при условии невозможности определять в C# типы по месту — это единственный выход не превращать код в лапшу.

При условии невозможности использовать нормальные полноценные лямбды с замыканиями в C++ выход не превращать код в лапшу приходиться искать где-то в другом месте.

V>Но опять же, писать тела алгоритмов в лямбдах — так никто не делает, лямбды чаще служат для параметризации, карринга, комбинации и т.д. уже готовых алгоритмов. А вот написание этих самых алгоритмов в C# — Большая Проблема, достаточно невозможности использования банальных арифметических операций для генериков, и огромная доля алгоритмов становятся не обощаемыми.

Алгоритмы в C# как раз и обобщаются с помощью функций высшего порядка. Да, параметрический полиморфизм в C# кривой (в C++, впрочем, это вообще полиморфизм ad hoc, вроде перегрузки), из-за того, что нельзя делать реализации интерфейсов для типов, не изменяя их. Другими словами, классов типов нет. Но классы типов — это, вообще говоря, сахар — и можно их эмулировать передавая словарь класса через дополнительный дженерик-параметр. Я, в свое время, даже обобщенный солвер на C# написал с такой эмуляцией классов типов. Но понятно, что это извращение.

V>Compile-time генерация в C++ вкупе с возможностью перегрузки операторов позволяет действительно обобщать алгоритмы, и тут без реальных замеров где и кто больше выиграл рассуждать бесполезно.

Конечно бесполезно. Мы и не рассуждаем о том, кто и где больше выиграл — я никогда не утверждал, что в C# есть все, что есть в C++ — это Вы утверждали, что в C++ есть все, что есть в C# — а это очевидная неправда.

V>Смешно, однако. Сколько строчек с yield return в твоём текущем проекте?

89

V>Сколько всего строчек в проекте?

30K с пробелами и комментариями.

V>В сотнях тысяч строк сэкономили всего несколько сотен на yield return, но просрали около четверти от общего объема из-за ограниченых возможностей генериков...

В C++/CLI они ограничены в такой же степени.

V>Я когда-то делал мини-систему обработки сигналов на дотнете, так запарился со всей этой выразительностью копипейстить, плюнул и сделал на обычном С++ в несколько раз короче.

Я думаю, что C# не подходит для написания ПО обработки сигналов. Но связано это не с выразительностью языка, а с возможностями компиляторов по оптимизации.

K>>Если я, в ответ на простой вопрос, который я написал за 15 секунд, получаю пространные рассуждения о том, что это все никому не нужно,
V>В представленом виде — никому не нужно, извини. Это я тебе с позиций пользователя твоего кода.

Даже если учеть, что мой пример, как и подобает примеру — сферический конь в вакууме — утверждение о том, что ленивый map никому не нужен — достаточно смелое. Хотя конечно, тому, кто не видит смысла в ленивой обработке списков он не нужен.

K>>нужно ли это понимать так, что написать в точности то же самое на C++/CLI нельзя?
V>Мощное заявление, однако, насчёт нельзя

Это был вопрос; больше, впрочем, вопросов нет.

V>Кое-чего нет, но всё, что может C# можно сделать и в C++/CLI, некоторые конструкции требуют больше приседаний, например, замыкания в практике С++ описывают явно в виде объектов по месту вызова. Несколько лишних строк обычно, есть такое.

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

V>Вот тебе более интересная задача: есть некий серверный процесс, в нём по требованию создаётся домен и хостится некий сервис. Как всем остальным доменам процесса узнать, что сервисный домен уже существует, не пытаться создать его, и как получить MBR оного сервиса? попробуй на C#

Для меня — не интересная.

Здравствуйте, vdimas, Вы писали:

VD>>Тебе, между прочем, тоже показали, что С++ не может, что может C#.

V>Ну тогда сформулирую прямо: С++/CLI может всё что C#, но некоторые вещи за счёт оверхеда и приседаний. C# в свою очередь не имеет доступа ко всем возможностям CLR, в отличие от C++/CLR. Так пойдёт?

Старая как мир ошибка технарей. Язык ничего не может. Творить может связка человек+программист. Теоретически, hex-редактор может больше всех, но никакой человек не захочет писать в нём, поэтому реально он может меньше всех.

Здравствуйте, VladD2, Вы писали:

VE>>Я его не без толку засоряю, а выражаю свое мнение.
VD>Это тебе так кажется. А на поверку твои минусы, расставленные по всем подряд сообщениям, никакой информации окружающим не дают.
А я и не ставил целью дать людям какую-то информацию. Для этого сообщения есть.

VE>> Если мне этого делать нельзя, я не буду.
VD>Ставь сколько угодно. Только спамить ими не надо. Если уж ты не согласен с чем-то, то надо хоть изредка аргументировать свое несогласие.
Хорошо, надо так надо. Знать бы критерии, когда надо, а когда нет.

VE>>Я бы объяснял, и могу объяснить тем, кто это воспримает именно как мнение, а не как на покушение не знаю на что, с последующим спором. А уж как некоторые проводят споры, так даже перепалки "Delphi vs C++" на gamedev.ru кажется дискуссией ученых мужей.
VD>Хм. Пока что я вижу, что ты банально неумеешь обосновывать свое мнение и прикрываешься гипотетическими рассуждениями о чужой реакции.
Вот понимаешь ли, у людей разные мнения, и твое видение может расходиться с видением окружающих. Это, конечно, не значит, что твое видение неверно, но как минимум это повод задуматься.
Я, конечно, понимаю, что это банальная истина про разные мнения, но то ли ты ее не понимаешь, то ли по каким-то еще причинам хочешь мне-таки свое мнение навязать, которого я, заметь, не спрашивал.
И уж я наверное получше тебя знаю, прикрываюсь я или нет.
Забавно, что ты видишь, что я банально не умею обосновывать свое мнение.
Вот вроде бы я пока мнений своих письменно не выражал, однако выводы ты уже сделал. Наверное, по аналогии с детским лепетом типа такого:
-А ты можешь в лужу лечь?
-Могу!
-Ляг!
-Не хочу
-Аааа! Значит не можешь!

Типа раз я каждое несогласие сообщением не сопровождаю, значит, обосновать не могу.
Ну да ладно, это дело твое, что ты там видишь.

VE>>Но в любом случае, если кому-то будет интересно, почему я согласен/не согласен, может спросить.
VD>Другими словами, твое мнение пока что никому не интересно? Так? Ну, а что тогда его выпячивать?
Вот смотри. Есть система оценок, которая, как ни странно, не подразумевает непосредственного ответа сообщением. Логично, что она предназначена, чтобы выразить согласие/несогласие без написания сообщений? Вот я ее так и использую. В противном случае тут была бы кнопка "не согласиться", после нажатия на которую пришлось бы писать сообщение с обоснованием. Увы, такого нет.
Более того, ты же моим мнением поинтересовался? Значит, все-таки, интересно. Вот, поэтому я сейчас и распинаюсь. Мне было бы проще несогласиться специально предназначенным для этого средством, но тебе это, видимо, слишком не нравится.
А вот кто из нас двоих и выпячивает мнение, так точно не я. Я уж не беру в расчет другие темы, а-ля
-Смотрите, A = B!
-Ну и? Зато N > A && N > B.
-А причем тут N?
-А причем тут A и B? Почему ты тогда не посвятил свою тему проблемам с кучей C/C++

А хотя бы касательно данного обсуждения.
Ведь я твоего мнения не спрашивал. Поставил бы мне минус и все, я бы не заметил даже.
Кстати, очень прошу, не отвечай на сообщение, меня твое мнение по этому вопросу совсем не интересует, поставь минус.
Мое предыдущее сообщение так же было законченным, не требующим пояснений.
Если ты думаешь, что другим шибко интересно твое мнение о моем отношении к системе оценок RSDN, то и обращайся к другим, мол, давайте закопаем мракобеса ВойдЕкса за учиненные беспорядки.
А то получается, что ты пока потверждаешь мои слова, что выражение мнения рождает никому не нужный спор, а также противоречишь сам себе. Раз мое мнение никому не интересно, проигнорируй.

Здравствуйте, Klapaucius, Вы писали:

FR>>В питоне с помощью yield (правда он помощнее шарповского) красиво делается много вещей

K>Можно подробнее про выделенное? Желательно с примерами.
http://docs.python.org/whatsnew/pep-342.html
http://www.python.org/dev/peps/pep-0342/

Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, FR, Вы писали:

FR>>В питоне с помощью yield (правда он помощнее шарповского) красиво делается много вещей

K>Можно подробнее про выделенное? Желательно с примерами.

За счет того что питон динамический и следовательно все функции обобщенные, yield просто удобней применять например как тут:

http://www.iso.ru/journal/articles/print/155.html
http://www.iso.ru/journal/articles/189.html
http://www.iso.ru/journal/articles/print/190.html

Та же обобщеность помогает построить итераторы во многом эквивалентные основным фвп используемым в функциональных языках:

http://docs.python.org/lib/itertools-functions.html
http://docs.python.org/lib/itertools-example.html
http://www.iso.ru/journal/articles/print/284.html

Ну и начиная с python2.5 yield стал двухстороним и может передавать даные в обе стороны:

http://docs.python.org/whatsnew/pep-342.html
http://www.python.org/dev/peps/pep-0342/

Что позволяет делать всякие вкусности типа http://en.wikipedia.org/wiki/Coroutine

Здравствуйте, Кодёнок, Вы писали:


V>>Ну тогда сформулирую прямо: С++/CLI может всё что C#, но некоторые вещи за счёт оверхеда и приседаний. C# в свою очередь не имеет доступа ко всем возможностям CLR, в отличие от C++/CLR. Так пойдёт?

Кё>Старая как мир ошибка технарей. Язык ничего не может. Творить может связка человек+программист. Теоретически, hex-редактор может больше всех, но никакой человек не захочет писать в нём, поэтому реально он может меньше всех.

Ну если ты мне дашь такой hex-редактор, который позволит прикручивать аспекты и вообще производить за меня кодогенерацию для .Net малым числом строк, то я согласен. А иначе сравнение малость неккоректно. Я вполне трезво оценил потери в одном месте и выигрыш в другом, и в отличие от моих оппонентов одинаково неплохо владею обоими обсуждаемыми вещами, чтобы позволить себе сравнивать.

Это не значит, что я полностью перееду на C++/CLI, т.к. на самом деле для C# есть еще одна фича, которая весьма прибавляет ему веса — это развитый рефакторинг. Но вот писать отдельные либы для проектов на нём — запросто и аж бегом, всё-равно в итоге получаем не нативный image, а такой же точно byte-code.

Здравствуйте, Klapaucius, Вы писали:

K>Принципиальное отличие IEnumerable в том, что память можно вовсе не перераспределять.

И тем не менее именно это и происходит с при использовании банального DbDataReader.


K>Даже если учеть, что мой пример, как и подобает примеру — сферический конь в вакууме — утверждение о том, что ленивый map никому не нужен — достаточно смелое. Хотя конечно, тому, кто не видит смысла в ленивой обработке списков он не нужен.

Ну во-первых я уже говорил где-то в этой ветке, что ленивость алгоритма не обязательно должна строиться на итераторах, эти вещи слабо связаны м/у собой. А во-вторых, событийная модель — это ленивая модель или нет? И требует ли она больше памяти, чем ленивая (прозвучало тут мнение от Синклера)? И как в такой модели происходит маппинг без итераторов и тем не менее тоже без перераспределения памяти?

Вроде бы трансформация данных — вотчина ленивых алгоритмов, однако почему-то большей популярностью пользуются XML-парсеры, работающие по событийной модели, и я даже знаю — почему. Диспечеризация данных в случае ленивых алгоритмов должна быть внешней by design, отсюда неудобство практического использования. Т.е. имеем банальную диллему выбора — простота интерфейса или простота реализации.

Здравствуйте, Klapaucius, Вы писали:

Вот момент, на который сначала не хотел отвечать, но всё же. Просто иногда задалбывает этот юношеский максимализм, проскакиваеющий даже у "ветеранов" RSDN, когда они пытаются судить об образе мышления оппонентов.


V>>Не, ну действительно, сколько мест в проекте, где реально требуются ленивые вычисления списков?

K>Разумеется, с точки зрения человека, который не умеет пользоваться X, мест в проекте, где требуется X равно нулю.

1. Не ты один тут путаешь ленивые вычисления как таковые с ленивыми вычислениями списков, я обратил на это внимание и потому в исходном предложении ключевое слово выделил. Везде, где объекты создаются только по требованию — это ленивость. Создали лишь часть объекта, напр. ключ и текстовое описание для отображения в списке в GUI объектов из базы данных — это тоже ленивые вычисления. Любая современная "правильная" программа сплошь ленивая. В то же самое время ленивость — не панацея, она нужна только там, где нужна (сорри за каламбур), иначе можно получить проседание эффективности без серьезных на то причин. Но это всё банальности, они утомительны но не раздражительны. Раздражает ситуация, когда кто-то относится к банальностям серьезно, провоцируя такое же отношения к ним со стороны оппонента.

2. Говорить "списки" применительно к IEnumerable — это безграмотно само по себе. В Хаскеле, например, действительно речь идет о ленивых вычисляемых списках, когда на каждый следующий порождаемый элемент ссылается предыдущий. Это фича и одновременно ограничение языка. IEnumerable в отрыве от итерируемого объекта — это просто бесконечный (в общем случае) поток данных. И если я пояснил свою позицию (надеюсь) то теперь ответь еще раз на заданный вопрос, где речь идет именно о списках, как о связанных линейных структурах данных. (массив, ArrayList, LinkedList, Queue, Stack, кастомные какие-нить, попадающие под определение "список" — пофиг).

3. У потока есть 2 конца, я ведь тебе намекнул, что ты инжектил обработку (маппинг) в источник, но ты явно не понял намёка. Вместо того, чтобы попытаться понять сказанное, ты разразился тирадой: "ах, вы не понимаете надобность ленивого маппинга". Смешно, однако. Тем не менее, напряги фантазию и представь как будет выглядеть маппинг на противоположной стороне, стороне приёмника. А потом попытайся объяснить, где мы здесь потеряли твою ленивость и что собственно не понимает оппонент.

4. Нет у C++ этого yield, и я уже наверно с десяток раз сказал здесь, что реальная мощь yield состоит в трансформации автоматных алгоритмов в императивные. Но твой пример — далёк от того, что я понимаю под "мошью" yield, т.к сводится к копированию кода в MoveNext. На С++ можно было бы сделать маппинг на стороне приёмника в одну строчку, без заморочек с промежуточными объектами и цепочек делегатов. Но даже посмотрев на в точности аналогичный твоему вариант, ты, сознательно или нет, пропустил мимо ушей замечание, что представленный пример подходящ для огромного класса типов, в отличие от твоего варианта, который оперирует только int. ИМХО, бестолково мерить выразительность отдельно взятых строчек кода в отрыве от мест применения. Следуя твоей логике, любой генерик-тип менее выразителен, чем точно такой же обычный тип, ведь при описании генерика мы потратили больше символов исходного кода, хотя бы на те же угловые скобки и декларацию ограничений.

Здравствуйте, vdimas, Вы писали:

VD>>Просто думать об алгоритме как о чем-то что можно тупо прервать в любой точке и продложить с того же места уже не просто.

V>А как же многопоточное ПО?

А вот потому его практически никто и не пишет. Точнее то что пишут в итоге получается мало пригодным. Еденицам удается написать что-то путное.

V>Кстати да, напомнило, есть же еще технология фиберов. Небольшое (одноразовое) приседание для С++ для достижение аналогичного эффекта общающихся процессов в рамках одного потока. Блокирующий канал связи сделать с интерфейсом IEnumerator и вуа ля.

Там оверхэд такой, что ты вряд ли его захочешь поиметь. Да и это стрельба из пушки по воробъьям.

Здравствуйте, palm mute, Вы писали:

PM>Здравствуйте, Klapaucius, Вы писали:

FR>>>В питоне с помощью yield (правда он помощнее шарповского) красиво делается много вещей

K>>Можно подробнее про выделенное? Желательно с примерами.
PM>http://docs.python.org/whatsnew/pep-342.html
PM>http://www.python.org/dev/peps/pep-0342/

Если речь о возрате значений, то можно просто возвращать в итераторе ссылочный объект с изменяемыми полями.

Можно, все же более подобное объеснение приемуществ?

Здравствуйте, VladD2, Вы писали:


VD>Если речь о возрате значений, то можно просто возвращать в итераторе ссылочный объект с изменяемыми полями.

Угу и вместо замыканий тоже можно подобный же объект возвращать

VD>Можно, все же более подобное объеснение приемуществ?

Нововведения в питон 2.5 (там не только двухстороность, а что более важно полный контроль потока управления) превращают генераторы в полноценные сопрограммы.

Здравствуйте, vdimas, Вы писали:

V>Вот момент, на который сначала не хотел отвечать, но всё же. Просто иногда задалбывает этот юношеский максимализм, проскакиваеющий даже у "ветеранов" RSDN, когда они пытаются судить об образе мышления оппонентов.

Это Вы просто не в бровь а в глаз.

V>>>Не, ну действительно, сколько мест в проекте, где реально требуются ленивые вычисления списков?
K>>Разумеется, с точки зрения человека, который не умеет пользоваться X, мест в проекте, где требуется X равно нулю.

Непонятное обвинение в непонимании разницы между lazy и non strict, ликбез и трюизмы поскипаны.

V>2. Говорить "списки" применительно к IEnumerable — это безграмотно само по себе.

Я знаю. Соответственно, впервые о списках заговорили как раз Вы, задав риторический вопрос о том, что, дескать, где же они нужны? А на любой риторический вопрос "Много ль мест, где нужен X?" у меня ответ один "С точки зрения человека, который не умеет пользолваться X, число мест в проекте, где требуется X равно нулю". Раз уж я не говорил, что шарповские итераторы — это ленивые списки, то смысл всей этой тирады от меня ускользает — особенно если учесть, что о ленивых списках Вы же первым и заговорили. Действительно, семантика у них не lazy, а non strict — т.е. это действительно потоки.

V>теперь ответь еще раз на заданный вопрос, где речь идет именно о списках, как о связанных линейных структурах данных.

Какое отношение вопрос об односвязных ленивых списках имеет к обсуждению выразительности C#? Их поддержка ни в C# ни в C++ не встроена, и, как мне кажется использование таких списков это не C# way.

V>3. У потока есть 2 конца, я ведь тебе намекнул, что ты инжектил обработку (маппинг) в источник, но ты явно не понял намёка. Вместо того, чтобы попытаться понять сказанное, ты разразился тирадой: "ах, вы не понимаете надобность ленивого маппинга". Смешно, однако. Тем не менее, напряги фантазию и представь как будет выглядеть маппинг на противоположной стороне, стороне приёмника. А потом попытайся объяснить, где мы здесь потеряли твою ленивость и что собственно не понимает оппонент.

Еще раз. Какое это имеет отношение к теме?

V>4. Нет у C++ этого yield,

Уже целых 5 слов по теме. Поразительное достижение!

V> и я уже наверно с десяток раз сказал здесь, что реальная мощь yield состоит в трансформации автоматных алгоритмов в императивные.

Да, и что?

V>Но твой пример — далёк от того, что я понимаю под "мошью" yield, т.к сводится к копированию кода в MoveNext.

Да, и что?

V>На С++ можно было бы сделать маппинг на стороне приёмника в одну строчку, без заморочек с промежуточными объектами и цепочек делегатов. Но даже посмотрев на в точности аналогичный твоему вариант,

Вовсе не аналогичный.

V>ты, сознательно или нет, пропустил мимо ушей замечание, что представленный пример подходящ для огромного класса типов, в отличие от твоего варианта, который оперирует только int. ИМХО, бестолково мерить выразительность отдельно взятых строчек кода в отрыве от мест применения.

Это не имеет отношение к теме. От моего примера требовалась только невоспроизводимость на C++. На C++ он не воспроизводиться.

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

Ваши домыслы о моей логике, мне, откровенно говоря, мало интересны.

Здравствуйте, vdimas, Вы писали:

V>Т.е. имеем банальную диллему выбора — простота интерфейса или простота реализации.

Ну да, конечно, когда нет выбора — нет и дилеммы. Банальной.

Здравствуйте, Klapaucius, Вы писали:

K>Вовсе не аналогичный.

Аналогичный, посмотри еще раз. Отличие лишь в используемом типе енумератора, т.к. пример сделан для итераторов STL/CLI, но работает пример точно так же, маппинг происходит только тогда, когда кто-то пытается получить у итератора объект.

Здравствуйте, vdimas, Вы писали:

V>А ты думаешь я прикалываюсь? Это я в MSDN от VS2008 прочел, надеюсь у тебя он есть. Синтаксис там, конечно, не столь прикольный как для C# 3.0, тем не менее...

Есть. Дай ссылку, прочту и я. А то я только извращения на кодпрожект ведел. Поддержкой — это назвать нельзя.