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

BZ>Здравствуйте, dr.Chaos, Вы писали:

VD>>>С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод.
DC>>В чем его моральная старость? Кто кроме С++ дает такие возможности с обобщенным программированием при строгой типизации? Java, .Net?

BZ>Eiffel с 80-х годов. оттуда кстати оно и было в C++ перенесено у меня есть на 25 кил письмо автора этого языка где-то 87-го года, где он критикует C++. можешь считать добавление exceptions/templates работой над ошибками

BZ>вообще C++ вырос из "высокоуровневого ассемблера" и на нынешнем уровне его применение имхо оправдано только когда нужна максимальная производительность. а все добавления последних 10-15 лет — это просто эмуляция возможностей более высокоуровневых языков, от умных указателей до лямбд.

BZ>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет

Вот, блин ты мне приведи то место где Я это сказал.

Здравствуйте, eugene0, Вы писали:
E> Я что-то писал про процессы или потоки?
Ты — нет. Ты писал про виртуальные машины. Вот, к примеру, каждая Java VM выполняется в отдельном процессе.

E>На ум приходят всякие доводы за и против, но на самом деле все это ни к чему. Если ты посмотришь немного выше по ветке, я всего лишь предположил, почему в вышеупомянутых казаках логика поведения юнитов полностью захардкодена, а не написана на скриптах.
Я понимаю, и я хардкод упомянул как один из вариантов. Но он не противопоставляется ни VM, ни интерпретатору, который бегает по кругу.
E>Зачем что-то колбасить? Вот LUA, вот python. Для того, чтобы делать что-то новое, нужно, чтобы это новое было чем-то лучше, чем готовое и многократно использованное и оттестированное старое. Чем вот эти псевдоязыки были бы лучше?
Ну, чисто теоретически, они бы еще сильнее контролировали дизайнера. Я, честно говоря, ни LUA ни Python не знаю, поэтому точно сказать ничего не могу. Но я 100% уверен, что дизайнеры не рождаются со знаниями ни того, ни другого. 100% известных мне дизайнеров делятся на тех, кто вообще ни на чем программировать не умеют, и тех, кто немножечко-немножечко знает JavaScript и PHP.
Я не знаю, почему вы выбрали Lua/Python для своих скриптов. Наверное, из них легче управлять игровыми объектами, чем из С++, и они дают меньше возможностей сделать какую-нибудь катастрофическую ошибку вроде прохода по памяти, использования удаленного объекта или неудаления использованного.

E>За все современные игрушки не скажу, а у нас дела обстоят следующим образом. Есть некий самодельный инструмент — редактор уровней, главный инструмент дизайнеров. В нем можно рассмотреть игровой мир со всех сторон, подвигать объекты, поменять их свойства. Еще там же можно давать объектам на выполнение различные скрипты, тут же их править, запускать снова.
E>Дизайнер может действовать так: он строит сцену из готовых объектов, настрайвает их свойства, пишет скрипты. Это обычно происходит в режиме "на паузе". После этого он сохраняет сцену, запускает ее и смотрит, что получилось. Обычно, сначала что-нибудь идет не так, как хотелось. Тогда дизайнер перегружает сцену, подправляет ее немного (передвигает неправильно стоящий объект, правит скрипт и т.д.), сохраняет, смотрит, что получилось. И т.д. и т.п.
E>При этом никаких длительных перерывов в его работе нет, из редактора он не выходит. Если бы вместо скриптов была захардкоденная логика, ему пришлось бы выходить, править, перекомпилировать как минимум тот модуль, который он поправил.
Это я понимаю. Непонятно только, что в твоем понимании "захардкоденная логика". Dll на С++? Ну да, согласен. Управляемые языки могут совместить компиляцию с "сохранением сценки" так, что дизайнер ничего не заметит
E>Вот о чем я пытался сказать выше. Насколько мне известо, разработка уровней организована таким образом не только у нас.
Ага, я тоже подозреваю, что вы такие не одни.

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

DC>Не только. Новые абстракции нужны для разбиения на части модели. Это локально снижает сложность.
А "Сложность" это что?
Подсказываю: главное уравнение общей теории поля выглядит так:
@A = 0;
Где A — некоторый вектор-потенциал, @ — некоторый дифференциальный оператор второго порядка.
Для частного случая электромагнитного поля хорошо известно, что такое A и @, и уравнение приводит к системе уравнений Максвелла (если расписать оператор даламбера и вектор-потенциал). Очевидно, в такой форме уравнение проще — в нем участвует меньше сущностей. Простота == лаконичности.

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

VD>>>>С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод.
DC>>>В чем его моральная старость?

BZ>>вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет

DC>Вот, блин ты мне приведи то место где Я это сказал.

лови

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

VD>Данные похожие на данные из приводимой мной презентации, но они мало что говорят об оправданности такого решения.
VD>Из той же презентации видно, что на всю симуляцию игры уходит около 10% процессорного времени:
<таблицу поскипал>

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

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

VD>Учитывая, что, например, дотнет если и дает проигрыш в производительности, то он все равно измеряется в процентакх, и то, что процессорные затраты на него не велики, то не кажется ли тебе не разумным писать этот код на С++? Если вместо скрипа использовать безопасный, удобный, но быстрый язык — то вы могли бы значительно упростить себе работу при этом практически ничего не потеряв в производительности.

VD>В итоге вы могли бы больше времени потратить на остальные части игры, или просто быстрее выпустить игру сделав ее при этом более надежной.

Гораздо лучше быть богатым и здоровым, чем бедным и больным
Конечно же, я с удовольствием писал бы на удобном и безопасном языке. Вопрос только в том, сколько все же составляют те самые проценты, на которые он медленнее неудобного и опасного, но более быстрого языка.
Предлагаю говорить все же более конкретно. Скажем, 10% для нас — это уже критично. У нас пока некоторые уровни на средних машинах на слайд-шоу похожи

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

E>Так что я не вижу противоречий по сравнению с тем, что я говорил здесь

Автор: eao197
Дата: 06.02.07

Первые версии компилятора C++, даже с поддержкой шаблонов и исключений, были всего лишь препроцессорами, генерившими C-шный код.

Когда дело реально дошло до шаблонов, то C++ препроцессоров уже не было.

E>Ну не было у меня возможности переносить объектные файлы Turbo Pascal 3.0 с Robotron 1715 и CP/M на Turbo Pascal 5.0 на IBM XT и MS-DOS. И не знаю я про существование Turbo Pascal для SPARC-овых или MIPS-овых архитектур. Например, можно ли было tpu-файлы из Turbo Pascal на Маках использовать?

А на C++ у тебя в то время такая возможность была? Может начнём вспоминать несовместимости не только между разными платформами, но и компиляторами на одной платформе и даже разными версиями одного и того же компилятора?

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

E>Как утверждает Wikipedia, Borland выпускал две линейки C++ компиляторов: Turbo C++ и Borland C++.

Какие две ленейки? Был TC++ 1.0, его следущая версия была переименована в BC++ 2.0.

E>Я не уверен на счет шаблонов в Borland C++ 3.1. В Borland C++ 2.0 их точно не было.

В тройке уже были шаблоны и исключения.

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

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

С чего все началось:

We need relatively complex language to deal with absolutely complex problems.

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

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

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

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

eao197:

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

Вот за эту фразу я ставлю коллеге заочно 500, поскольку я со своими оценками is out of range.

BZ>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет.

А я когда пишу с применением не удовлетворяющего вас языка, то при условии правильного архитектурного рещения, у меня проблем в многопоточной среде не возникает вообще. Если ты владеешь инструментом и знаешь платформо-зависимую реализацию используемого, то язык тебе не помощник. От всех неурядиц в жизни даже мама не спасет. Что значит словосочетание километры геморроя придется искать в словаре. Мне конструкций и объектов синхронизации хватает для решения любых вопросов. Конечно язык позволяет достичь и non thread-safe реализаций, но это не значит, что меня обязывают делать именно так или язык ущербен.

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

PS. Хотите не верить мне, просто не верьте. Когда у меня возникнут в чем либо сомнения, я сам спрошу как мне быть. Ответы без наличия знака вопроса is UB. Я до сих пор пишу на том, о чем вы догадыватесь. И не потому что боюсь учиться, а потому что инструмент позволяет сделать все что необходимо, и не только мне. В зависимости от того какими инструментами либо технологиями я владею, зависит лишь то, каков выбор будет у меня при поиске работы, НО БУДЕТ ОН ВСЕГДА!!! Может я ..., потому что везет только им, но о тех километрах которые были упомянуты, мне встречаться в жизни не приходилось, а если и так, то очень редко и решения были для меня точно достижимы. Насколько это было красиво или нет, судить только мне. Каждой задаче в зависимости от задаваемых внешних параметров свое интерфейсное средство достижения цели.

P.S. [Content — Independent] Я в этой ветке увидел лишь одно логическое завершение всего выше описанного в качестве оптимизации. Изложенное выше — лишь разложенные на много постов статьи каждого из участников, за что я люблю программирование, а за что нет. Поэтому в качестве оптимизации дерева, предлагаю сделать N количество листьев главного узла, где N= количеству участников и там каждый приведет свои за и против в протокольном формате. Все остальное ................ Вместо точек каждый определяет самостоятельно продолжение повествования.

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

S>Здравствуйте, dr.Chaos, Вы писали:

DC>>Не только. Новые абстракции нужны для разбиения на части модели. Это локально снижает сложность.
S>А "Сложность" это что?
S>Подсказываю: главное уравнение общей теории поля выглядит так:
S>@A = 0;
S>Где A — некоторый вектор-потенциал, @ — некоторый дифференциальный оператор второго порядка.
S>Для частного случая электромагнитного поля хорошо известно, что такое A и @, и уравнение приводит к системе уравнений Максвелла (если расписать оператор даламбера и вектор-потенциал). Очевидно, в такой форме уравнение проще — в нем участвует меньше сущностей. Простота == лаконичности.

Кто тут, что то про J говорил? .

В предыдущем посте я имел в виду сложность модели. А в начальном именно упрощение синтаксиса. Т.е. Понятия ООП позволили представлять более сложные модели. Немерле и ОКамл, по вашим, утверждениям служат только для уменьшения многословности, что я воспринял, как простое упрощения синтаксиса (не хочу употреблять "синтаксический сахар", а то еще один флейм поднимут ). Я прошу дать именно те абстракции которых нет в С++, но есть в Немерле/ОКамл, которые позволят мне понизить сложность при создании алгоритмов для 3Д движка.

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

E>>Как утверждает Wikipedia, Borland выпускал две линейки C++ компиляторов: Turbo C++ и Borland C++.

IT>Какие две ленейки? Был TC++ 1.0, его следущая версия была переименована в BC++ 2.0.

Вот, что написано в Wikipedia:

Turbo C++ 3.0 was released in 1991 (shipping on November 20), and came in amidst expectations of the coming release of Turbo C++ for Microsoft Windows. Turbo C++ v3.0 first came as an MS-DOS compiler, supporting C++ templates, generation of DOS & protected mode executables, as well as generation of code targeting specific legacy CPUs, such as Intel 80186. The language implementation was updated to the latest AT&T release of C++.

After Windows 3.1 became available, Turbo C++ was sold with MS-Windows support. First Windows-based IDE was Turbo C++ 3.0 for Windows, followed by Turbo C++ 3.1 and Turbo C++ 4.5. It's possible that the jump from version 1.x to version 3.x was in part an attempt to link Turbo C++ release numbers with Microsoft Windows versions; however, it seems more likely that this jump was simply to synchronize Turbo C and Turbo C++, since Turbo C 2.0 (1989) and Turbo C++ 1.0 (1990) had come out roughly at the same time, and the next generation 3.0 was a merger of both the C and C++ compiler.

With version 3.0, Borland introduced a distinction between "Turbo C++" and "Borland C++". The former was marketed as a somewhat low-end product, while the latter was geared toward professional applications (it included additional tools and a stronger optimizer).

Т.е., как я понял, Borland продавал отдельно Turbo C++ и отдельно Borland C++.
Я по ошибке написал "выпускал" вместо "продавал".

E>>Я не уверен на счет шаблонов в Borland C++ 3.1. В Borland C++ 2.0 их точно не было.

IT>В тройке уже были шаблоны и исключения.

Вот не помню я про тройку. Поскольку, в отличии от двойки, она была исключительно Windows IDE, то у меня была возможность пользоваться ей только эпизодически. Серьезно следующую после 2.0 версию Borland-а довелось использовать только 4.0 (или какую-то ее модификацию 4.01 или 4.05) в начале 95-го и она была довольно глючная. А к концу 95-го появилась версия 4.5, в которой точно были исключения и шаблоны. И здесь в тему утверждения Wikipedia:

Version 4.0 was released in November 1993 and was notable (among other things) for its robust support of templates. In particular, it was instrumental in the development of the Standard Template Library, expression templates, and the first advanced applications of template metaprogramming.

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

E>>Так что я не вижу противоречий по сравнению с тем, что я говорил здесь

Автор: eao197
Дата: 06.02.07

IT>

Первые версии компилятора C++, даже с поддержкой шаблонов и исключений, были всего лишь препроцессорами, генерившими C-шный код.

IT>Когда дело реально дошло до шаблонов, то C++ препроцессоров уже не было.

Т.е. первый компилятор с поддержкой шаблонов, Cfront, за компилятор не считается?

E>>Ну не было у меня возможности переносить объектные файлы Turbo Pascal 3.0 с Robotron 1715 и CP/M на Turbo Pascal 5.0 на IBM XT и MS-DOS. И не знаю я про существование Turbo Pascal для SPARC-овых или MIPS-овых архитектур. Например, можно ли было tpu-файлы из Turbo Pascal на Маках использовать?

IT>А на C++ у тебя в то время такая возможность была? Может начнём вспоминать несовместимости не только между разными платформами, но и компиляторами на одной платформе и даже разными версиями одного и того же компилятора?

Тогда о чем мы здесь говорим?
Я так понял, что здесь сетуют, что во времена выпуска C++ 2.0 кто-то не додумал и не сделал для C++ единый формат объектных файлов и библиотек для всех компиляторов на всех платформах, а так же единый стандар формирования VMT и размещения объектов в памяти. Мол для других языков это было, а вот C++ валенки делали, они и не придумали.

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

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

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

E>>Как утверждает Wikipedia, Borland выпускал две линейки C++ компиляторов: Turbo C++ и Borland C++.

IT>Какие две ленейки? Был TC++ 1.0, его следущая версия была переименована в BC++ 2.0.

да, и потом они выпустили TC++ 3.0 как облегченную версию BC++ 3.0. в общем, по номерам версий ориентироваться в языковых фичах можно, различие между TC и BC касалось других вещей

E>>Я не уверен на счет шаблонов в Borland C++ 3.1. В Borland C++ 2.0 их точно не было.

IT>В тройке уже были шаблоны и исключения.

вот на этот счёт я могу совершенно точно ответить. в стандарте C++ 3.0 они были. в Borland C++ 3.1 были только шаблоны, и я его на этот счёт изрядно материл

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

E>Т.е., как я понял, Borland продавал отдельно Turbo C++ и отдельно Borland C++.
E>Я по ошибке написал "выпускал" вместо "продавал".

Может что-то и продавалось под другим именем, но упоминаний TC++ выше 1.0 тогда не было. В компиляторных войнах от Борланды тогда принимал участие исключительно BC++.

E>Вот не помню я про тройку. Поскольку, в отличии от двойки, она была исключительно Windows IDE

Это как? Всё там было на месте. Я писал на BC++ 3.1 с момента выхода и до самой 4.5. Писал под DOS и DPMI16.

IT wrote:
> Первые версии компилятора C++, даже с поддержкой шаблонов и исключений,
> были всего лишь препроцессорами, генерившими C-шный код.
> Когда дело реально дошло до шаблонов, то C++ препроцессоров уже не было.
Некоторые товарищи до сих пор preprocessor-based компиляторы поставляют.

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

IT>>Когда дело реально дошло до шаблонов, то C++ препроцессоров уже не было.

E>Т.е. первый компилятор с поддержкой шаблонов, Cfront, за компилятор не считается?

Кто его видел этот Cfront? Вот ты, например, видел? Я Zortech видел. T/BC++ видел. VC++ видел. gcc видел. WC++ видел. Cfront не видел.

E>Я так понял, что здесь сетуют, что во времена выпуска C++ 2.0 кто-то не додумал и не сделал для C++ единый формат объектных файлов и библиотек для всех компиляторов на всех платформах, а так же единый стандар формирования VMT и размещения объектов в памяти. Мол для других языков это было, а вот C++ валенки делали, они и не придумали.

Нет, здесь сетуют не на времена выпуска C++ 2.0. А вообще на C++. Это можно было сделать и во времена C++ 1.0 и десять лет спустя. Хуже не было бы. А теперь мы, точнее вы, имеете то, что имеете.

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

E>>Т.е., как я понял, Borland продавал отдельно Turbo C++ и отдельно Borland C++.
E>>Я по ошибке написал "выпускал" вместо "продавал".

IT>Может что-то и продавалось под другим именем, но упоминаний TC++ выше 1.0 тогда не было. В компиляторных войнах от Борланды тогда принимал участие исключительно BC++.

+1
Я сам когда сегодня в Wikipedia прочитал, удивился. Но вот очевидцы утверждают

Автор: BulatZiganshin
Дата: 07.02.07

, что таки была еще линейка Turbo C++.

E>>Вот не помню я про тройку. Поскольку, в отличии от двойки, она была исключительно Windows IDE

IT>Это как? Всё там было на месте. Я писал на BC++ 3.1 с момента выхода и до самой 4.5. Писал под DOS и DPMI16.

В BC++ 2.0 IDE была текстовая под DOS. Хотя можно было Windows приложения под 16-бит Windows компилировать. Хотя я тогда уже вместо IDE редактор MultiEdit использовал.

В BC++ 3.1 была графическая IDE, как нормальное Windows приложение. На ней под Windows писал. Затем, с выходом, BC++ 4.0 появилась возможность 32-х битовые приложения под Windows делать, изначально мы win32s под Win 3.11 использовали.

Но вот точно помню, что поддержка исключений только в какой-то из 4-рок появилось. По крайней мере использовать исключения я начал только когда на 4.5 окончательно перебрался.

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

IT>>>Когда дело реально дошло до шаблонов, то C++ препроцессоров уже не было.

E>>Т.е. первый компилятор с поддержкой шаблонов, Cfront, за компилятор не считается?

IT> Кто его видел этот Cfront? Вот ты, например, видел? Я Zortech видел. T/BC++ видел. VC++ видел. gcc видел. WC++ видел. Cfront не видел.

А ты в то время DEC-и видел? VAX-ы, Solaris-ы? Они же были.
К тому же мне доводилось несколько раз пользоваться C++ компиляторами, работавшими именно по принципам Cfront, вполне возможно, наследников того самого Cfront.

E>>Я так понял, что здесь сетуют, что во времена выпуска C++ 2.0 кто-то не додумал и не сделал для C++ единый формат объектных файлов и библиотек для всех компиляторов на всех платформах, а так же единый стандар формирования VMT и размещения объектов в памяти. Мол для других языков это было, а вот C++ валенки делали, они и не придумали.

IT>Нет, здесь сетуют не на времена выпуска C++ 2.0. А вообще на C++. Это можно было сделать и во времена C++ 1.0 и десять лет спустя. Хуже не было бы. А теперь мы, точнее вы, имеете то, что имеете.

Что характерно, нас это не волнует совершенно, а вот вас почему-то беспокоит

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

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

VD>>>Не допускаешь, что то что ты считаешь нормальным в сравнении с другим языком может оказаться ужасно сложно и медленно?

Ш>>Нет, я допускаю, что ты пытаешься подменить предмет обсуждения.

VD>Ухот от ответа можно расцнить как "да, допускаю"?

Я тебе дал точный ответ.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

E>А ты в то время DEC-и видел? VAX-ы, Solaris-ы? Они же были.

Соляру не видел. На дековском асме писал под PDP-11, даже C там какой-то ковырял. Если мне не изменяет мой склероз, то аналогами VAX были наши СМ ЭВМ. ЕС ЭВМ были содраны с IBM 360. Этих монстриков тоже довелось пощупать.

IT>>Нет, здесь сетуют не на времена выпуска C++ 2.0. А вообще на C++. Это можно было сделать и во времена C++ 1.0 и десять лет спустя. Хуже не было бы. А теперь мы, точнее вы, имеете то, что имеете.

E>Что характерно, нас это не волнует совершенно, а вот вас почему-то беспокоит

Бывает. Видимо я (мы) слишком чувствительны и восприимчивы к тому, что на нас как на пользователей так долго и так нагло кладёт комитет. У нас со временем это стало обоюдным. Ну а вас это не волнует совершенно. Понимаю.

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

IT>>>Нет, здесь сетуют не на времена выпуска C++ 2.0. А вообще на C++. Это можно было сделать и во времена C++ 1.0 и десять лет спустя. Хуже не было бы. А теперь мы, точнее вы, имеете то, что имеете.

E>>Что характерно, нас это не волнует совершенно, а вот вас почему-то беспокоит

IT>Бывает. Видимо я (мы) слишком чувствительны и восприимчивы к тому, что на нас как на пользователей так долго и так нагло кладёт комитет. У нас со временем это стало обоюдным. Ну а вас это не волнует совершенно. Понимаю.

Сколько сарказма

Тема, я думаю исчерпана.