Здравствуйте Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, VladD2, Вы писали:
ГВ>[ой, много чего писали ]
VD>>На практике обработка ошибок в .NET на порядок поще, логичнее и удобнее чем в С++. Причем это теперь стандарт, а не самопальщина компилторостроителей.
ГВ>Это ECMA-шный-то стандарт?
В С++ нет и такого. Для меня MS — это уже стандарт. Врядли будут компиляторы для .NET не свместмые с .NET.
ГВ>Пока на этом стандарте не будет буковок "ANSI/ISO <ля-ля-ля>" — это фикция (ой, извините за неполиткорректность, это блестящий маркетинговый ход ), а не стандарт. Таких стандартов своих у любой фирмы — вагон и две телеги впридачу.
Правильно! Вот Штаты — это круто а европа — дерьмо. Только вот мне это хыть бы.
ГВ>Пока вместе с MS на одном поле не начнут играть киты типа IBM и Hewlett-Packard, все эти разговоры о "стандарте" — демагогия чистой воды.
Расслябься. Hewlett-Packard уже начал. IBM тоже попыжится и начнет. Кому охата бабки терять?
ГВ>Поясняю свою оценку. В принципе-то да, принятие стандарта позволяет клонировать разработку MS другим производителям, но оригинал улетит за это время ещё неизвестно куда, и неизвестно во что превратится. То есть в данном случае стабильность этого стандарта — от силы полгода-год. И шо це за стандарт?
Да плевать мне на опен сорс. Мне ешать нужно. Я стандарт имел в виду в том смысле, что в .NET определено как нужно обрабоатывать и генерировать исключения. И все языки будут делать это именно так. Причем даже не важно будет ли это соотвествать ECMA CLI или нет.
А вот в С++ с этим беда. Его создатели как черт ладана боятся говорить о рантайме. Принцип реализации исключений не определен и каждый лепит реализацию как хочет. А мир уже изменился. Сегданя совместимости на уровне исходников недосточно!
Здравствуйте, VladD2, Вы писали:
VD>>>На практике обработка ошибок в .NET на порядок поще, логичнее и удобнее чем в С++. Причем это теперь стандарт, а не самопальщина компилторостроителей.
ГВ>>Это ECMA-шный-то стандарт?
VD>В С++ нет и такого.
Да ну? А "ANSI/ISO-IEC 14882:1998" ? Единственно в чём ты прав, так это в том, что среди производителей компиляторов согласованности нет.
VD>Для меня MS — это уже стандарт. Врядли будут компиляторы для .NET не свместмые с .NET.
Тоже аргумент.
ГВ>>Пока на этом стандарте не будет буковок "ANSI/ISO <ля-ля-ля>" — это фикция (ой, извините за неполиткорректность, это блестящий маркетинговый ход ), а не стандарт. Таких стандартов своих у любой фирмы — вагон и две телеги впридачу.
VD>Правильно! Вот Штаты — это круто а европа — дерьмо. Только вот мне это хыть бы.
Да нет, просто в ANSI организаций-членов ( ) больше, чем в ECMA. Как я понимаю, раз эдак в тридцать...
ГВ>>Пока вместе с MS на одном поле не начнут играть киты типа IBM и Hewlett-Packard, все эти разговоры о "стандарте" — демагогия чистой воды.
VD>Расслябься. Hewlett-Packard уже начал. IBM тоже попыжится и начнет. Кому охата бабки терять?
Я бы так уверенно не говорил. IBM очень уж большие ставки на Java делает.
ГВ>>Поясняю свою оценку. В принципе-то да, принятие стандарта позволяет клонировать разработку MS другим производителям, но оригинал улетит за это время ещё неизвестно куда, и неизвестно во что превратится. То есть в данном случае стабильность этого стандарта — от силы полгода-год. И шо це за стандарт?
VD>Да плевать мне на опен сорс. Мне ешать нужно. Я стандарт имел в виду в том смысле, что в .NET определено как нужно обрабоатывать и генерировать исключения. И все языки будут делать это именно так. Причем даже не важно будет ли это соотвествать ECMA CLI или нет.
Ну вот я и говорю, что стандарт де-факто будет устанавливаться только MS, а не ECMA. Так что, не знаю, что там в размере крутизны Штатов супротив Европы, а вот ECMA супротив MS...
VD>А вот в С++ с этим беда. Его создатели как черт ладана боятся говорить о рантайме. Принцип реализации исключений не определен и каждый лепит реализацию как хочет. А мир уже изменился. Сегданя совместимости на уровне исходников недосточно!
Хорошо бы сначала её получить, а потом рассуждать о достаточности...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте Геннадий Васильев, Вы писали:
ГВ>Да ну? А "ANSI/ISO-IEC 14882:1998" ? Единственно в чём ты прав, так это в том, что среди производителей компиляторов согласованности нет.
У меня стандарта нет. Так что приведи пункты где говорится о обем бинарном формате. Плиз.
ГВ>Да нет, просто в ANSI организаций-членов ( ) больше, чем в ECMA. Как я понимаю, раз эдак в тридцать...
Ну и скорость реакции во столько же раз менше.
VD>>Расслябься. Hewlett-Packard уже начал. IBM тоже попыжится и начнет. Кому охата бабки терять?
ГВ>Я бы так уверенно не говорил. IBM очень уж большие ставки на Java делает.
Он и на полуось стаки далела. Они вообще теперь на все ствят. А про Хюлет — это уже 100%.
ГВ>Ну вот я и говорю, что стандарт де-факто будет устанавливаться только MS, а не ECMA. Так что, не знаю, что там в размере крутизны Штатов супротив Европы, а вот ECMA супротив MS...
А я хоть слово про ECMA вообще говорил? Хотя любая независимая стандартизация — это хорошо.
VD>>А вот в С++ с этим беда. Его создатели как черт ладана боятся говорить о рантайме. Принцип реализации исключений не определен и каждый лепит реализацию как хочет. А мир уже изменился. Сегданя совместимости на уровне исходников недосточно!
ГВ>Хорошо бы сначала её получить, а потом рассуждать о достаточности...
Я что-то не пойму что ты плучить не можешь? Я вот без проблем генерирую исключение в MC++ и ловлю в Шарпе.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте Геннадий Васильев, Вы писали:
ГВ>>Да ну? А "ANSI/ISO-IEC 14882:1998" ? Единственно в чём ты прав, так это в том, что среди производителей компиляторов согласованности нет.
VD>У меня стандарта нет. Так что приведи пункты где говорится о обем бинарном формате. Плиз.
А я ничего и не говорил о бинарном стандарте на C++. Да и откуда он возьмётся для языка высокого уровня? Я говорил о неправомерности апелляции к стандарту ECMA, как к документу, сохраняющему значимость на протяженном отрезке времени. Что называется, прочувствуйте разницу.
ГВ>>Да нет, просто в ANSI организаций-членов ( ) больше, чем в ECMA. Как я понимаю, раз эдак в тридцать...
VD>Ну и скорость реакции во столько же раз менше.
Вопрос: кому нужны стандарты, меняющиеся как погода осенью?
[...]
VD>Он [IBM] и на полуось стаки далела. Они вообще теперь на все ствят. А про Хюлет — это уже 100%.
Всё равно, пока что сомневаюсь, что IBM перейдёт в разряд адептов .NET. Ну, да это уже моё личное мнение. Что в IBM думают по этому поводу — .
ГВ>>Ну вот я и говорю, что стандарт де-факто будет устанавливаться только MS, а не ECMA. Так что, не знаю, что там в размере крутизны Штатов супротив Европы, а вот ECMA супротив MS...
VD>А я хоть слово про ECMA вообще говорил? Хотя любая независимая стандартизация — это хорошо.
Насколько я помню, стандарт CLI существует только в ECMA-шном исполнении. Отсюда при упоминании тобой термина "стандарт" я сразу и вспомнил про ECMA.
Про "независимую стандартизацию" в данном случае ничего определённого сказать не могу. Напоминаю только, что Win16 API...
ГВ>>Хорошо бы сначала её получить, а потом рассуждать о достаточности...
VD>Я что-то не пойму что ты плучить не можешь? Я вот без проблем генерирую исключение в MC++ и ловлю в Шарпе.
Было бы странно, если бы было иначе. А я хочу получить совместимость на уровне исходников (полную совместимость хотя бы для множества ANSI-C++!) для разных реализаций С++.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Ну, вероятно, не классами, а всё-таки — экземплярами.
В начале я использовал "объект класса", потом оставил "класс". Под влиянием NET.
Конечно, атрибуты — это метаданные отдельного объекта класса. Причем, атрибуты отдельных объектов класса могут быть совершенно независимы и могут не иметь отношения к классу как таковому (в NET это не так).
Соответственно, описание метаданных должно быть привязано к отдельному объекту. А это уже неэффективно с точки зрения организации системы. Те же VB или Скрипты имеют TypeInfo на каждый свой объект.
Вообще, мне кажется, атрибутное программирование и компонентное — исключающие друг друга. Не находите?
[Эмоции поскипаны]
VD>Кто что делает? Ты перечитай еще разок мои постинги. А шаблоны действительно позволяют эмулировать множественное наследование.
VD>class C : A< B< C > {};
Не въехал. У меня есть два библиотечных (читай — неизменяемых) классов A1 и B1. У класса A есть функция a(), у B — b(). Мне надо, чтоб обе они были у C. Твой пример я понял так:
template <class Tb>
struct A : public A1
{
int a();
};
template <class Ta>
struct B : public B1
{
int b() const;
};
class C: public A< B<C> > {};
Но тут эмуляции множественного наследования нет, класс C имеет только функцию int a();
VD>В С а тем более асм-е наследования неблыло вообще. Так что не надо. К тому же ты прекрасно знаешь все проблемы множественного
наледования.
Угу, не было, в том числе и множественного не было. Поэтому его отсутствие — шаг назад, к тем языыкам, где его не было.
S>>Какие именно? Проблемы я пока видел только от "бриллиантового" множественного наследования. Вот его вполне можно и из С++ исключить, хотя и для него есть вполне оправданная область применения.
VD>Дублирование наследников, проблемы при приведении типов, молопонятные сообщения компиляторов и еще много чего. А облость применения можно найти для любых извращений.
Включение в наследников членов-данных предков — не побочный, а прямой эффект. Это именно то, что требуется при множественном наследовании (да и при агрегации). Проблему дублирование представляет только при "бриллиантовом" наследовании, которое здравомыслящие люди используют только при крайней необходимости. Но даже при "бриллиантовом" наследовании дублирование контролируемое — с помощью виртуального наследования. Проблем при приведении типов, честно говоря, я не замечал. Малопонятных сообщений компиляторов я тоже не замечал — по сравнению с тем заклинаниями, что VC выдает для шаблонов, все прозрачно как слеза комсомолки.
S>>ATL, IMHO, демонстрирует, что в команде его разработчиков максимум один человек более-менее проникся C++ и ООП, а остальные там махровые сишники.
VD>Ага. Я бы сказал бы ламеры. И почему только эти неотесанные программисты так его любят? Если серьезно, то вообще не ясно почему ATL нужно оценивать с точки зрения ОО (хотя и с этой точки зрения там все впорядке).
Не охота ATL по второму разу обсуждать . Ну ладно — там полно "грязного" кода в сишном стиле, там куча ошибок и утечек (особенно в OLE DB шаблонах и в хосте для ActiveX контролов), премерзкая реализация синков событий (мля, ну обернули бы в класс, запасающий куку — нет, самому приходится делать). Половину генерированного визардом кода приходится переписывать руками. Включение макроса _ATL_DEBUG_INTERFACES приводит к появлению AV время от времени — Release обектов начинает производить обращение к уже освобожденной памяти, если страница успела выгрузиться — иммедиате кирдык. А любят этот глючный ATL только потому, что нет ничего лучшего да еще за большую, по сравнению с MFC, гибкость и удобство. На безрыбье, так сказать...
S>>Ну а я не считаю агрегацию более простым методом, чем множественное наследование.
VD>От нее нет таких проблем как от наследования. К тому же она может производиться в рантайме.
Ну тут как раз неразрешимое противоречие — или в рантайме, или C++. Мне удобнее, чтоб ошибки с типами компилятор искал. Если надо будет в рантайме, я выберу другой язык.
S>>Поддержка агрегации компилятором (языком) может, и не помешала бы. Однако нафига иметь в языке два средства, делающие одно и то же?
VD>Дык это не одно и тоже. У тебя получется с одной стороны дерево типов. С другой решается проблема повторного использования кода.
Проблема повторного использования кода решается в обоих случаях, дерево типов получается в обоих случаях (хотя и несного разное) — от интерфейса все равно наследоваться надо. Или ты про что-то другое? Нов принципе да, не совсем одно и то же, хотя и очень похоже.
S>>Это вопрос удобства, а не просто привычка. Ручная очистка ресурсов там, где раньше была автоматическая — шаг назад.
VD>Для стековых переменных есть using. Так что жтого даже не замечаешь.
using, конечно, частично исправляет ситуацию. Но он вводит область видимости, что не всегда удобно.
VD>Ну а для не стековых при наличии GC детерминированную финализацию обеспечить невозможно. Так что это компромис. Но я лично на своей шкуре прочуствовал насколько лучше такое решение чем "автоматическое" из С++. Дело в том, что память теряется куда чаще чем другие ресурсы. И ловить ее потери куда сложенее. Незарытый файл или хэндл проявляются довольно быстро, а вот утечки памяти — это бичь почти всех Win32-программ. К тому же с программиста как минимум снимается куча обязанностей по контролю.
У меня несколько другой опыт — в C++ программах обычно вполне хватает рефкаутинга (умные указатели), при этом время жизни объекта остается детерменированным. Я уже не помню, когда последний раз в своем коде утечки памяти искал. А вот утечки хэндлов зачастую проявляются тогда, когда про код, в котором они возникают, все и думать забыли. Поэтому мне GC не нравится в принципе. Если уж даже Страуструп утверждает, что когда в С++ появится GC (причем добавляет "когда, а не если"), деструкторы для коллектнутых объектов вызываться не будут, то нафиг мне такой GC не нужен.
S>>>>argument-dependent name lookup,
VD>>>Это я вообще не понял, что такое?
S>>В MSDN загляни, оно там описано.
VD>Где там? Что оно? Может по русски?
Там — это в MSDN. Оно — это argument-dependent name lookup. Задаешь поиск по фразе "argument-dependent name lookup", находишь в C++ language reference пункт 3.4.2 — Argument-Dependent Name Lookup. Объяснять, тем более по русски, долго.
S>>Когда один класс должен использовать одноименные классы из разных неймспейсов (особенно если внутри одной функции), просто необходимая вещь. Без него — только полная квалификация имен.
VD>Вот я тебе и горю. Надуманная проблема. В жизни не всречается. По крайнй мере мне не всретилать пока.
Так тебе и неймспейсы, получается, не нужны, раз и без них имена не пересекаются. Хотя, конечно, в шарпе алиасы есть, но они нарушают локальность — в одном месте объявляем, через 500 строк используем.
S>>Даже в VC 6.0 есть. using действует до конца области видимости — если оно не так, то это ошибак в компиляторе.
VD>Ты про using namspace?
И про using namspace тоже. Но в основном, конечно, про using Namespace_name::Name (типа using std::vector). using namspace опасен, поскольку открывает все имена из неймспайса, даже те, про которые ты не знаешь.
VD>>>Уж лучще добавить With как в VB. Чтобы к членам объектов можно было обращаться через одну точку.
S>>Вот-вот, совершенно другая вещь, а назвали так же (и тем самым запретили тот, другой using). Уроды.
VD>В данном случае согласен. Могли бы придумать другое название. Но это они по Струструпу. Чтобы не создавать дополнительных ключевых слов. Помнишь историю про = 0 для абстрактных методов вместо слова abstract? Тоже по уродски было и аргументировалось так же.
Страуструпа совместимость с существующим кодом держала, в том числе сишным, и за каждое ключевое слово сишники пинали. C# — новый язык, создаваемый с нуля, при его разработке таких проблем не было.
S>>И что такого уродливого в указателях на методы класса? Совершенно логичная штука. Не, я не против, что бы в язык добавили чего-нибудь типа closure, но и без них не плохо.
VD>Ну тогда может ты приведешь мне пример отличный от эмуляции делегатов (что тоже делает через одно место). А? Уродливо именно то что из полезного и удобного средства в С указатели на функции превратились в безмолезные уродливые кострукции.
Ну были у меня ситуации, когда у класса функция должна делать разные вещи в зависимости от содержимого членов. Причем должна работать быстро (правило к таблице применить). Самым простым и прямым решением оказалось применение указателей на функции. Одно длинное сравнение, потом 10000 косвенных вызовов. Еще для эмуляции vtbl полезно — посмотреть можно здесь: http://oonumerics.org/tmpw01/alexandrescu.pdf. В общем, указатели на функции-члены нужны в случаях, когда применение виртуальных функций и иерархий классов затруднено, избыточно или чересчур дорого.
S>>Это кому как. Если я знаю, что сейчас в вектор или стрим буду много-много мегабайт запихивать, а потом все освобожу одним куском, то ручной распределитель памяти дает ускорение иногда аж в 500-1000 раз (C++ код, 30 мег данных пишутся в стрим в памяти).
VD>Дык по сравнению с GC никакого выигрыша не будет. Там попросту нет освобождения пмяти. Она только занимается. Процесс сборки мусора происходит редко и тоже делается одним махом. Причем всгде, а не только в некторых случаях. В общем — это уже точно привычка, а не разумное требование.
Не, к GC тот случай отношения не имеет. Я просто точно знал, как работает (конкретно — как именно выделяет и копирует память) стрим (это был мой стрим), поэтому мог применять VirtualAlloc и MoveMemory вместо хиповских функций. MoveMemory, насколько я понимаю, работает достаточно умно и в случае, если двигается целая страница, физического копирования не производит, а просто меняет таблицу дескрипторов памяти, подставляя одну физическую страницу по разным виртуальным адресам. Поскольку после копирования скопированная страница сразу освобождалась, никакого Copy-On-Write не было. За счет этого — гигансткий рост производительности.
S>>А все проблемы и так всегда мои, если программу пишу я, а не MS Мне надо что-то вроде C++'ного uncaught_exception в деструкторе и нормальные деструкторы вместо finally, который все ООП рушит нафиг.
VD>Чего он рушит? Это в С++ уродство полное. Надо же было не включить в стадарт finally! Почти все компиляторы это дело встроили, а Страуструп не чешется.
Деструкторы выглядят куда логичнее в ООП-языке. Вся очистка ресурсов делается классами-обертками. finally же поощряет не-ООПный стиль. Кроме того, если я в finally буду вызывать какие-то библиотечные функции, которые могут кинуть новое исключение, мне каждый такой вызов придется заворачивать в try/catch и код станет совершенно нечитаемым. В С++ я эти try/catch могу спрятать внутри деструкторов, вызов деструкторов руками прописывать не надо, кода меньше — ошибок меньше.
VD>На практике обработка ошибок в .NET на порядок поще, логичнее и удобнее чем в С++. Причем это теперь стандарт, а не самопальщина компилторостроителей.
Угу, это теперь самопальный стандарт. А простой и логичной обработки ошибок я пока не в одном языке не видел. Если этот долбаный рантам иногда молча глотает исключения (то ли в интеропе он это делает, то ли еще когда, я пока не разобрался), часть ошибок (все та же неочистка ресурсов, например) просачивается в релиз.
VD>В С++ исключение живет в пределах одного модуля, нельзя намисать код обрабоки на VC, а лволи на BCC.
Есть такая проблема. Без стандартизации рантайма не решается. Но рантайм нельзя стандартизировать в рамках языка общего назначения, максимум, что можно сделать — стандартизировать рантайм в рамках языка и платформы. Так что опять производители компиляторов и, конечно же, горячо любимая MS, виноваты — так и не договорились, падлы.
S>>Хе-хе, вон в C++ спорные места до сих пор находят,
VD>Нехрена было все так усложнять. Тогда и спорных мест не было бы.
Их иногда находят в самых простых местах
Как тебе такой пример:
int main()
{
bool a;
bool b = a;
if (b == a)
return 0;
else
return 1;
}
Вопрос — что должна по стандарту возвращать программа? Тебе понравиться, если, будучи скомпилированной разными компиляторами, она будет давать разные результаты? Такие дыры — следствие не черезмерной сложности языка, а плохой разработки нормативных документов. В стандартах тоже надо баги искать.
S>> а ты говоришь, что я, практически незнакомый с C#, за один раз все спорные места в нем нашел
VD>А я тебе говрю, что в Шарпе все просто как три копейки. Для того он и делался.
Я не говорю, что там сложно, я говорю, что если это стандартизированный язык и подразумевается создание сторонних компиляторов, то в стандарте дыр быть не должно. А если сторонних компиляторов не будет, нафига стандарт?
S>>И которая хуже воровства Ну не делаются сложные вещи простыми инструментами, и все тут. Вернее, делаются, он это сложнее, чем делать их более сложным инструментом.
VD>И ты говоришь что это не демагогия?
Это мое убеждение, основанное на личном опыте. Возможно, оно выглядит как демагогия, но обосновывать его чересчур долго и не интересно.
VD>>>Насклоько они будут мощны я пока не знаю. Но даже если они будут на уровне VC6, меня это устроит.
S>>А меня, к сожалению, нет.
VD>Дык првильно! Тебе же на них кривой язык переписывать. А мне просто не зависимые от конкретных типов алгортмы писать.
Я на них метапрограммировать хочу Это примерно как ты на С# подсел
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте Sergey, Вы писали:
S>Угу, не было, в том числе и множественного не было. Поэтому его отсутствие — шаг назад, к тем языыкам, где его не было.
И джава и object паскаль моложе плюсов. У обоих множественного наследования нет. Что это все так дружно назад шагают, не знаешь?
S>Но даже при "бриллиантовом" наследовании дублирование контролируемое — с помощью виртуального наследования.
Это называется создаем себе проблемы а потом начинаем их решать.
S>using, конечно, частично исправляет ситуацию. Но он вводит область видимости, что не всегда удобно.
Не понял юмора. Так в плюсах тоже автоматические деструкторы работают по выходу из области видимости.
S>Там — это в MSDN. Оно — это argument-dependent name lookup. Задаешь поиск по фразе "argument-dependent name lookup", находишь в C++ language reference пункт 3.4.2 — Argument-Dependent Name Lookup. Объяснять, тем более по русски, долго.
Классная вещь наверное, что про русски объяснить что это такое очень сложно.
S>Угу, это теперь самопальный стандарт. А простой и логичной обработки ошибок я пока не в одном языке не видел. Если этот долбаный рантам иногда молча глотает исключения
Ни разу не сталкивался.
S>>>И которая хуже воровства Ну не делаются сложные вещи простыми инструментами, и все тут. Вернее, делаются, он это сложнее, чем делать их более сложным инструментом.
VD>>И ты говоришь что это не демагогия?
S>Это мое убеждение, основанное на личном опыте. Возможно, оно выглядит как демагогия, но обосновывать его чересчур долго и не интересно.
А мое убеждение, основанное на личном опыте, противоположное. Потому как когда из-за этих супер-пупер сложностей проект начинает захлебываться в собственной сложности то становиться не до наворотов. Могу тебе рассказать точку зрения с другой стороны, не программера а заказчика. Мне пофигу супер фичи. Мне главное чтобы продукт был написан быстро и при этом в нем не было глюков приводящих к неработоспособности, чтобы он был легко конфигурируем, причем чем больше автоматики тем лучше и легко модернизируем. И чтобы код был понятен даже недоучившемуся студенту. И в гробу я видал этот С++ с его множественным наследованием, крутыми указателями и прочия и прочия.
Здравствуйте Геннадий Васильев, Вы писали:
ГВ>Ёлки! Пока вместе с MS на одном поле не начнут играть киты типа IBM и Hewlett-Packard, все эти разговоры о "стандарте" — демагогия чистой воды.
Хрюклет где то с пару месяцев назад выпустил совместный с мсом пресс-релиз о полной и безоговорочной поддержке дотнета и начале совместных разработок.
Здравствуйте Геннадий Васильев, Вы писали:
ГВ>Вопрос: кому нужны стандарты, меняющиеся как погода осенью?
Поинтересуйся сановскими стандатртами для джавы. Они довольно часто меняются. И даже в ЕСМА не стандартизованы, только комитетом сана. Но это не мешает всему и вся в джава мире иметь между собой вполне приличную совместимость. Хотя и там ляпы случаются, но почти всегда из-за недоделанных стандартов, как это было с EJB 1.0.
Стандарт это не конфетка, не признак крутости и не вещь решающая все проблемы. Стандарт это такая штука которая позволяет продукту А работать совместно с продуктом В когда они созданы разными производителями. И мне пофигу кто круче — ANSI, ISO, IEEE, РСТ или ЕСМА. Главное что ни один производитель в зравом уме не будет писать продукты под дотнет не соответствующие этому стандарту.
ГВ>Было бы странно, если бы было иначе. А я хочу получить совместимость на уровне исходников (полную совместимость хотя бы для множества ANSI-C++!) для разных реализаций С++.
Ну жди. А мы пока по простому, на шарпе будем потихоньку.
Здравствуйте VladD2, Вы писали:
VD>>>В Паскле с этим задница.
AVK>>С чем задница?
VD>С точкой. Вернее без нее.
А, ну да. Но это небольшая и ожидаемая задница.
Лирическое отступление: классификация задниц
Задницы подразделяются по следующим признакам:
1) По величине. Бывают задницы маленькие, задницы средние, задницы большие и полные задницы. Последние встречаются редко, но последствия при этом бывают весьма печальные. Чаще всего встречаются задницы маленькие, но к счастью они как правило не доставляют больших хлопот.
2) По неожиданности. Бывают ожидаемые и неожиданные задницы. Ожидаемая задница встречается редко, ходят они обычно по одиночке, имет свою территорию и редко выходит за ее пределы, при встрече с человеком стараются убежать или спрятаться. Неожиданные задницы, в противоположность, очень часто сбиваются в стаи, которые постоянно меняют свое местоположение. Интересно что в стае встречаются особи разных размеров и окраски. При встрече с человеком не убегают а напротив стараются на него напасть. Таким образом встреча с большой стаей неожиданных задниц очень опасна.
3) По настроению. Бывают радостные задницы, мрачные задницы, скучные задницы и агрессивные задницы. Радостные задницы это как правило особи небольших размеров. Доставляемые ими хлопоты обычно не приводят к плохим последствиям. Мрачные задницы обычно тоже малых или средних размеров, однако заметно более неприятны. Скучные задницы, как и две предыдущих разновидности, невелики по размерам. Их характерная особенность — они пасуться очень большими стаями и завидев человека начинают выпрашивать у него еду. Если вы отвернетесь то они могут и украсть вашу еду. Агрессивные задницы как правило средних и больших размеров. Большинство полных задниц относятся именно к этой разновидности.
AVK>>Есть, я о них тоже подумал. Но в случае джавы и дотнета решение более кардинальное.
VD>И все же те же типизированные коллекции вручную делать очень геморойно. Шаблоны бы очень даже пригодились бы.
Ну разве что в для этого, они для этого изначально и задумывались. А вот те извращения которые в плюсах воротят дотнету вряд ли нужны. А то наворотят, а потом возмущаются что компилеры между собой несовместимы.
Здравствуйте, VladD2, Вы писали:
A>>В общем, после твоих рассуждений о скрости, с серьезно относиться к твоим рассужедениям о приемлемости фреймворка нельзя A>> VD>Ну-ну. Здесь конечно все идиоты кроме тебя.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте Геннадий Васильев, Вы писали:
ГВ>>Вопрос: кому нужны стандарты, меняющиеся как погода осенью?
AVK>Поинтересуйся сановскими стандатртами для джавы. Они довольно часто меняются. И даже в ЕСМА не стандартизованы, только комитетом сана. Но это не мешает всему и вся в джава мире иметь между собой вполне приличную совместимость. Хотя и там ляпы случаются, но почти всегда из-за недоделанных стандартов, как это было с EJB 1.0.
Согласен, я как раз о том и говорил, что таких стандартов у каждой фирмы — вагон и две телеги. Мне просто непонятно, почему MS особо отметила факт стандартизации в ECMA. ИМХО — она где-то чувствует себя неуверенно, а иначе зачем лишние траты?
AVK>Стандарт это не конфетка, не признак крутости и не вещь решающая все проблемы. Стандарт это такая штука которая позволяет продукту А работать совместно с продуктом В когда они созданы разными производителями. И мне пофигу кто круче — ANSI, ISO, IEEE, РСТ или ЕСМА. Главное что ни один производитель в зравом уме не будет писать продукты под дотнет не соответствующие этому стандарту.
Не горячись , я не называл стандарт "конфеткой", "признаком крутости" и т.п. Вообще, здорово ты попытался опровергнуть довод, который сам же мне и приписал. Я говорил только о стабильности стандарта самого по себе и правомерности апелляции к стандарту с учётом стереотипа "стандарт — общепринятое стабильное решение".
Кстати, стандарт ещё и позволяет разрабатывать продукт А, имея ввиду, что разрабатываемый продукт Б тоже будет сооответствовать этому стандарту, а сам стандарт не изменится в неизвестном направлении к моменту окончания разработок А и Б.
ГВ>>Было бы странно, если бы было иначе. А я хочу получить совместимость на уровне исходников (полную совместимость хотя бы для множества ANSI-C++!) для разных реализаций С++.
AVK>Ну жди. А мы пока по простому, на шарпе будем потихоньку.
Ну так кто же возражает?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ> А я ничего и не говорил о бинарном стандарте на C++.
Вот ход рассуждений...
VD>>>На практике обработка ошибок в .NET на порядок поще, логичнее и удобнее чем в С++. Причем это теперь стандарт, а не самопальщина компилторостроителей.
VD>>В С++ нет и такого. Для меня MS — это уже стандарт. Врядли будут компиляторы для .NET не свместмые с .NET.
ГВ>Да ну? А "ANSI/ISO-IEC 14882:1998" ? Единственно в чём ты прав, так это в том, что среди производителей компиляторов согласованности нет.
Т.е. ты подразумевал что если производители сделают все по стандарту, то компиляторы будут совместимы между собой.
Вот я тебе и говрю, что нет никакого стандарта. Стандарт — общие разплывчатые слова о том как должна вести себя обработка исключений. Но про то как это реализовывать там ничего не сказано. Я это и без стандарта прекрасно понимаю. Дело в том что С++ вообще избегает всего что связано с физической совместимостью. Этот стандарт подразумевает что есть только одна программа и что она состоит из одного модуля. Т.е. речь идет только о бинарной совместимости и только о стическом связывании. Даже библиотеки уже не выдерживают никакой критики. Попробуй на одном комиляторе создать библиотеку которая генерирует исключения, а на другом ее использовать. От сюда и все навороты КОМ-а. Все эти HRESULT вместо исключений и другая дрибидень. В .NET это все устрнено. Можно смело пользоваться всеми возможностями языка так как они гарантируются исполняющей средой.
ГВ>Да и откуда он возьмётся для языка высокого уровня?
Язык это только по сравненю с ассемблером имеет "высокий уровень". На сегодня это уже низкоуровнвый язык системного программирования.
ГВ>Я говорил о неправомерности апелляции к стандарту ECMA,
Еще раз тебе говорю, что слова про ECMA сказал ты. Так что это чисто воды демагогия.
Я говорил о том, что .NET это стандарт по которому будут делаться все совместимые с ним языки. Что же касается отрезка времени, то MS ясно дала понять, что будут разные версии CLR. При этом с каждой из них можно будет быть совместимым. А тот факт что разные версии CLR могут жить на одной машине не даст коду независимых фирм умереть от смены версий. И кстити продукты именно MS обладают очень высокой степенью обратной совместимости. До сих пор под NT прекрасно работают досовские игры и т.п.
ГВ>Вопрос: кому нужны стандарты, меняющиеся как погода осенью?
Пример привести можешь? Или лиш бы наехать?
ГВ>Всё равно, пока что сомневаюсь, что IBM перейдёт в разряд адептов .NET. Ну, да это уже моё личное мнение. Что в IBM думают по этому поводу — .
IBM большая рыночная контора. Рынок PC она упускать не будет. Как только .NET завоюет серьезную чатьс этого рынка IBM будет вынуждена поддержать эту платформу, как в свое время поддержала NT бросив свою полуось.
ГВ>Насколько я помню, стандарт CLI существует только в ECMA-шном исполнении. Отсюда при упоминании тобой термина "стандарт" я сразу и вспомнил про ECMA.
А кто говорил про CLI? Я говрю о самом .NET как о стандарте де-факто.
ГВ>Было бы странно, если бы было иначе.
И тебе не стронно что ты не можешь сгенерировать исключение в С++ и поймать его в С++ же, но от другого производителя компилятора?
ГВ>А я хочу получить совместимость на уровне исходников (полную совместимость хотя бы для множества ANSI-C++!) для разных реализаций С++.
А по исключеним совместмость полная. К тому же если ты напшешь код для VC6 без использвания специфичных для MS фич, то получишь полную совместимость с другими компиляторами. Но все это пустые слова. Если тебе нужна переносимость, то ты скорее всего просто скомпилируешь все под gcc, а если ты работаешь для виндовс, то под VC или Intel. Меня лично совместмость компиляторов не трогает. А вот бенароной или компонентной совместмости мне (как и многим) нехватет. Это как раз веление времени. И С++ здесь на сегодня в пролете. Хотя очень заль. (МС++ по большому счету уже не С++-компилятор).
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Согласен, я как раз о том и говорил, что таких стандартов у каждой фирмы — вагон и две телеги. Мне просто непонятно, почему MS особо отметила факт стандартизации в ECMA. ИМХО — она где-то чувствует себя неуверенно, а иначе зачем лишние траты?
Таты эти для них ничтожны. А стандартизовались, чтобы все кому хочется понаезжать имели по меньще оргуменов. 90% назедов на MS имеют целью не указать на реальную пробему, а кольнуть по больнее, чтобы подпортить имидж. Ну вот ты даже к стандартизации прицепился хотя сам даже говоришь, что и без нее стандарт был бы. В общем эта тема вонует только тебя. Для меня важен сам факт наличия стандарта, а не формальная сторона вопроса.
ГВ>Не горячись , я не называл стандарт "конфеткой", "признаком крутости" и т.п. Вообще, здорово ты попытался опровергнуть довод, который сам же мне и приписал. Я говорил только о стабильности стандарта самого по себе и правомерности апелляции к стандарту с учётом стереотипа "стандарт — общепринятое стабильное решение".
По С++ стандарт существует уже наверное 30 лет, а компиляторы мжду собой так и не совместмы. .NET существует пол года, и нет ни одного нарушения этого стадарта, хотя компиляторов для него уже вагн и маленька тележка. Но это для тебя не довод. Потому как тебе просто безпричинно нравится это действительно неплохой но не иделатьный и сильно устаревший язык.
ГВ>Кстати, стандарт ещё и позволяет разрабатывать продукт А, имея ввиду, что разрабатываемый продукт Б тоже будет сооответствовать этому стандарту, а сам стандарт не изменится в неизвестном направлении к моменту окончания разработок А и Б.
Ну и к чему эта демогогия. Когда стадарты от MS изменялись да еще с ткой частотой? WinAPI до только расширяется и т.п. Да и другие продукты... Ты лучше обясни почему от С++ оуже песком попахивает? Не из-за того ли ревностного соблюдения неизменности стандарта?
Важна не консервативность которую ты называешь неизменностью стандарта, а обратная совместимость. Тот же С++ можно было спокойно обоготить современными возможностями без ущерба для обратной совместимости. Но делать этог не хотят. От сюда и рождаются все эит .NET, Явы и D.AVK>>Ну жди. А мы пока по простому, на шарпе будем потихоньку.
ГВ>Ну так кто же возражает?
Здравствуйте, Sergey, Вы писали:
S>Не въехал. У меня есть два библиотечных (читай — неизменяемых) классов A1 и B1. У класса A есть функция a(), у B — b(). Мне надо, чтоб обе они были у C. Твой пример я понял так:
S>template <class Tb> S>struct A : public A1 S>{ S> int a(); S>};
S>template <class Ta> S>struct B : public B1 S>{ S> int b() const; S>};
S>class C: public A< B<C> > {};
Не так, а что-то вроде этого:
template <T>
class A : public T
{
int a();
};
class <T>
struct B : T
{
int b() const;
};
class A < B < C > > {};
Те мн. наследование разворачивается в последовательное одиночное. Кажное одиночное наследование добавляет нужную реализацию. По большему счету ведь пробема одиночного наследования заключается именно в том, что к классу нельзя добавить готовую реализацию некоторого интерфейса. Полиморфность (если таковая вообще нужна) может быть обеспечена путем множественного наследования интерфейсов. В шарпе кстит интерфейсы не переходят публичный (дефолтный) интерфейс класса. Объект можно будет привести к интерфейсу, но мтоды у него соотвествующие не появятся. Так что шаблоны решат эту проблему. Ну правда придется изменить несколько свои стереотипы.
Здравствуйте, AndrewVK, Вы писали:
AVK>А мое убеждение, основанное на личном опыте, противоположное. Потому как когда из-за этих супер-пупер сложностей проект начинает захлебываться в собственной сложности то становиться не до наворотов. Могу тебе рассказать точку зрения с другой стороны, не программера а заказчика. Мне пофигу супер фичи. Мне главное чтобы продукт был написан быстро и при этом в нем не было глюков приводящих к неработоспособности, чтобы он был легко конфигурируем, причем чем больше автоматики тем лучше и легко модернизируем. И чтобы код был понятен даже недоучившемуся студенту. И в гробу я видал этот С++ с его множественным наследованием, крутыми указателями и прочия и прочия.
Я бы скзал так. А елси будет очень нужно то возмем МС++ тотрый 80% С++-а поддерживает и сделаем те 2% кода которые не сможем сделать на Шарпе или VB. За то не будем трахаться с отладкой по пол года и отсуствием элементаных библиотек.
Vi2>Да уж, глядя на примеры в форуме NET я бы так с ходу не сказал, что просто и удобно.
А ты их на С++-ые аналоги замени. То-то посмеемся.
Хочешь например соревнемся с тобой в скорости создания и объеме полученного кода в области ком-объектов? Я уже не говрю про простоту модификации и поддежки...
Vi2>Аналогия? Пожалуйста! Использование VB — легко и просто, Дельфи (которую все почему-то(?) ругают) — тоже. И вот теперь Шарп — легко и просто.
Заметь VB и Дельфи ругают обычно очень упертые и недалекие люди. Даже сишники до мозга костей обычно просто отмалчиваются на эту тему. Это потому что в соих обостях (создание гуи и взаимодейсвтие с БД) они делают С++ с большим запасом. Шарп же дает непривзайденную универсальность, а простое взаимодейсвие с МС++ полную независимость и простоту разработки сложных решений.
]
А "ANSI/ISO-IEC 14882:1998" ? Единственно в чём ты прав, так это в том, что среди производителей компиляторов согласованности нет.
А я ничего и не говорил о бинарном стандарте на C++. Да и откуда он возьмётся для языка высокого уровня? Я говорил о неправомерности апелляции к стандарту ECMA, как к документу, сохраняющему значимость на протяженном отрезке времени. 
Что называется, прочувствуйте разницу. 
