Re: C++ vs C# and C++/CLI :) Dynamic Type - Философия программирования

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

PC>Наследование сделано не правильно...

См. предыдущие (и последующие) топики, а то твердить одно и то же надоело.

PC>Ок из-за безопасности... будем считать, что не тормозит...

PC>млин зачем делать членом, то что могло им не быть... Например в C++3x элементарно можно добавиь reflection в std::type_info...

А зачем не делать членом то, что может им быть?

В System.Object есть ещё Equals, GetHashCode и ToString — их, наверное, тоже стоит убрать?...

Информация о типе объекта всё равно всегда связана с объектом. Её всегда можно получить у объекта — так что почему бы не сделать соответствующий метод (который, к тому же, используется во многих местах в FCL и который совершенно не получится подменить)?

PC>Я и из typeid знаю... не так хорошо, но знаю

PC>Ладно про это проехали, С++ и без reflection хорошо живет...

Да просто отлично живёт. Сериализация, например, без reflection делается на раз-два-три совершенно без геморроя в виде тучи классов и макросов, правда?

PC>Я про CLI, а не про шарп. Наследние С и только. Memory leaks у некоторых и без GC нет...

Аргументы? Я так понял, пока что твой единственный аргумент это "неправильное" наследование?

PC>Так вот эти "за" и "против" о которых я спрашивал никто говорит не собирается.

Изучи вопрос. Почитай книжки (Рихтера, например), блоги, статьи. Я для тебя искать информацию не собираюсь (времени нет), но вот кое-что нашёл: http://www.artima.com/intv/choices.html (не в тему, так как там CLR vs JVM, а не CLR vs Godlike C++)

PC>Кое-что да, кое-что нет...

Согласен — CLI, C# и FCL не лишены недостатков. Но... покажи мне идеальный продукт

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

VD>>Да, уж. Подставища еще та. Я бы даже сказал клинический случай.

PC>Для С++/CLI да.

И чем же это подстава то? Это как раз в С++ вместо перегрузки по типу перекрытие на необъяснимых основаниях.

VD>>Однако как плюсы менталитет плющат.
PC>П. 5 !!!

VD>>Ведь даже в голову не прийдет, что решения в дизайне языков бывают разные? И уж темболее не задумываться же на счет того, что дизайн любимого языка может оказаться кривым?
PC>Очень даже придет... млин см. п. 5!!!

И где же ты углядел то п.5? Я же не виноват, что совершенно логичное поведение ты счет "подставой", а страннейшее С++-ное нормальным.

Как это еще объяснить? Это именно влияние языка на менталитет. Ты просто привык к изращенному миру и смотришь на нормальный мир как на нечто ненормальное.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

PC>Наследование сделано не правильно...

А вообще бывает что-то в программироании правильное и при этом не похожее на С++?

O>>"Почти" не считается. Я бы сказал — typeid сотоварищи и рядом не валялись с reflection.
PC>млин зачем делать членом, то что могло им не быть... Например в C++3x элементарно можно добавиь reflection в std::type_info...

А зачем что-то засовывать в даль если это неотемлемая часть любого объекта? Это чему-то помешает? Или снова ранушение принципов отрытозакрытости?

O>>Кстати, почему это GetType() идиотизм? Почему плохо всегда знать тип объекта? Или, если бы этот метод был статическим, тебе было бы легче?
PC>Я и из typeid знаю... не так хорошо, но знаю

Это знание бесценно, потому что бесполезно.

PC>Ладно про это проехали, С++ и без reflection хорошо живет...

Ага. Видимо по этому в С++ХХХ только и разговоры о нем.

PC>Я про CLI, а не про шарп. Наследние С и только. Memory leaks у некоторых и без GC нет...

И в чем же наследие С то выражается?

O>>Дизайн CLI отнюдь не случаен. Поверь — товарищи разработчики долго взвешивали все "за" и "против".
PC>Так вот эти "за" и "против" о которых я спрашивал никто говорит не собирается.

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

O>>И, я думаю, получилось у них очень неплохо.
PC>Кое-что да, кое-что нет...

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

Из C++/CLI попытались сделать современный язык сохранив совместимость с С++. Понятно, что совмещать ужа с ежом не простое занятие. Лично я прохладно отношусь к C++/CLI, но я прекрасно понимаю какую работу люди сделали.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

PC>>Для С++/CLI да.
VD>И чем же это подстава то? Это как раз в С++ вместо перегрузки по типу перекрытие на необъяснимых основаниях.
Что для ref class одни правила, для class другие. И всё. Не больше не меньше. Подстава для тех, кто переходит с C++ на C++/CLI.

VD>>>Ведь даже в голову не прийдет, что решения в дизайне языков бывают разные? И уж темболее не задумываться же на счет того, что дизайн любимого языка может оказаться кривым?
PC>>Очень даже придет... млин см. п. 5!!!

VD>Как это еще объяснить? Это именно влияние языка на менталитет. Ты просто привык к изращенному миру и смотришь на нормальный мир как на нечто ненормальное.
Млин опять! Или тут так принято?

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

O>Здравствуйте, Pavel Chikulaev, Вы писали:

PC>>Наследование сделано не правильно...
O>См. предыдущие (и последующие) топики, а то твердить одно и то же надоело
Ок

PC>>млин зачем делать членом, то что могло им не быть... Например в C++3x элементарно можно добавиь reflection в std::type_info...

O>А зачем не делать членом то, что может им быть?

В System.Object есть ещё Equals, GetHashCode и ToString — их, наверное, тоже стоит убрать?...
потому что если доступ private и protected и остальные не нужен — лучше не член. Хотя CLS уж слишком ООП, наверно не обойтись. Ладно проехали.

O>Информация о типе объекта всё равно всегда связана с объектом. Её всегда можно получить у объекта — так что почему бы не сделать соответствующий метод (который, к тому же, используется во многих местах в FCL и который совершенно не получится подменить)?

O>

Да.

PC>>Я про CLI, а не про шарп. Наследние С и только. Memory leaks у некоторых и без GC нет...
O>Аргументы? Я так понял, пока что твой единственный аргумент это "неправильное" наследование?
Еще будут... жди.

PC>>Так вот эти "за" и "против" о которых я спрашивал никто говорит не собирается.
O>Изучи вопрос. Почитай книжки (Рихтера, например), блоги, статьи. Я для тебя искать информацию не собираюсь (времени нет), но вот кое-что нашёл: http://www.artima.com/intv/choices.html (не в тему, так как там CLR vs JVM, а не CLR vs Godlike C++)
Читал... Просто похоже именно это никого не волнует...

PC>>Кое-что да, кое-что нет...
O>Согласен — CLI, C# и FCL не лишены недостатков. Но... покажи мне идеальный продукт

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

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

PC>>Наследование сделано не правильно...

VD>А вообще бывает что-то в программироании правильное и при этом не похожее на С++?
Да

Python, D

O>>>"Почти" не считается. Я бы сказал — typeid сотоварищи и рядом не валялись с reflection.
PC>>млин зачем делать членом, то что могло им не быть... Например в C++3x элементарно можно добавиь reflection в std::type_info...

O>>>Кстати, почему это GetType() идиотизм? Почему плохо всегда знать тип объекта? Или, если бы этот метод был статическим, тебе было бы легче?
PC>>Я и из typeid знаю... не так хорошо, но знаю

VD>Это знание бесценно, потому что бесполезно.

PC>>Ладно про это проехали, С++ и без reflection хорошо живет...
VD>Ага. Видимо по этому в С++ХХХ только и разговоры о нем.
Его не будет. никогда. Да и С++ и CLS не конкуренты вообще...

PC>>Я про CLI, а не про шарп. Наследние С и только. Memory leaks у некоторых и без GC нет...
VD>И в чем же наследие С то выражается?
95% косяков С++ от пришли из С и от них не избавиться

VD>Из C++/CLI попытались сделать современный язык сохранив совместимость с С++. Понятно, что совмещать ужа с ежом не простое занятие. Лично я прохладно отношусь к C++/CLI, но я прекрасно понимаю какую работу люди сделали.
+1

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

O>>А зачем не делать членом то, что может им быть? В System.Object есть ещё Equals, GetHashCode и ToString — их, наверное, тоже стоит убрать?...
PC>потому что если доступ private и protected и остальные не нужен — лучше не член. Хотя CLS уж слишком ООП, наверно не обойтись. Ладно проехали.

То CLS слишком ООП, то CLI не ООП...

Кстати, причём тут Common Language Specification? Может ты имел в виду FCL? Или даже CLR/CLI?

O>> Да просто отлично живёт. Сериализация, например, без reflection делается на раз-два-три совершенно без геморроя в виде тучи классов и макросов, правда?
PC>Да.

Ок. Предоставь пример такой мегабиблиотеки для C++ — я хотел бы сериализовать/десериализовать что-то вроде std::set (раз уж он упоминался) — т.е. обюъекты типов из стандартной библиотеки — и объекты своих типов.

Все библиотеки для сериализации (буст и ручные поделки), что я видел до сих пор, изобилуют макросами, которые девелопер вынужден пихать в свои классы. А насчёт сериализации и стандартных типов... вообще не видел.

O>>Аргументы? Я так понял, пока что твой единственный аргумент это "неправильное" наследование?
PC>Еще будут... жди.

Ждю.

PC>Читал... Просто похоже именно это никого не волнует...

Может, не то читал?

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

PC>Что для ref class одни правила, для class другие. И всё. Не больше не меньше. Подстава для тех, кто переходит с C++ на C++/CLI.

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

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

PC>Да

Python, D

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

PC>>>Ладно про это проехали, С++ и без reflection хорошо живет...
VD>>Ага. Видимо по этому в С++ХХХ только и разговоры о нем.
PC>Его не будет. никогда. Да и С++ и CLS не конкуренты вообще...

Кого? Нового стандарта? Это конечно возможно.

А вот если он все таки случится, то уверен, что аналог рефлекшона там будет. Не даром этим вопросом сам Страуструп занимался.

PC>>>Я про CLI, а не про шарп. Наследние С и только. Memory leaks у некоторых и без GC нет...
VD>>И в чем же наследие С то выражается?
PC>95% косяков С++ от пришли из С и от них не избавиться

А, так ты о С++? А из контекста можно подумать, что о CLI. Ну, тут можно только посочувствовать. Вот твой любимый Ди хороший пример того как оставаясь совместимым с С не загрести всех косяков. Сдается мне, что дело все же было в первую очередь в непродуманности дизайна языка. Если бы напрячься, то 99% косяков можно было обойти.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

VD>>Попробуй заняться статистикой... подсчитать количество обратившихся в форумы со случаями подобными описаным тобой на Шарпе, и со случаями вроде "почему не вызвалась моя виртуальная функция в С++?" и "почему виртуальный конструктор не виртуальный?".
PC>Для домохозяек это безусловно аргумент...

Интересно почему поклонники С++ так часто позволяют себе стольк высокомерные фразы. Не знашь частом?

Хотя аналогии вряд ли можно счесть за аргумент, но мне почему-то все время хочется провести следующую аналогию.
Сидит орел и критикует мерседес шестисотый. Мол неповоротливый. Бензин жрет. Едешь под 250, а скорость не чувствуется. Те кто его водит даже не знают где в машике находится топливный фильтр. То ли дело наш жигуль. 250 конечно не пойдет, но и на 120 ветер так свистит, что адреналин переполняет. Бензина жрет мало. А уж как будешь в крабюраторах и другой дрибидени разбираться?... В общем, зверь-машина. Это вам не это ламерские шестесотые...

Вот так же тут. Сначала поговорили про гипотетические проблемы, а потом поняв, что претензии надуманные наклеили ярлычок "для домохозяек".

А вот другой бы ярлычек пришпилил. Это для тех кто любит комфорт и умеет ценить свое время и нервы.

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

VD>>А потом за одно подсчитай сколько обратилось с вопросом "почему в С++ не вызвался деструктор класса наследника?". Ведь ты не указал, что у Base деструктор виртуальный, но тем не менее вызывашь его у типа приведенного к базовому.
PC>"Pay as you go" а не "а мне пофиг сколько программа жрет памяти, когда надо удалится, а то, что не детерминированно и исходный код как на ладони это безусловно фигня".

Что-то я не оценил этого перехода. Обсуждали вроде деструкторы и финалайзеры.

VD>>Почти уверен отевет на все вопросы будет "да они все ламеры..."

PC>давай я сам отвечу, а?

Давай. Но про домохозяек ты уже сказал.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

PC>И все в .NET замечательно да? фанатизм какой-то...

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

ЗЫ

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

... << RSDN@Home 1.2.0 alpha rev. 620>>

Oyster wrote:
> Ок. Предоставь пример такой мегабиблиотеки для C++ — я хотел бы
> сериализовать/десериализовать что-то вроде std::set (раз уж он
> упоминался) — т.е. обюъекты типов из стандартной библиотеки — и объекты
> своих типов
А чего его представлять?? У меня уже давно работает:

struct code_line
{
    int num;
    ...
    template<class Archive> void serialize(Archive & ar)
    {
        ar & num;
    }
};

struct file_coverage_info
{
    std::hash_map<code_line,int> lines_hit;
    std::set<code_line> lines_missed;
    std::set<code_line> lines_uncompiled;

    template<class Archive> void serialize(Archive & ar)
    {
        ar & lines_hit & lines_missed & lines_uncompiled;
    }
};

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 2.0

Cyberax wrote:
> А чего его представлять?? У меня уже давно работает:
Кстати, это как раз Boost.S11N. Для всех стандартных контейнеров там
поддержка есть, а также еще для Boost.Graph, Boost.SmartPtr и т.п.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 2.0

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

S>>Есть. Просто ты их не замечаешь. Ты искусственно придумал пример, при котором финалайзер базового типа начинает заниматься фигней.
PC>Ок придумай искусственный пример где С++ с его семантикой смены динамического типа в дторе подведет. Жду.
Как нефиг делать.

class Base 
{
  private: 
    Handle m_fileHandle;
    protected: 
  virtual void Close()
    {
      CloseHandle(m_fileHandle);
    }
    virtual ~Base()
    {
      Close(); // 
    }
}

class Derived : public Base
{
  private:
    void* m_buffer;
    virtual void Close()
    {
      delete[] m_buffer;
        Base::Close();
    }
}

Я намеренно поскипал код конструкторов и методов Open для краткости. Поясню: наш класс реализует переоткрываемый ресурс. Его можно закрыть и переоткрыть вручную, а можно потерять в конструкторе. В данном варианте у нас Derived::Close() не будет вызван при разрушении Derived. Несмотря на то, что мы вызываем виртуальный метод из виртуального метода. Ок, допустим я в отчаянии прочел доку и узнал про эти грабли. Я дописываю деструктор ~Derived с вызовом Close. Отлично — теперь у меня дважды вызывается Base::Close().

S>>Для начала рекомендую несколько освоиться с индетерминистической финализацией как таковой. Она сводится не только к отсутствию возможности вызвать деструктор напрямую. Есть и другие ограничения. В аналогичном случае ты бы рисковал получить то же самое, т.к. вместо вызова деструктора у тебя был бы вызов классического виртуального метода Dispose. И он точно так же позвал бы Derived::Foo, который бы успешно обратился к уже отдиспозенному Derived::o. И получил бы исключение ObjectDisposed.
PC>Почему ты так уверен, что я это не понимаю?

Потому, что ты пишешь о разрушении объекта как о детерминистическом процессе. Правильное отношение к нему в управляемой среде не включает копание в последовательности фаз разрушения. Точка.
S>>И чего он позволит достичь? Зачем, собственно, этот геморрой?
PC>Потому что это самый правильный вариант, но в чистом виде он нигде не используется (ни в С++ ни CLS)
Еще раз: помимо теоретической правильности, есть какие-нибудь практические выгоды от его использования? Что, что-то станет более эффективно работать? Или удастся где-то сэкономить строчку кода?
S>>Здравый смысл и огромный опыт.
PC>Сомневаюсь...
А ты не сомневайся. Почитай блоги этих парней. Бокс и Хейльсберг совершенно точно были изготовлены не при помощи пальца. И почти все вопросы, которые могут в наши головы прийти, им тоже приходили. Но в отличие от нас, изредка пописывающих в форум философия в перерыве между обедом и кодингом, эти парни тратили по 8 часов в день именно на тщательное продумывание всех этих идей. А также на анализ кода существующих приложений на Java, С++, Delphi и VB. И на рассмотрение жалоб народа на недостатки этих языков и платформ. Да что там 8 часов в день — у них целые команды в подчинении, которые только этим и занимаются! Тут же такое дело — реализовать как раз очень несложно все. Особенно когда ты работаешь в МС. Захотел новое ключевое слово в C# — бах, и в следующем weekly build оно уже работает. Проблема в том, как придумать это все. Чтобы ничего ничему не противоречило, чтобы ни компилятор ни программист не глючили, и чтобы фича не внесла больше геморроя, чем ее отсутствие.
S>>А, вот теперь мне все понятно. Я рекомендую тебе воздержаться от критики дотнета до тех пор, пока ты не получишь достаточный опыт. Нельзя слепо переносить опыт из одной среды в другую. GetType() настолько круче, чем typeid, что это даже обсуждать бессмысленно. На нем построено очень много чего в дотнете.
PC>П. 5. Я ЭТО МЛИН ЗНАЮ! В скобках написано, что reflection не учитывается...
Да хоть п.8. Я не понимаю, как можно рассуждать о дотнете, отбрасывая Reflection. Ну давай отбросим от С++ перегрузку операторов, классы и исключения. Ну и в чем его мифическое преимущество перед C? Я как-то общался с дизайнером интерьеров. У них на эту тему есть мини-анекдот про заказчика, который хотел стену между комнатой и кухней, с одной стороны — прозрачную, а с другой — заклеенную обоями. Вот примерно также и ты — не против рефлекшна, но против GetType. Если ты вдруг имел в виду то, что можно было бы сделать GetType внешним по отношению к object, то я тебя разочарую — в контексте разговора внешний GetType работает точно так же, как и внутренний. Мы должны получать настоящий тип объекта. Нарушение этого правила приведет к очень большому геморрою.

S>>Но ты пока что не видишь всей этой мощи, потому как смотришь на дотнет сквозь танковую смотровую щель С++.
PC>А ты уверен, что щель с моей стороны? Я нет.
Я — уверен. Потому что ты игнорируешь фичи дотнета, невозможные в плюсах. Эдак походя — типа "я в плюсах это имею парой строчек кода". Хрен там, не имеешь. Зато какие-то маловажные особенности реализации, отличающиеся от С++, ты считаешь достойными критики.
PC>>>Очень жаль, что разрботчики .NET не читали Design & Evolution of C++ — много бы проблем избежали типа не совмещять понятия access и overload.
S>>Уверяю тебя — читали. И изучили не только С++, а еще много языков.
PC>И все в .NET замечательно да? фанатизм какой-то...
Ну, по крайней мере лучше, чем в большинстве предшествующих технологий.

1.1.4 stable rev. 510

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

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

A>>Здравствуйте, Pavel Chikulaev, Вы писали:

A>>Ужос!

PC>Для native типов в С++/CLI все остается по прежнему

PC>Там еще очень много подстав... Статью что-ли написать?

PC>Например:
...
PC>Hidebysig in action.

Это ещё что. Как объяснить вот это:

using namespace System::IO;

int main() {
    FileStream f = File::Create("test"); // error C3673: 'System::IO::FileStream' : class does not have a copy-constructor
    FileStream f = FileStream("test", FileMode::Create); // error C3673
    FileStream f("test", FileMode::Create); // OK
}

Что такое copy constructor для ref класса, зачем он в нужен, и какие реализации отличные от тривиальной у него могут быть?

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

S>>>Есть. Просто ты их не замечаешь. Ты искусственно придумал пример, при котором финалайзер базового типа начинает заниматься фигней.
PC>>Ок придумай искусственный пример где С++ с его семантикой смены динамического типа в дторе подведет. Жду.
S>Как нефиг делать.
Извини, что так долго шел ответ...

S>class Base 
S>{
S>  private: 
S>    Handle m_fileHandle;
S>    protected: 
S>  virtual void Close()
S>    {
S>      CloseHandle(m_fileHandle);
S>    }
S>    virtual ~Base()
S>    {
S>      Close(); // 
S>    }
S>}

S>class Derived : public Base
S>{
S>  private:
S>    void* m_buffer;
S>    virtual void Close()
S>    {
S>      delete[] m_buffer;
S>        Base::Close();
S>    }
S>}
S>

S>Я намеренно поскипал код конструкторов и методов Open для краткости. Поясню: наш класс реализует переоткрываемый ресурс. Его можно закрыть и переоткрыть вручную, а можно потерять в конструкторе. В данном варианте у нас Derived::Close() не будет вызван при разрушении Derived. Несмотря на то, что мы вызываем виртуальный метод из виртуального метода. Ок, допустим я в отчаянии прочел доку и узнал про эти грабли. Я дописываю деструктор ~Derived с вызовом Close. Отлично — теперь у меня дважды вызывается Base::Close().
1) RAII. Зачем open и close? Т.к. процесс создания, закрытия, открытия тоже самое, что и создание первого объкта, разрушение, создание второго. Зачем усложнять класс?
2) Т.к. ты сам придумал себе весь этот геморрой с open и close, то объект у тебя может иметь два состояния — есть ресурс и нет. Поэтому следует иметь или явную переменную обозначающую состояние (правильный способ), или неявную — так чтобы при повторном вызове close ничего не происходило:

void base::close()
{
    CloseHandle(handle_);
    handle_ = INVALID_HANDLE; //вроде так... забыл Win API :shuffle:
}

void derived::close()
{
    delete[] buffer_;
    buffer_ = 0;
}

PC>>Потому что это самый правильный вариант, но в чистом виде он нигде не используется (ни в С++ ни CLS)
S>Еще раз: помимо теоретической правильности, есть какие-нибудь практические выгоды от его использования? Что, что-то станет более эффективно работать? Или удастся где-то сэкономить строчку кода?

S>>>Здравый смысл и огромный опыт.
PC>>Сомневаюсь...
S>А ты не сомневайся. Почитай блоги этих парней. Бокс и Хейльсберг совершенно точно были изготовлены не при помощи пальца. И почти все вопросы, которые могут в наши головы прийти, им тоже приходили. Но в отличие от нас, изредка пописывающих в форум философия в перерыве между обедом и кодингом, эти парни тратили по 8 часов в день именно на тщательное продумывание всех этих идей. А также на анализ кода существующих приложений на Java, С++, Delphi и VB. И на рассмотрение жалоб народа на недостатки этих языков и платформ. Да что там 8 часов в день — у них целые команды в подчинении, которые только этим и занимаются! Тут же такое дело — реализовать как раз очень несложно все. Особенно когда ты работаешь в МС. Захотел новое ключевое слово в C# — бах, и в следующем weekly build оно уже работает. Проблема в том, как придумать это все. Чтобы ничего ничему не противоречило, чтобы ни компилятор ни программист не глючили, и чтобы фича не внесла больше геморроя, чем ее отсутствие.
У разработчиков VB и Delphi тоже были целые комманды и что?

S>>>А, вот теперь мне все понятно. Я рекомендую тебе воздержаться от критики дотнета до тех пор, пока ты не получишь достаточный опыт. Нельзя слепо переносить опыт из одной среды в другую. GetType() настолько круче, чем typeid, что это даже обсуждать бессмысленно. На нем построено очень много чего в дотнете.
Тоже самое к тебе о С++.

	От:	Pavel Chikulaev
	Дата:	17.12.05 07:28
	Оценка:

	От:	Pavel Chikulaev
	Дата:	17.12.05 07:29
	Оценка:

От:	Oyster	https://github.com/devoyster
Дата:	17.12.05 07:45
Оценка:

От:	VladD2	www.nemerle.org
Дата:	17.12.05 07:50
Оценка:

От:	VladD2	www.nemerle.org
Дата:	17.12.05 07:50
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	19.12.05 08:23
Оценка:

	От:	alexeiz
	Дата:	22.12.05 00:01
	Оценка: