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

AVK>Влад, да бог с ним, пускай работает на 98. Через пару лет все равно NT поставит. 95 не поддерживается, а 98, 98SE и ME отличаются только косметикой. Офис вон уже не работает. 7 студия тоже. Дальше будет только хуже.

Насчет 98 и 98SE — не согласен. Очень существенные различия, например, в работе с сетью, и в SE много меньше ошибок. ME — просто дрянь, несмотря на косметику.

Здравствуйте <Аноним>, Вы писали:

А>Насчет 98 и 98SE — не согласен. Очень существенные различия, например, в работе с сетью, и в SE много меньше ошибок. ME — просто дрянь, несмотря на осметику.

По сравнению с различиями NT4 и W2K сущая косметика. Как и XP впрочем.

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

S>>Трудно реализовать, особенно в сочетании с полиморфизмом, вот и шагают.

AVK>Ой ли. Не сложнее рефлекшена. Сотни мегабайт исходников, а множественное наследование трудно реализовать. Не смешно.

Сотни мегабайт исходников транслятора C# или жабы Очень даже смешно. Даже компилятор C++ меньше занимает.

AVK>А полиморфизм тут вобще не причем, множественное наследование интерфейсов есть и в джаве и в дотнете.

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

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

AVK>Давай так — лично ты не смог найти решения. Если ты считаешь что твое решение было единственно правильным то описание твоей задачи в студию.

Описание простое — по некоторому внутреннему представлению данных (оно здесь несущественно) надо формировать соответствующий PMML документ (с его спецификацией можно познакомиться на www.dmg.org) задаваемой юзером версии (1.0, 1.0 MS specific, 1.1). По существу, имеют место две несвязанные иерархии — различные PMML-модели (AssocRules, BivarStats, ClusteringModel и т.д.) одной веросии, имеющие между собой много общего, и иерархия из различных версий PMML, также имеющих между собой много общего. Разумеется, мое решение не является единственно правильным, но оно достаточно хорошо работает и было написано в разумные сроки.

AVK>(Тут товарищи обижаться стали — я не имел ввиду что твоя квалификация недостаточна, может оно действительно так и было. Но приводить подобное в качестве аргумента некорректно, не правда ли?)

Ну в квалификации Страуструпа сомневаться не приходиться, не правда ли? А он придерживается того же мнения — "бриллиантовое" множественное наследование иногда (достаточно редко, к счастью), является необходимым.

S>>В С++ создание автоматического объекта не приводит к созданию новой области видимости. Скобки там можно отдельно от создания объекта написать.

AVK>Так и в юзинге можно. Можешь объект создавать где угодно, иногда так и приходиться делать. Юзинг ограничивает опасную область. Вот такое вполне корректно

AVK>

AVK>MyClass mc = new MyClass();
AVK>...
AVK>using(mc)
AVK>{
AVK> ...
AVK>}

AVK>MyClass mc = null;
AVK>...
AVK>using(mc)
AVK>{
AVK> ...
AVK> mc = new MyClass();
AVK> ...
AVK>}
AVK>

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

S>>>>Угу, это теперь самопальный стандарт. А простой и логичной обработки ошибок я пока не в одном языке не видел. Если этот долбаный рантам иногда молча глотает исключения

AVK>>>Ни разу не сталкивался.

S>>А я вот почти сразу столкнулся.

AVK>Поподробнее можно?

Кода под рукой нет, извини Интернет на работе, эксперименты — дома. Кроме того, я пока до конца не понял, в чем там дело было.

AVK>Исходные коды к примеру генерить можно.

А это уже более сложное средство, чем имеющиеся в С++. Так что не катит.

AVK>Еще можно много чего на лету создавать. В дотнете вобще очень много технологий направленных именно на уменьшение исходного кода. Рефлекшен позволяет кучу вещей делать автоматом а не писать код (в rsdn mag #3 наверное будет статья про конфигурирование, там очень хорошо это видно, добавление новой настройки начинается и заканчивается добавлением свойства к классу настроек. сохранение в xml и гуевый редактор подстраиваются автоматически). Эмиттинг кода позволяет отказаться от генерации всевозможных проксей и стабов, они генеряться на лету. Вот к примеру код создания удаленного объекта в ремоутинге
AVK>

AVK>RemoteClass rc = new RemoteClass();
AVK>

AVK>Давай, напиши на С++ короче. И это не какая то внутренняя фича, так ты можешь сделать и для своей библиотеки.

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

S>> массированному применению Cut'n'Paste

AVK>Это от средства не зависит, это уже уродство дизайна.

От средства тоже. Напиши-ка на ассемблере универсальный двоичный поиск, такой же удобный, как в С++? Херовенькое средство разработки автоматически требует либо более высокой квалификации разработчиков, либо ведет к уродливому дизайну.

AVK>По простоте поддержки и развития С++ с дотнетом и джавой даже рядом не стоял. Тут компоненты рулят.

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

AVK>А вот в дотнете даже хеш-таблицы есть. А шаблонов пока нету. Шаманы наверное.

Не понял. Ну так и для С++ полно реализаций хеш-таблиц, выбирай на любой вкус.

S>> Или вот нет в С++ поддержки мультиметодов

AVK>Это кто ж такие, если не секрет?

Это функции, виртуальные по отношению к более чем одному классу.

AVK>Вот дотнет как раз по своим внутренностям несравненно сложнее С++, а вот пользоваться им проще и удобнее, как и электропилой. Так что очень правильная аналогия .

Я не про дотнет как рантайм говорил, а про убогий C# как язык программирования. Для C++ при желании можно найти (или написать) библиотеки, не уступающие или почти не уступающие по функциональности нету. Хотя кой-чего С++'у как языку, безусловно, не хватает, C# еще хуже.

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

S>Сотни мегабайт исходников транслятора C# или жабы Очень даже смешно. Даже компилятор C++ меньше занимает.

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

AVK>>А полиморфизм тут вобще не причем, множественное наследование интерфейсов есть и в джаве и в дотнете.

S>Я чет не понимаю — только что меня убеждали, что множественное наследование сложная

Сложная для понимания кода, но не для реализации.

AVK>>Давай так — лично ты не смог найти решения. Если ты считаешь что твое решение было единственно правильным то описание твоей задачи в студию.

S>Описание простое — по некоторому внутреннему представлению данных (оно здесь несущественно) надо формировать соответствующий PMML документ (с его спецификацией можно познакомиться на www.dmg.org) задаваемой юзером версии (1.0, 1.0 MS specific, 1.1). По существу, имеют место две несвязанные иерархии — различные PMML-модели (AssocRules, BivarStats, ClusteringModel и т.д.) одной веросии, имеющие между собой много общего, и иерархия из различных версий PMML, также имеющих между собой много общего. Разумеется, мое решение не является единственно правильным, но оно достаточно хорошо работает и было написано в разумные сроки.

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

S>Ну в квалификации Страуструпа сомневаться не приходиться, не правда ли? А он придерживается того же мнения — "бриллиантовое" множественное наследование иногда (достаточно редко, к счастью), является необходимым.

А он что, не может ошибаться в принципе?

AVK>>Так и в юзинге можно. Можешь объект создавать где угодно, иногда так и приходиться делать. Юзинг ограничивает опасную область. Вот такое вполне корректно

AVK>>

AVK>>MyClass mc = new MyClass();
AVK>>...
AVK>>using(mc)
AVK>>{
AVK>> ...
AVK>>}

AVK>>MyClass mc = null;
AVK>>...
AVK>>using(mc)
AVK>>{
AVK>> ...
AVK>> mc = new MyClass();
AVK>> ...
AVK>>}
AVK>>

S>Скобки все равно лишние. Хотя, конечно, привыкнуть можно, если придется.

Как сказать. Очень повышают читаемость, хорошо видно область существования ресурса.


AVK>>Поподробнее можно?

S>Кода под рукой нет, извини Интернет на работе, эксперименты — дома. Кроме того, я пока до конца не понял, в чем там дело было.

А если до конца не понял то не стоит и валить на дотнет.

AVK>>Исходные коды к примеру генерить можно.

S>А это уже более сложное средство, чем имеющиеся в С++. Так что не катит.

Почему не катит? В дотнете ведь есть такое? Да и в С++ при желании такое наворотить можно. А уж во всяких пхп сплош и рядом.

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

Как я уже устал повторять одно и тоже. Нет никакого такого разделения дотнета на компилятор шарпа и рантайм. Оно переплетено очень тесно. Язык шарп в отсутствии своего рантайма не имеет никакого смысла.

AVK>>А вот в дотнете даже хеш-таблицы есть. А шаблонов пока нету. Шаманы наверное.

S>Не понял. Ну так и для С++ полно реализаций хеш-таблиц, выбирай на любой вкус.

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

AVK>>Это кто ж такие, если не секрет?

S>Это функции, виртуальные по отношению к более чем одному классу.

Не понял, если честно. Метод принадлежащий более чем одному классу? А зачем такое?

S>Я не про дотнет как рантайм говорил, а про убогий C# как язык программирования.

Повторяться не буду.

S> Для C++ при желании можно найти (или написать) библиотеки, не уступающие или почти не уступающие по функциональности нету.

Еще один Ты чего реализовывать будешь? GC? Делегатов? Или может еще чего?

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

AVK>По сравнению с различиями NT4 и W2K сущая косметика. Как и XP впрочем.

И это неправда. XP очень заметно переработан внутри.

Здравствуйте <Аноним>, Вы писали:

AVK>>По сравнению с различиями NT4 и W2K сущая косметика. Как и XP впрочем.

А>И это неправда. XP очень заметно переработан внутри.

Да не так уж и переработан. Кое что с драйверами поправили, да с совместимостью поковырялись, вот по большому счету и все.

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

S>>Сотни мегабайт исходников транслятора C# или жабы Очень даже смешно. Даже компилятор C++ меньше занимает.

AVK>Нет там такого разделения как в С++. Рантайм и компиляторы неразделимы в принципе. А сам компилятор конечно небольшой. Только вот с точки зрения компиляции вобще не вижу никакой сложности в поддержке множественного наследования.

А я вижу.

S>>Я чет не понимаю — только что меня убеждали, что множественное наследование сложная

AVK>Сложная для понимания кода, но не для реализации.

Что сложного для понимания в таком коде:

struct coords_pair
{
  coords_pair()  : x_(0), y_(0) {}
  int x_;
  int y_;
};
struct positioned
{
  void org(int x, int y)
  { org_.x_ = x; org_.y = y; }
  coords_pair org() const
  { return org_; }
private:
  coords_pair org_;
};

struct sized
{
  void size(int w, int h)
  { size_.x_ = w; size_.y = h; }
  coords_pair size() const
  { return size_; }
private:
  coords_pair size_;
};

struct shape : sized, positioned
{
};

Никто ведь не заставляет писать сложно там, где можно обойтись простыми средствами. Что, решение с шаблонами для C# будет более простым и читаемым?

AVK>>>Давай так — лично ты не смог найти решения. Если ты считаешь что твое решение было единственно правильным то описание твоей задачи в студию.

S>>Описание простое — по некоторому внутреннему представлению данных (оно здесь несущественно) надо формировать соответствующий PMML документ (с его спецификацией можно познакомиться на www.dmg.org) задаваемой юзером версии (1.0, 1.0 MS specific, 1.1). По существу, имеют место две несвязанные иерархии — различные PMML-модели (AssocRules, BivarStats, ClusteringModel и т.д.) одной веросии, имеющие между собой много общего, и иерархия из различных версий PMML, также имеющих между собой много общего. Разумеется, мое решение не является единственно правильным, но оно достаточно хорошо работает и было написано в разумные сроки.

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

IMHO, хуже получится.

AVK>Да и способ получить почти настоящее множественное наследование я в форум по дотнету кидал.

Попробуй применить его к библиотечным классам.

S>>Ну в квалификации Страуструпа сомневаться не приходиться, не правда ли? А он придерживается того же мнения — "бриллиантовое" множественное наследование иногда (достаточно редко, к счастью), является необходимым.

AVK>А он что, не может ошибаться в принципе?

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

S>>Скобки все равно лишние. Хотя, конечно, привыкнуть можно, если придется.

AVK>Как сказать. Очень повышают читаемость, хорошо видно область существования ресурса.

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

S>>Кода под рукой нет, извини Интернет на работе, эксперименты — дома. Кроме того, я пока до конца не понял, в чем там дело было.

AVK>А если до конца не понял то не стоит и валить на дотнет.

То что исключение было и молча съелось — факт. В каких конкретно условиях это проявляется и управляется ли такое поведение как-нибудь, я пока не знаю. Впрочем, не хочешь — не верь.

AVK>>>Исходные коды к примеру генерить можно.

S>>А это уже более сложное средство, чем имеющиеся в С++. Так что не катит.

AVK>Почему не катит? В дотнете ведь есть такое? Да и в С++ при желании такое наворотить можно. А уж во всяких пхп сплош и рядом.

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

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

AVK>Как я уже устал повторять одно и тоже. Нет никакого такого разделения дотнета на компилятор шарпа и рантайм. Оно переплетено очень тесно. Язык шарп в отсутствии своего рантайма не имеет никакого смысла.

Весьма странное утверждение, однако. Я вон слышал, что ML под дотнет портировали. И что, из-за этого исчезла разница между ML и C# как языками программирования, или ML перестал представлять интерес в отсутствии нетовского рантайма?

AVK>>>А вот в дотнете даже хеш-таблицы есть. А шаблонов пока нету. Шаманы наверное.

S>>Не понял. Ну так и для С++ полно реализаций хеш-таблиц, выбирай на любой вкус.

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

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

AVK>>>Это кто ж такие, если не секрет?

S>>Это функции, виртуальные по отношению к более чем одному классу.

AVK>Не понял, если честно. Метод принадлежащий более чем одному классу? А зачем такое?

Ну, допустим у нас есть такая иерархия: классы A1, A2, A3, A4 наследуются от A (и друг друга, произвольным образом). Требуется функция, (bool foo(A& a, A& b) которая принимает в качестве аргументов 2 (или больше) наследника класса A (по ссылке или указателю) и что-то с ними делает, основываясь на их фактическом типе. Т.е, на самом деле требуются от 1 (когда A и все его наследники обрабатываются одинаково) до 25 функций. Проблема состоит в том, что в течении жизненного цикла программы иерархия может расширяться. Если бы аргумент был один, подошли бы обычные виртуальные функции, а так — полная задница. Т.е. решения есть, но ни простыми, ни удобными их не назовешь.

S>> Для C++ при желании можно найти (или написать) библиотеки, не уступающие или почти не уступающие по функциональности нету.

AVK>Еще один Ты чего реализовывать будешь? GC? Делегатов? Или может еще чего?

GC и делегаты уже успели реализовать Причем делегатами в C++, IMHO, пользоваться удобнее, чем в C# (хотя потроха их реализации кому-то могут показаться весьма неприглядными). Сложность представляет реализация обобщенной сериализации. IMHO, в нынешнем C++ это невозможно. Хотя, про делегаты я тоже раньше так думал...

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

AVK>>>По сравнению с различиями NT4 и W2K сущая косметика. Как и XP впрочем.

А>>И это неправда. XP очень заметно переработан внутри.

AVK>Да не так уж и переработан. Кое что с драйверами поправили, да с совместимостью поковырялись, вот по большому счету и все.

SEH, IMHO, совершенно новый.

A>Конечно. Если к тому времени новый комп соберу .

Хм... Да нормальный у тебя комп для Win2k. Ты только после инсталяции немножко лишних сервисов убей и вообще красота будет
У меня дома Селерон 667 с 390 памяти. ПРи этом ПО куча. Apache+PHP+MySQL, VS 7, Delphi валяеться, MS SQL, вот Оракл даже временно пришлось взгромоздить. И все отлично работает. Главное не запускать все одновременно КОнечно дотнет подтормаживает там при запуске но это не смертельно. Вообще если не только играться, а хоть какой то разработкой заниматься даже в целях обучения непредставляю как можно сидеть на виндоус меньше Win2k.

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

AVK>>>Влад, да бог с ним, пускай работает на 98. Через пару лет все равно NT поставит.
A>>Конечно. Если к тому времени новый комп соберу .
AVK>Тебе и тепиерешнего хватит выше крыши. Я ж тебе пример привел компа под NT 4 на 486 процессоре. Очень неплохо работал.

Я понимаю, что для кого-то это нормально. Кто-то и XP гоняет на 128, да еще и какие-то приложения запускает. Но зачем мне такой eXPerience?

A>>А зачем на домашнем компе офис и 7-ая студия? .
AVK>Так комп то программиста. У меня к примеру есть. А офис — найди мне домашний компьютер без ворда. Очень редко встречаются, скажу тебе по секрету.

А, понял. Конечно, если бы мне студия 7 нужна была, я бы использовал 2000. Что касается офиса, то лично мне он не нужен, но на крайний случай у меня есть дистрибутивы 97 офиса, который прекрасно работает на 95 и 98. 2000-ый тоже под 98 работает. Необязательно же ставить последний ворд, чтобы сделать doc-файл или xls-файл, что, как правило, дома и требуется.

А все программерские пакеты, которые мне нужны, у меня прекрасно работают, начиная от PHP и заканчивая FASM'ом. Если потребуется поставить что-то, необходимое по работе, и идущее только под Win2k и выше, то я и поставлю это на рабочем компьютере .

AVK>>>Дальше будет только хуже.
A>>А... Этих программ уже сейчас — как собак. Выбирай любую.
AVK>Каких программ? Офисов или студий?

Разных. И офисов и студий .

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

A>>Конечно. Если к тому времени новый комп соберу .
A>Хм... Да нормальный у тебя комп для Win2k. Ты только после инсталяции немножко лишних сервисов убей и вообще красота будет
A>Вообще если не только играться, а хоть какой то разработкой заниматься даже в целях обучения непредставляю как можно сидеть на виндоус меньше Win2k.

Легко.

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

AVK>>Нет там такого разделения как в С++. Рантайм и компиляторы неразделимы в принципе. А сам компилятор конечно небольшой. Только вот с точки зрения компиляции вобще не вижу никакой сложности в поддержке множественного наследования.

S>А я вижу.

А зря. Не забывай что очень много работы переложено на рантайм. Для поддержки множественного наследования компилятору достаточно определять его (даже синтаксис менять не надо) и генерировать соотв. семантику, чтобы сказать рантайму от кого класс отнаследован. А вот тот гимор с vtbl о котором ты поминал целиком ложиться на плечи CLR.
Не забывай что множественное наследование интерфейсов компилятор уже поддерживает, а до множественной реализации ему должно быть пофигу, это забота рантайма.

AVK>>Сложная для понимания кода, но не для реализации.

S>Что сложного для понимания в таком коде:

Я тебе могу такого с эти наследованием навернуть что черт голову сломит. А твой кусок кода не сложен для понимания.

S>Никто ведь не заставляет писать сложно там, где можно обойтись простыми средствами. Что, решение с шаблонами для C# будет более простым и читаемым?

Не знаю, как сделать. Я без шаблонов сделал множественную реализацию. Получилось просто и читаемо.

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

S> IMHO, хуже получится.

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

AVK>>Да и способ получить почти настоящее множественное наследование я в форум по дотнету кидал.

S>Попробуй применить его к библиотечным классам.

Никаких проблем. Чем они принципиально отличаются от собственных?

S>Ошибаться он, само собой может, и, я не сомневаюсь, регулярно это делает. Однако его мнение по данному вопросу совпадает с мнением значительной и далеко не худшей части С++ сообщества. Тебе не кажется, что более вероятно, что ошибаешься ты, а не он?

А ты на каком основании говоришь за "значительную и далеко не худшую часть С++ сообщества"?

AVK>>Как сказать. Очень повышают читаемость, хорошо видно область существования ресурса.

S>Ну, так можно договориться до того, что вокруг объявления каждой переменной скобки ставить.

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

S>То что исключение было и молча съелось — факт.

Съесть его мог кто угодно из цепочки вызова.

S>Потому что приводилось это как иллюстрация того, что излишняя сложность инструмента вредна. А доказывает обратное — сложность инструмента иногда позволяет упростить его использование.

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

AVK>>Как я уже устал повторять одно и тоже. Нет никакого такого разделения дотнета на компилятор шарпа и рантайм. Оно переплетено очень тесно. Язык шарп в отсутствии своего рантайма не имеет никакого смысла.

S>Весьма странное утверждение, однако. Я вон слышал, что ML под дотнет портировали. И что, из-за этого исчезла разница между ML и C# как языками программирования, или ML перестал представлять интерес в отсутствии нетовского рантайма?

Нет. Я говорю только про шарп. Шарп разрабатывался исключительно под CLR и очень сильно заточен именно под него. И рассматривать его в отрыве от рантайма бессмысленно. А то что старые языки можно выполнять в дотнете ничего не доказывает. Тут либо остаемся без части функциональности либо начинаем править язык (как VB). Правленый язык точно так же в отрыве от CLR смысла не имеет.

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

S>А, вон ты о чем. Так у них оверхед гигантский,

Не такой уж и гигантский на самом деле. Не забывай о том что оверхед на полиморфизме у CLR меньше чем у плюсов. (Там кстати даже не полиморфизм как таковой виноват, самый большой оверхед на создании кучи мелких объектов.).

S> и без шаблонов его не побороть. Или наследование от общего предка/коллбэки и неизбежные при этом тормоза, или шаблоны.

Экий у тебя мир черно-белый. Либо либо. Дженериксы в дотнете это уже не плюсовые шаблоны, в отличие от шаблонов, которые по сути чисто синтаксические изыски, дженериксы в дотнете это реально существующие в рантайме сущности. А способов еще туча. Можно к примеру генерить сортировщики налету. Там результат еще быстрее будет, можно соптимизироваться под реальные данные и выбрать в зависимости от них. И уж точно не медленней.

AVK>>Не понял, если честно. Метод принадлежащий более чем одному классу? А зачем такое?

S>Ну, допустим у нас есть такая иерархия: классы A1, A2, A3, A4 наследуются от A (и друг друга, произвольным образом). Требуется функция, (bool foo(A& a, A& b) которая принимает в качестве аргументов 2 (или больше) наследника класса A (по ссылке или указателю) и что-то с ними делает, основываясь на их фактическом типе. Т.е, на самом деле требуются от 1 (когда A и все его наследники обрабатываются одинаково) до 25 функций. Проблема состоит в том, что в течении жизненного цикла программы иерархия может расширяться. Если бы аргумент был один, подошли бы обычные виртуальные функции, а так — полная задница. Т.е. решения есть, но ни простыми, ни удобными их не назовешь.

И чем тут тебе помогут общие для нескольких классов методы?

Да, на дотнете такое реализуемо. Сдергиваем код метода и генерим на его основе новый класс.

AVK>>Еще один Ты чего реализовывать будешь? GC? Делегатов? Или может еще чего?

S>GC и делегаты уже успели реализовать

Доктор, я жить буду? Будете, больной, но хреновооо!

S> Причем делегатами в C++, IMHO, пользоваться удобнее, чем в C# (хотя потроха их реализации кому-то могут показаться весьма неприглядными).

Ага, проще некуда. Я аж заплакал.

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

A>>>Конечно. Если к тому времени новый комп соберу .
A>>Хм... Да нормальный у тебя комп для Win2k. Ты только после инсталяции немножко лишних сервисов убей и вообще красота будет
A>>Вообще если не только играться, а хоть какой то разработкой заниматься даже в целях обучения непредставляю как можно сидеть на виндоус меньше Win2k.

A>Легко.

Я переполз на NT4 еще в 95 году, как только появились деньги 64М памяти. И работу в Дельфях в 95 вспоминаю только с содраганием. Малейшие ошибки с распределением памяти и перезагрузка. За час бывало раз по 10 приходилось перегружаться. А еще как то один товарищ, так же писавший на 95 решил у меня запустить свой проект, который он считал отлаженым. Когда посыпались ахесы виолатьены он был очень удивлен.

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

A>Я понимаю, что для кого-то это нормально. Кто-то и XP гоняет на 128, да еще и какие-то приложения запускает. Но зачем мне такой eXPerience?

При чем тут кто то? W2K будет быстрее 98 на 384М памяти на любой современной конфигурации. Тебе толпа народа говорит, а ты все никак не поверишь.

A>А, понял. Конечно, если бы мне студия 7 нужна была, я бы использовал 2000. Что касается офиса, то лично мне он не нужен, но на крайний случай у меня есть дистрибутивы 97 офиса, который прекрасно работает на 95 и 98. 2000-ый тоже под 98 работает. Необязательно же ставить последний ворд, чтобы сделать doc-файл или xls-файл, что, как правило, дома и требуется.

Для дома обычно требуется не делать, это как раз обычно на работе. Для дома надо обычно читать. И вот когда процентов 50 документов твой ворд перестанет понимать тогда ты и поставишь таки свежую версию.

A>А все программерские пакеты, которые мне нужны, у меня прекрасно работают, начиная от PHP и заканчивая FASM'ом.

Это пока.

A> Если потребуется поставить что-то, необходимое по работе, и идущее только под Win2k и выше, то я и поставлю это на рабочем компьютере .

Все равно заставит тебя МС перейти на НТ, даже не сомневайся. Я думаю отдел разработки линейки 9Х они уже закрыли. И слава богу, меньше зоопарк.

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

AVK>>Да не так уж и переработан. Кое что с драйверами поправили, да с совместимостью поковырялись, вот по большому счету и все.

S>SEH, IMHO, совершенно новый.

Возможно. Но это все куски. Ничего кардинально нового. XP это скорее всего тот же W2K, но его выпустить торопились (сколько его лет делали?) и кое что осталось недоработанным. Они все что хотели доделали и выпустили ХР. В следующей версии опять обещают что то кардинально иное. К примеру файловую систему на sql server.

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

AVK>А зря. Не забывай что очень много работы переложено на рантайм. Для поддержки множественного наследования компилятору достаточно определять его (даже синтаксис менять не надо) и генерировать соотв. семантику, чтобы сказать рантайму от кого класс отнаследован. А вот тот гимор с vtbl о котором ты поминал целиком ложиться на плечи CLR.
AVK>Не забывай что множественное наследование интерфейсов компилятор уже поддерживает, а до множественной реализации ему должно быть пофигу, это забота рантайма.

Не знаю, в исходники CLR пока не лазил. Может, ты и прав.

AVK>>>Сложная для понимания кода, но не для реализации.

S>>Что сложного для понимания в таком коде:

AVK>Я тебе могу такого с эти наследованием навернуть что черт голову сломит. А твой кусок кода не сложен для понимания.

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

S>>Никто ведь не заставляет писать сложно там, где можно обойтись простыми средствами. Что, решение с шаблонами для C# будет более простым и читаемым?

AVK>Не знаю, как сделать. Я без шаблонов сделал множественную реализацию. Получилось просто и читаемо.

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

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

S>> IMHO, хуже получится.

AVK>Ничего не могу сказать, зависит от специфики. Но не факт что хуже. Может и лучше. Лишние взаимосвязи никогда полезными не были. Решение же с МН очень сильно классы связывает.

Иногда это даже хорошо. В том случае, если most derived класс имеет смысл сам по себе, а его родительские классы самостоятельного смысла не имеют.

Ну вот маленький примерчик:

struct A
{
    A(std::ostream &f) : f_(f) {}
protected:
    virtual void CreateHeader() = 0;
    virtual void CreateBody() = 0;
    virtual void CreateFooter() = 0;
    ... И еще 33 функции
    void Generate()
    {
        CreateHeader();
        CreateBody();
        CreateFooter();
        ... На самом деле тут куда более хитрый алгоритм
    }
    std::ostream &f_;
    ... И еще 33 члена данных, которые используются виртуальными функциями.
};

struct V1 : virtual A
{
    V1(std::ostream &f) : A(f) {}
protected:
    virtual void CreateHeader();
    virtual void CreateFooter();
};

struct V2 : virtual A
{
    V2(std::ostream &f) : A(f) {}
protected:
    virtual void CreateHeader();
    virtual void CreateFooter();
};

struct M1 : virtual A
{
    M1(std::ostream &f) : A(f) {}
protected:
    virtual void CreateBody();
};

struct M2 : virtual A
{
    M2(std::ostream &f) : A(f) {}
protected:
    virtual void CreateBody();
};

struct M1V1 : virtual M1, virtual V1
{
    M1V1(std::ostream &f) : M1(f), V1(f) {}
};

struct M1V2 : virtual M1, virtual V2
{
    M1V2(std::ostream &f) : M1(f), V2(f) {}
};

struct M2V1 : virtual M2, virtual V1
{
    M2V1(std::ostream &f) : M2(f), V1(f) {}
    virtual void CreateHeader(); // Тут от нас другой хедер требуется
};

struct M2V2 : virtual M2, virtual V2
{
    M2V2(std::ostream &f) : M2(f), V2(f) {}
    virtual void CreateFooter(); // А тут - другой footer.
};

AVK>>>Да и способ получить почти настоящее множественное наследование я в форум по дотнету кидал.

S>>Попробуй применить его к библиотечным классам.

AVK>Никаких проблем. Чем они принципиально отличаются от собственных?

Тем, что их нельзя менять. Или твое решение — не то, что Влад в этой ветке приводил (правда, с ашипками, как обычно)? Если то, то тебе руками придется каждый вызов члена библиотечного класса оборачивать.

S>>Ошибаться он, само собой может, и, я не сомневаюсь, регулярно это делает. Однако его мнение по данному вопросу совпадает с мнением значительной и далеко не худшей части С++ сообщества. Тебе не кажется, что более вероятно, что ошибаешься ты, а не он?

AVK>А ты на каком основании говоришь за "значительную и далеко не худшую часть С++ сообщества"?

А тебе не кажется, что говорить от чьего-то имени и ссылаться на чье-то мнение — это несколько разные вещи?

AVK>Съесть его мог кто угодно из цепочки вызова.

Во-во. Я не ел, кто-то съел по дороге, кто и на каком основании — не понятно.

S>>Потому что приводилось это как иллюстрация того, что излишняя сложность инструмента вредна. А доказывает обратное — сложность инструмента иногда позволяет упростить его использование.

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

Шарп как язык — черезмерно простой. Рантайм, который он использует — сложный. Так понятнее?

AVK>>>Как я уже устал повторять одно и тоже. Нет никакого такого разделения дотнета на компилятор шарпа и рантайм. Оно переплетено очень тесно. Язык шарп в отсутствии своего рантайма не имеет никакого смысла.

AVK>Нет. Я говорю только про шарп. Шарп разрабатывался исключительно под CLR и очень сильно заточен именно под него. И рассматривать его в отрыве от рантайма бессмысленно.

Бред. Язык он и есть язык. Что, если рантайм смениться, изменится синтаксис шарпа и семантика написанных на шарпе программ? Ты не путай язык с его реализацией. Допустим, мы выкидываем из языка шарпа using statement и требуем руками вызывать финалайз. Заточенность на рантайм сохранилась, язык стал хуже.

AVK>А то что старые языки можно выполнять в дотнете ничего не доказывает. Тут либо остаемся без части функциональности либо начинаем править язык (как VB). Правленый язык точно так же в отрыве от CLR смысла не имеет.

Без части функциональности чего? Языка? Не верю. Дотнета? Вполне, не всем она целиком нужна.

AVK>Не такой уж и гигантский на самом деле. Не забывай о том что оверхед на полиморфизме у CLR меньше чем у плюсов.

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

AVK>(Там кстати даже не полиморфизм как таковой виноват, самый большой оверхед на создании кучи мелких объектов.).

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

S>> и без шаблонов его не побороть. Или наследование от общего предка/коллбэки и неизбежные при этом тормоза, или шаблоны.

AVK>Экий у тебя мир черно-белый. Либо либо. Дженериксы в дотнете это уже не плюсовые шаблоны, в отличие от шаблонов, которые по сути чисто синтаксические изыски, дженериксы в дотнете это реально существующие в рантайме сущности.

Значит, все еще хуже, чем я думал.

AVK>А способов еще туча. Можно к примеру генерить сортировщики налету. Там результат еще быстрее будет, можно соптимизироваться под реальные данные и выбрать в зависимости от них. И уж точно не медленней.

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

AVK>>>Не понял, если честно. Метод принадлежащий более чем одному классу? А зачем такое?

S>>Ну, допустим у нас есть такая иерархия: классы A1, A2, A3, A4 наследуются от A (и друг друга, произвольным образом). Требуется функция, (bool foo(A& a, A& b) которая принимает в качестве аргументов 2 (или больше) наследника класса A (по ссылке или указателю) и что-то с ними делает, основываясь на их фактическом типе. Т.е, на самом деле требуются от 1 (когда A и все его наследники обрабатываются одинаково) до 25 функций. Проблема состоит в том, что в течении жизненного цикла программы иерархия может расширяться. Если бы аргумент был один, подошли бы обычные виртуальные функции, а так — полная задница. Т.е. решения есть, но ни простыми, ни удобными их не назовешь.

AVK>И чем тут тебе помогут общие для нескольких классов методы?

Где я говорил про "общие для нескольких классов методы"? Ты что-то не так понял.

AVK>Да, на дотнете такое реализуемо. Сдергиваем код метода и генерим на его основе новый класс.

Я чего-то идею не понял. Примерчик можно?

AVK>>>Еще один Ты чего реализовывать будешь? GC? Делегатов? Или может еще чего?

S>>GC и делегаты уже успели реализовать

AVK>Доктор, я жить буду? Будете, больной, но хреновооо!

Поясни.

S>> Причем делегатами в C++, IMHO, пользоваться удобнее, чем в C# (хотя потроха их реализации кому-то могут показаться весьма неприглядными).

AVK>Ага, проще некуда. Я аж заплакал.

Хм.. Ты их, наверное, просто не видел.

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

AVK>Влад, да бог с ним, пускай работает на 98. Через пару лет все равно NT поставит. 95 не поддерживается, а 98, 98SE и ME отличаются только косметикой. Офис вон уже не работает. 7 студия тоже. Дальше будет только хуже.

Да нет. И офис и студия работают. Сам пробывал. Вот только тормоза почище W2k. Эта уродливая ОС попросту не знает что делать с 256 мегами памяти. Ее же на 16-64 оптимизировали. 95 вообще 16 мег за благо считали.

Здравствуйте, <Аноним>, Вы писали:

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

AVK>>Влад, да бог с ним, пускай работает на 98. Через пару лет все равно NT поставит. 95 не поддерживается, а 98, 98SE и ME отличаются только косметикой. Офис вон уже не работает. 7 студия тоже. Дальше будет только хуже.

А>Насчет 98 и 98SE — не согласен. Очень существенные различия, например, в работе с сетью, и в SE много меньше ошибок. ME — просто дрянь, несмотря на косметику.

Согласен, но это не оправдывает цепляние за эти устаревшие ОС. Даже 98SE — это полное дерьмо по сравнению даже с NT4 SP6. О W2k и ХаРэ вообще разговору быть не может. Ну а аргументация про тормоза вообще смешна. Машина с 800 мегагерцами и почти 400 мегами памяти видите ли слаба!

Здравствуйте, <Аноним>, Вы писали:

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

AVK>>По сравнению с различиями NT4 и W2K сущая косметика. Как и XP впрочем.

А>И это неправда. XP очень заметно переработан внутри.

А вот это уже фигня. Три сотни билдов. Нового только COM+1.5 и ГУИ.

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

Что-то у меня к пхп начинает предвзятость пояляться. Как не встречу пхп-шника, так какой-то сумашедший дом сразу получается. 350 метров для ХаРэ мало. Нэт дерьмо. В общем нужно срочно что-то в филармонии править.