Re[9]: Metaprogramming et al
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.07.05 04:02
Оценка: 1 (1)
Здравствуйте, eao197, Вы писали:

E>...если Lisp так хорош, то почему же он не мейнстрим? Ну не могу я понять. И аргументов, которые бы доказывали, что Lisp хорош не вижу. Только восторженные отзывы.


Дело в том, что Лисп плох. Да и восхваляют его очень небольшое количество людей. Но с тем что лисповские макросы до сих пор являются одним из смых гибких средств метапрограммирования не поспоришь. Это факт.

Между прочем если взять самых рьяных апологетов ФЯ (т.е. Гапертора и Квантонара), то можно заметить, что они как раз на лисп смотрят довольно прохладно. Так Гапертон, как мне показалось, больше агетировал за Хаскель и Эрлинг (по крайней мере для целей обучения). Примеры на этих языках мне тоже больше понравились. Квантонар выступал за Окамл. И я очень даже понимаю его аргументы. Это как раз то ФЯ на котором очень даже можно писать риальные приложения. Причем это статически типизированный язык в котором нет даже компромиса в типобезопасности.

А Лисп — это прородитель всего этого у которого в добавок удобный для трасформаций синтаксис. Только и всего.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Metaprogramming et al
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.07.05 04:02
Оценка:
Здравствуйте, Кодёнок, Вы писали:

Кё>"Если RISC лучше, то почему у всех стоит Intel"


Потому что это вранье. Лучше тот процессор который бысрее решает задачи. Интел решает задачи ПК бысрее.

Кё>"Если FreeBSD лучше, то почему Windows более распространён"


Потому что это тоже вранье. FreeBSD лучше Линукса и то как сервер. А как машина для бухгалтера или как машина для геймера FreeBSD полный 0.

Кё>"Если интерфейс Mac OS всегда был лучше (впереди), то почему даже опен-сорсные библиотеки ему не следуют"


Чё?

Кё>Много факторов повлияло на проигрыш лучших технологий,


Лучше то что побидило.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Metaprogramming et al
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.07.05 04:02
Оценка:
Здравствуйте, Кодёнок, Вы писали:

Кё>Потому что они императивные. Понятные всем. А чтобы освоить новое мышление, нужно немного усилий.


О, как?!

Скажи, а for в Лиспе функциональнее чем for в Питоне? А скажем, map() в Питоне императивнее чем в Лиспе?

Что является критерием функциональности и императивности?

Мое мнение по этому вопросу таково. Императивный и функциональый это про стиль программирования. И если язык поддерживает оба стиля, то определение того к какому классу относится язык — это не более чем устоявшийся стереотип.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Metaprogramming et al
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.07.05 04:02
Оценка:
Здравствуйте, Курилка, Вы писали:

К>А макросы уровня лиспа писать тоже никто не мешает? Писать функционально мало, имхо, на плюсах тоже получается местами вполне функционально...


Аргумент был "Потому что они императивные". Хаскель тоже функциональный, но с макросами там туго, так как язык имеет четкий и развитой синтаксис и не имеет препроцессора.

А что до макросов, то их при желании можно прикрутить к любому языку. Например, вот вариант прикручивания их к Яве. В Питоне и Руби тоже есть свои реализации макросво я-ля Лисп.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Metaprogramming et al
От: Павел Кузнецов  
Дата: 20.07.05 05:21
Оценка: -1
VladD2,

Ш>> надувательские языки, они не столько помогают бороться с ошибками,

Ш>> сколько их банально скрывают.

V> Примеры скрытия ошибок языком можно поглядеть?


Легко. Исключение в finally во время обработки уже выброшенного исключения.
Первое при этом потеряется. Одна ошибка уже скрыта
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[12]: Metaprogramming et al
От: Павел Кузнецов  
Дата: 20.07.05 05:39
Оценка: -1
P.S.

V>> Примеры скрытия ошибок языком можно поглядеть?


ПК> Легко. Исключение в finally во время обработки уже выброшенного

ПК> исключения. Первое при этом потеряется. Одна ошибка уже скрыта

Кстати, еще один пример
Автор: Павел Кузнецов
Дата: 19.07.05
: вместо исправления ситуации ошибку
"замазали" требованием поддержки множественных вызовов Dispose. При этом
сами же признают, что ошибки таким макаром прячутся:

Though it is legal to invoke Dispose more than once, if this happens it may indicate the presence
of a bug since such an object is usually rendered otherwise unusable after the first Dispose invocation.

Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[8]: Metaprogramming et al
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.07.05 05:43
Оценка: 1 (1) +2
Здравствуйте, VladD2, Вы писали:

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


VD>Полная ерунда. Чтобы нормально программировать нужно просто уметь нормально программировать. И человек поверхносно знающий С++ ничем не будет отличаться от человека поверхносно знающего C#.


В том-то и дело, что в C++ недостаточно "просто уметь нормально программировать". Кроме умения нормально проектировать решения в C++ требуется еще довольно много внимания уделять "мелким" техническим деталям. В противном случае даже хорошие программисты, перешедшие с Java на C++ будут писать проблемный код. Типа вот такого:
void do_something()
    {
        int * params = new int[ 10 ];
        ....
    }
    
class    connection_info_t
    {
    private :
        std::string &    m_data_source;
        ...
    public :
        ...
        std::string    data_source() { return m_data_source; }
        ...
    };
    
connection_t *
connect( connection_info_t * info );

connection_t *
establish_connection( std::string data_source, std::string user, std::string password )
    {
        ...
        connection_t * c = connect( new connection_info_t( data_source, user, password ) );
        ...
        return c;
    }


И проблема заключается именно в том, чтобы научить человека заниматься такими мелочами. А это действительно проблема, т.к. лично я время от времени, после очередного указания на подобные ляпы, слышал в ответ: "Да нафига этот C++ вообще нужен, если я о таких мелочах думать должен! Об этом компилятор и run-time заботиться должны!". Вот именно такой сдвиг в психологии Java программистов и не дает многим из них нормально перейти на C++.

E>>И еще хорошо, если человек действительно молодой, не очень опытный, понимающий это и без понтов.


VD>С понтами скорее те кто считает С++-ников высшей кастой. Понимать здесь точно нечего.


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

E>> И ведь стимула к изучению C++, как такового, нет. Ну нужно освоить C++ для того, чтобы работать в нашей конторе, а вот в соседней конторе он на уже известной ему Java будет прямо сейчас получать устраивающую его зарплату. Так зачем же прилагать лишние усилия, если результат представляется одинаковым?


VD>Не льсти себе. Нет у вас никакой касты.


Покажи мне, пожалуйста, где я говорил о нашей кастовости? Или у тебя после перехода с C++ на C# комплекс возник? Вроде того, что раньше, в бытность C++ программистом, ты был в касте, а сейчас уже нет. Абыдно, да? ((C) Ю.Никулин)

VD>Ява же просто терпимее относится к ошибкам. И там где ламер (которые и бывают обычно дешевыми) насажает в С++ ошибок которые потом бригадов за пол года не вычистить, то на яве он просто сделает не эффектинове и кривое решение которое с помощью рефакторинга и какой-то матери получится хоть как-то запустить.


Так об этом же я и говорю.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: Metaprogramming et al
От: pvgoran Россия  
Дата: 20.07.05 07:16
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И все же дело не в мухах. Лично я предпочту более длинный, но более понятный код. Не же ли хакирский (в лучшем смысле этого слова) выверт укладывающий 5 строк в одну. В конечном итоге грамотно написанный код все равно сведется к некой функции или классу который скроет от меня все эти 5 (500 или сколько угодно) строк и предоставит мне удобную абстракцию.


Дело в том, что Lisp (вроде бы) позволяет без особых проблем заложить в абстракцию то, что (например) в C++ абстрагировать либо совсем невозможно, либо можно, но очень неудобно (реализации и/или в использовании).

Пример — boost::spirit, в частности, его closures (если что — это не то же, что closures в Лиспе). Они полезны, без них было бы сложнее жить — но они так криво описываются...
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[10]: Metaprogramming et al
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.07.05 07:40
Оценка: +1
Здравствуйте, Павел Кузнецов, Вы писали:

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


Ответ не верный. Эти платформы меньше страдают от некачественного кода не потому, что они менее гибкие, а потому что проблема, возникшая из-за ошибок программиста вычисляется значительно быстрее, и как правило сразу точно известно почему и кто виноват. Т.е. для определения кто есть ху мне не нужно копаться в исходниках и искать косяки, достаточно глянуть на стек-трейс.
... << RSDN@Home 1.2.0 alpha rev. 580>>
AVK Blog
Re[11]: Metaprogramming et al
От: Cyberax Марс  
Дата: 20.07.05 12:54
Оценка:
AndrewVK wrote:

> ПК>И эта же нацеленность на компенсацию некачественного кода и помощь

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

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

> Т.е. для определения кто есть ху мне не нужно копаться в исходниках и

> искать косяки, достаточно глянуть на стек-трейс.

Да? А вы знаете, что в core-файлах вдобавок к stack-trace'ам всех тредов
еще сохраняются и стековые фреймы (или даже полное состояние
приложения)? По dmp-файлам мне лично отлаживать намного приятнее, чем по
одиночному stack-trace'у.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[12]: Metaprogramming et al
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.07.05 13:10
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Да? А вы знаете, что в core-файлах вдобавок к stack-trace'ам всех тредов

C>еще сохраняются и стековые фреймы (или даже полное состояние
C>приложения)? По dmp-файлам мне лично отлаживать намного приятнее, чем по
C>одиночному stack-trace'у.

По стектрейсу обычно отлаживаться не надо, и без отладчика все понятно. Дело не в самом стектрейсе, а в том что вероятность наведенной ошибки мала, грохается обычно в непосредственной близости от косяка.
... << RSDN@Home 1.2.0 alpha rev. 580>>
AVK Blog
Re[16]: Metaprogramming et al
От: vdimas Россия  
Дата: 21.07.05 13:08
Оценка:
Здравствуйте, VladD2, Вы писали:

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



V>>Что сказать-то хотел?


VD>Re[11]: Metaprogramming et al
Автор: VladD2
Дата: 12.07.05


епрст, ну когда научимся читать оппонентов малость тщательнее?


Цикл чего, простите, длиннее? Цикл внесения серьезных изменений — да, длиннее. Цикл разработки по "устаканившемуся" ТЗ — ничуть.


Без уточнения, цикл чего именно имеется в виду — спорить бессмысленно. На тот момент, когда шла разработка, была важна скорость изменения функциональности.

Если же ТЗ вполне устоялось, то скорость разработки на С++ не уступит ни Java ни C#. А если проект достаточно большой, то может существенно обогнать.


----------
"Достаточно большой" в данном контексте означает содержание большой доли функциональности, которой нет во всяких фреймворках.
Re[13]: Metaprogramming et al
От: Cyberax Марс  
Дата: 22.07.05 07:23
Оценка: +2
AndrewVK wrote:

> C>Да? А вы знаете, что в core-файлах вдобавок к stack-trace'ам всех

> тредов
> C>еще сохраняются и стековые фреймы (или даже полное состояние
> C>приложения)? По dmp-файлам мне лично отлаживать намного приятнее,
> чем по
> C>одиночному stack-trace'у.
> По стектрейсу обычно отлаживаться не надо, и без отладчика все
> понятно. Дело не в самом стектрейсе, а в том что вероятность
> наведенной ошибки мала, грохается обычно в непосредственной близости
> от косяка.

Вот как раз хэндлинг NullPointerException'а и может навести ошибку, так
как очень часто NPE просто скрывает баги в коде.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[14]: Metaprogramming et al
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 22.07.05 07:58
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Вот как раз хэндлинг NullPointerException'а и может навести ошибку, так

C>как очень часто NPE просто скрывает баги в коде.

Это зависит какой хендлинг. Если он после себя оставляет следы, например ввиде записей в логе, то ничего не скрывается. А за пустой catch в 99% случаев надо расстреливать на месте.
... << RSDN@Home 1.2.0 alpha rev. 583>>
AVK Blog
Re[17]: Metaprogramming et al
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.07.05 15:26
Оценка:
Здравствуйте, vdimas, Вы писали:


V>епрст, ну когда научимся читать оппонентов малость тщательнее?


Хороший вопрос. Ты над ним сам то задумывался?

Вот прочти еще раз Re[11]: Metaprogramming et al
Автор: VladD2
Дата: 12.07.05
и погляди о чем там идет речь. Мне совершенно по фигу правильность или не правильность рассуждений о "длиннах". Там сделан вывод о том что от А отказались в пользу Б так как В имеет приемущество. Все! Точка! Если ты действительно не всилах понять алогичности подобных рассуждений, то обсуждать больше нечего.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Metaprogramming et al
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.07.05 15:26
Оценка:
Здравствуйте, pvgoran, Вы писали:

P>Дело в том, что Lisp (вроде бы) позволяет без особых проблем заложить в абстракцию то, что (например) в C++ абстрагировать либо совсем невозможно, либо можно, но очень неудобно (реализации и/или в использовании).


В любом ЯП можно абстрагироваться от любой проблемы. Для этого достаточно банальных процедур. Так что не нужно рассказывать сказки.

P>Пример — boost::spirit, в частности, его closures (если что — это не то же, что closures в Лиспе). Они полезны, без них было бы сложнее жить — но они так криво описываются...


boost::spirit — это LL(1)-парсер. Про то что в нем есть closures я никогда не слышал.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Metaprogramming et al
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.07.05 15:26
Оценка:
Здравствуйте, eao197, Вы писали:

E>В том-то и дело, что в C++ недостаточно "просто уметь нормально программировать". Кроме умения нормально проектировать решения в C++ требуется еще довольно много внимания уделять "мелким" техническим деталям.


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

E> В противном случае даже хорошие программисты, перешедшие с Java на C++ будут писать проблемный код.


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

E> Типа вот такого:

E>
E>void do_something()
E>    {
E>        int * params = new int[ 10 ];
E>        ....
E>    }
    
E>class    connection_info_t
E>    {
E>    private :
E>        std::string &    m_data_source;
E>        ...
E>    public :
E>        ...
E>        std::string    data_source() { return m_data_source; }
E>        ...
E>    };
    
E>connection_t *
E>connect( connection_info_t * info );

E>connection_t *
E>establish_connection( std::string data_source, std::string user, std::string password )
E>    {
E>        ...
E>        connection_t * c = connect( new connection_info_t( data_source, user, password ) );
E>        ...
E>        return c;
E>    }
E>


E>И проблема заключается именно в том, чтобы научить человека заниматься такими мелочами.


Научи этом "матерых С++-ников" с этого сайта. У нас в половине статей delete или разные вариации free используются направо и налево. Вот, например, третья же статья в поиске по статьям выдала:
http://rsdn.ru/article/patterns/singleton.xml
Автор(ы): Дмитрий Федоров
Дата: 14.11.2002

void main()
{
  Application* application = Application::Instance();
  application->Run();
  delete application;
}

Что будет при исключении думаю ты и сам понимашь. И таких случаев море.

E> А это действительно проблема, т.к. лично я время от времени, после очередного указания на подобные ляпы, слышал в ответ: "Да нафига этот C++ вообще нужен, если я о таких мелочах думать должен! Об этом компилятор и run-time заботиться должны!". Вот именно такой сдвиг в психологии Java программистов и не дает многим из них нормально перейти на C++.


Интересно, а какие задачи вы заставляете решать на С++ бывших Явщиков?

VD>>С понтами скорее те кто считает С++-ников высшей кастой. Понимать здесь точно нечего.


E>С понтами -- это те, кто говорят: "Да дайте любую задачу, я вам щас ее за 5 минут!". А после пятиминутного махания шашкой оказывается, что решения, в лучшем случае, приходится ждать в два раза дольше намеченного срока.


10 минут?

E>Покажи мне, пожалуйста, где я говорил о нашей кастовости?


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

E> Или у тебя после перехода с C++ на C# комплекс возник?


У меня возникает раздражение когда я вижу рассуждения о некотором превосходстве С++-программистов.

E> Вроде того, что раньше, в бытность C++ программистом, ты был в касте, а сейчас уже нет. Абыдно, да? ((C) Ю.Никулин)


Я не считаю, что качество программиста зависит от многих факторов. И среди этих факторв есть такой как количество и разнообразие изученных языков и технологий, но нет конкретного пункта про С++. Более того лдей программирующих на Дельфи или VB, но, при этом , отлично знающих, к пример Ocaml я считаю потенциально более развитыми чем тех кто знает С/С++.

VD>>Ява же просто терпимее относится к ошибкам. И там где ламер (которые и бывают обычно дешевыми) насажает в С++ ошибок которые потом бригадов за пол года не вычистить, то на яве он просто сделает не эффектинове и кривое решение которое с помощью рефакторинга и какой-то матери получится хоть как-то запустить.


E>Так об этом же я и говорю.


Ты говоришь не о том. Еще раз. Класс программиста не зависит от того изучил он С++ или Яву. И то что Ява — это типобезопасный язык без ужасного наследия не делает автоматом даунами всех кто на ней пишет. Ты же постоянно пыташся доказать обратное. У тебя С++-программист это особенный человек обладающий способностями суперменов.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Metaprogramming et al
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.07.05 15:26
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>VladD2,


Ш>>> надувательские языки, они не столько помогают бороться с ошибками,

Ш>>> сколько их банально скрывают.

V>> Примеры скрытия ошибок языком можно поглядеть?


ПК>Легко. Исключение в finally во время обработки уже выброшенного исключения.

ПК>Первое при этом потеряется. Одна ошибка уже скрыта

Эдак можно и до радио докапаться. В catch тоже исключения ведь могут быть.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Metaprogramming et al
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.07.05 15:26
Оценка: +1
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>P.S.


V>>> Примеры скрытия ошибок языком можно поглядеть?


ПК>> Легко. Исключение в finally во время обработки уже выброшенного

ПК>> исключения. Первое при этом потеряется. Одна ошибка уже скрыта

ПК>Кстати, еще один пример
Автор: Павел Кузнецов
Дата: 19.07.05
: вместо исправления ситуации ошибку

ПК>"замазали" требованием поддержки множественных вызовов Dispose. При этом
ПК>сами же признают, что ошибки таким макаром прячутся:
ПК>

ПК>Though it is legal to invoke Dispose more than once, if this happens it may indicate the presence
ПК>of a bug since such an object is usually rendered otherwise unusable after the first Dispose invocation.


Я вижу только безграмотную реализацию паттерна. Если в базовом классе, к примеру в Form, реализован паттерн Dispose и сделано это с помощью создания виртуального метода:
protected virtual void Dispose(bool disposing)

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

using System;

namespace cs_test
{
    class C : IDisposable
    {
        // Реализуем Dispose Pattern, как завещает спецификация.

        private bool disposed = false;

        ~C()
        {
            Console.WriteLine("~C");
            Dispose(false);
        }

        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        }

        protected virtual void Dispose(bool disposing)
        {
            Console.WriteLine("C.Dispose({0})", disposing);

            if (!this.disposed)
            {
                if (disposing)
                {
                    // TODO: Dispose managed resources.
                }
                // TODO: Dispose unmanaged resources here.
            }
            disposed = true;
        }
    }

    class C1 : C
    {
        private bool disposed = false;

        protected override void Dispose(bool disposing)
        {
            Console.WriteLine("C1.Dispose({0})", disposing);

            if (!this.disposed)
            {
                base.Dispose(disposing);
            }
            disposed = true;
        }
    }

    class C2 : C1
    {
        private bool disposed = false;

        protected override void Dispose(bool disposing)
        {
            Console.WriteLine("C2.Dispose({0})", disposing);

            if (!this.disposed)
            {
                base.Dispose(disposing);
            }
            disposed = true;
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            C2 c = new C2();
            GC.Collect();
            GC.WaitForPendingFinalizers();
        }
    }
}

Ну, и его вывод:
~C
C2.Dispose(False)
C1.Dispose(False)
C.Dispose(False)


От таких ошибок не застрахует ни один язык. Это банальное не понимание паттерна.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Metaprogramming et al
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 22.07.05 15:47
Оценка:
Здравствуйте, VladD2, Вы писали:

P>>Дело в том, что Lisp (вроде бы) позволяет без особых проблем заложить в абстракцию то, что (например) в C++ абстрагировать либо совсем невозможно, либо можно, но очень неудобно (реализации и/или в использовании).


VD>В любом ЯП можно абстрагироваться от любой проблемы. Для этого достаточно банальных процедур. Так что не нужно рассказывать сказки.


Однако ж в C# вместо абстракции при помощи процедур пришлось вводить ключевое слово foreach. Или итераторы C#2 те же.
... << RSDN@Home 1.1.4 stable rev. 510>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.