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

АХ>Глупо не иметь возможности задействовать это богатство. Но так же бессмысленно требовать DX 9.0 видеокарту, двух-ядерный процессор и 1-2 гига памяти на офисном компе у секретарши на котором в основном читают почту и серфят Инет.

Пусть секретарша не включает Aero и ей не понадобится мощная видеокарта. Насчёт 2-х ядерного камня у меня тоже сомнения. А гиг памяти — мелочь.

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

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

DC>>Когда вышел ARM, когда вышла Java и .Net? Мало того за эти 20 лет очень сильно поменялось железо.
S>За какие 20 лет? С++ в современном виде едва ли не моложе джавы. Когда в него ввели частичную специализацию шаблонов?

С++ придумали практически в 85-86 годах, реализовывали долго. Со времен ARM ничего толком не изменилось из того что касается маглинга.

DC>>Так что в далеком 85, даже 91 было несколько иначе. Но как тогда, так и сейчас остается приоритетом именно портируемость на уровне исходников, а это уже не мало для платформы где нет VM, но есть компилятор С++.
S>Приоритетом должны оставаться потребности пользователей, а не стремление к прекрасному.

Приоритетами занимаются пользователи, которые сидят в комитете,

DC>>Какую землю? см. ответ eao197. Я думаю это тебе надо чуток спуститься на землю, или хотя бы вернуться в то время мыслью.
S>В то время — это в какое? Когда был принят актуальный стандарт С++? Сколько еще нужно ждать, чтобы комитет наконец задумался о вопросах интеропа? Бред какой-то. Газотурбинный двигатель изобрели, а до щеколды не додумались.

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

Это не щеколда, это если вдруг понадобился двигатель который способен работать и на керосине, и на спирте и на метане, причем практически без изменений КПД.

DC>>У комитета есть четкие задачи и цели, которые были сформулированы еще во время его создания, вместо обвинений в близорукости почитай в чем они заключаются.
DC>>Кроме того, для тебя они могут казаться очевидными, а для членов комитета очевидными и более нужными могут казаться другие вещи.
S> Именно поэтому я и ушел с плюсов — разошелся, видишь ли, в целях и задачах с комитетом.
S>Да, кстати, пользуясь случаем передаю привет от Хайнлайна комитету W3C.

DC>>Мало того есть инструменты удовлетворяющие твоим потребностям. Внимание вопрос: Зачем хаять комитет? За то что они решают другие проблемы?
S>Конечно.

DC>>А компилятор видимо сам программы собирает ? Т.е. ты полагаешь, что проблемы с разной кодировкой имен это самая важна проблема совместимости? Да проше простого написать тулзу которая будет перекодировать манглинг различных компиляторов. Толь вот функцию я то вызвать смогу, а объект передать — уже нет.
S>Вот именно, только почему-то комитет вообще не счел нужным упомянуть о такой тулзе или подумать о том, какая информация может быть ей нужна. Передачу объектов тоже можно было сделать вполне человеческим образом — мне, если честно, лень тут в двух строках делать работу, с которой не смогла справиться Вся Королевская Рать за двадцать лет. Просто им хотелось заниматься не этим.

Сделать передачу объекта м-ду конкретными платформами и компиляторами действительно несложно . Ты это в общем виде сделай да так чтоб всех устраивало. Это отдельный стандарт по объемам ИМХО, который к имеет прямое отношение к реализации компиляторов.

DC>>Как? Ты представляешь себе различие в представлении компилятором множественного наследования, витртуального множественного наследования на разных компиляторах?

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

Потому как это скорее работа библиотеки. CORBA вполне себе справляется.

DC>>Мало того для платформы которая работает в реальном времени, от этого производители компилятора вообще отказались, как и от обработки исключений, ради оптимизации и эффективности.
S>Производители компилятора — вообще отдельные люди.
DC>>Вот тебе и разница. Здесь нет компромисса, мало того это не противоречит основным идеям создателя С++. Совместимость С++ с С и стремление к равенству по скорости кода, причина такой популярности С++, но так же и причина его основных недостатков.
S>Да ничего подобного. С++ не стремился к равенству по скорости; лозунг С++ — не надо платить за то, чем не пользуешься. Поэтому вполне в рамках концепции была бы стандартизация интеропа, пусть даже она и приводила бы к потерям производительности при кросс-компиляторной линковке. Главное — что а) эта линковка была бы возможна и б) производительность в случае ее отсутствия не страдала бы.

Всегда стремился, хотя бы потому как сначала работал просто как препроцессор для Си. Стандарт интеропа по времени затраченному на его определение занял бы ИМХО даже больше времени, чем собственно стандарт языка.

S>Причем заметь — это мы обсудили одну только маахонькую фичу — компонентность, а ведь это не она одна. То, что комитет наплевал на возможность поставлять библиотеки в кросс-компиляторном бинарном виде, это только их вина. Ты упорно отказываешься видеть, что нету в С++ никакой компонентности. И уже 15 лет комитет страдает фигнёй от избытка интеллекта.

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

DC>>Никто. Внеси предложение . .
S>Да у них этих предложений тонны.

DC>>Думаю можно найти предложения которые решали бы эту проблему и посмотреть причины отказов. Полагаю, что они будут довольно вескими.
S>Мне всё равно, насколько вески эти причины. Хотя скорее всего причина ровно одна — отсутствие консенсуса. См. Р. Хайнлайна.

Комитет, на данный момент лучший выбор из всех возможных.

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

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

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

DC>>Хм, т.е. все улучшения которые дают Немерл и Окамл это уменьшение многословности? Мда уж что-то тогда индустрия на месте топчется получается, только шаги красивше и меньше выходят.

M>Ну ИМХО Асм -> С тоже в значительной мере уменьшение многословности...

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

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

M>>Ну ИМХО Асм -> С тоже в значительной мере уменьшение многословности...

DC>Ну уж нет, Си явно выражал концепцию структурного программирования, т.е. вводил новые абстракции что ли.

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

И далее. Почему-то мне кажется что структурно можны было писать и на Асме(допустим макроподстановками). Равно как и неструктурно на С.

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

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

M>>>Ну ИМХО Асм -> С тоже в значительной мере уменьшение многословности...

DC>>Ну уж нет, Си явно выражал концепцию структурного программирования, т.е. вводил новые абстракции что ли.

M>Не довелось застать перехода с Асма на С. Поэтому могу только предполагать что первые версии С недалеко от фортрана были, то бишь банальное упрощение кода. Это тоже имхо, могу ошибаться. Если у кого есть более точные данные прошу кинуть ссылкой.

M>И далее. Почему-то мне кажется что структурно можны было писать и на Асме(допустим макроподстановками). Равно как и неструктурно на С.

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

Sinclair wrote:
> Оказывается, что очень большой вес играет именно последний уровень. Вон
> — почитай отзывы на конкурсах по разработке уровней. Банальное
> дописывание скрипта, который закрывает двери за героем может ускорить
> игру в два-три раза. Потому как главное в 21 веке — не выплевывание
> пикселов со скоростью шины, а аккуратное отсечение лишних треугольников
Эта проблема была решена давным давно с помощью BSP/Octree и их
комбинаций

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

GC на таких структурах тоже часто очень быстро сдыхает — ну не живет он
с сильносвзяными изменяющимися данными.

Я где-то приводил пример структуры геометрических данных из моей
(неигровой) программы, сейчас вот только найти ее не могу — RSDN глючит

Вот для игровых скриптов что-то типа Nemerle рулило бы, да собственно
там сейчас и так уже вполне неплохой LUA/Python используют.

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

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

VD>>>А какой у тебя опыт написания переносимых программ на других языка?

Ш>>Речь шла о C++. Причем тут другие языки?

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

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

VD>Другими словами, не допускаешь, что делов в твоей неверной оценке?

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

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

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

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

Мнение из середины 90-x:

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

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

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

IT>Шаблоны и исключения появились намного позже, уже в 90-х.

Необходимость поддержки параметризованных типов, исключений и множественного наследования в C++ была описана Страуструпом в 1986 г. в статье "What is Object-Oriented Programming". Затем, в мае 1990-го вышла книга The Annotated C++ Reference Manual (ARM) в которой механизм шаблонов и исключений был описан. Вот, что об этом говорит сам Страуструп:

Итак, в ARM были представлен следующие возможности:
* все, что вошло в версию 2.0;
* шаблоны;
* исключения;
* вложенные классы;
* раздельная перегрузка префиксных и постфиксных операций ++ и --;
* volatile;
* локальные статические массивы.

Все описанные в ARM возможности, кроме исключений, получили широкое распространение вместе с версией Cfront 3.0 в октябре 1991 г. Полная реализация возможностей, упомянутых в ARM, впервые появилась в компиляторах фирм DEC и IBM в начале 1992.

(Дизайн и эволюция языка C++, 2-е издание).

А Cfront, в котором шаблоны появились впервые, был как раз препроцессором.
И, если не ошибаюсь, то ли DEC-овский, то ли IBM-овский компилятор был так же препроцессором.

E>> Далее работали штатные C-компиляторы и линкеры конкретной целевой платформы. Первый "родной" компилятор C++, Zortech C++, был написан в конце восьмидесятых для MS-DOS и не поддерживал самых продвинутых возможностей языка.

IT>Это каких?

Как раз шаблонов и исключений Я сталкивался с Zortech C++ годах в 92/93-м -- там этого не было.

E>>И я не очень представляю себе, как в 87-м или 89-м можно было выработать единый стандарт объектных файлов для 16-ти битовой MS-DOS с разными моделями памяти и 32-х битовыми мейнфреймами и RISC-рабочими станциями.

IT>А мозг на что человеку даден? Нужно было подумать им немного.

Я вот не могу себе представить другого способа для этого, кроме компиляции не в объектный код, а в код какой-нибудь виртуальной машины. С последующей трансляций в конкретный нативный код.
Однако, это совсем не простая задача. Smalltalk-у для этого потребовалось ой как много времени.
К тому же это была бы совсем другая история.

Если мне не изменяет память, то в Borland-овских компиляторах вообще можно было умудрится слинковать в один проект obj-файлы, скомпилированные в разных моделях памяти (например, small и large), а затем долго выяснять, почему же программа странно себя ведет. Если уж одна фирма в своих объектных файлах разобраться не могла, то что уже говорить об общем формате для конкурирующих фирм.

E>>Тем более, что в отличии от нынешних времен, когда компиляторы менстримовых языков (Java и C#) принято раздавать бездвоздмездно (т.е. даром), в то время на продажах компиляторов деньги зарабатывали.

IT>Вот он корень зла!

Да, деньги способны испортить все, что угодно.
Кстати, не поэтому ли Sun придушила MS Java в зародыше?

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

M>>Не довелось застать перехода с Асма на С. Поэтому могу только предполагать что первые версии С недалеко от фортрана были, то бишь банальное упрощение кода. Это тоже имхо, могу ошибаться. Если у кого есть более точные данные прошу кинуть ссылкой.

это ведь не одноразовый процесс. ЯП развиввлись десятилетиями, обрастая всё новыми возможностями и лишаясь старых. например, в фортране не было зарезервированных слов, а пробелы в идентификаторах игнорировались. говорят, из-за этого в одной программе цикл 'do' превратился в писванивание (там была банальная опечатка, которую компайлер не смог заметить) и Вояджер не долетел до Венеры

M>>И далее. Почему-то мне кажется что структурно можны было писать и на Асме(допустим макроподстановками). Равно как и неструктурно на С.

это ещё что. у борладнда в асме есть ООП расширения у приницпе, спец. языки лишь *облегчают* использование выбранной методологии программирования

DC>Это все верно, только я прошу чтоб мне привели те кардинальные изменения, которые упростят работу с алгоритмами в алгоритмах оптимизации отображения сцены или хотя бы в других алгоритмах используемых в движках. Я думаю ничего кардинального со времен процедурной модели не появилось . Я конечно не ас в ФП, но мне все-таки кажеться, что в этом плане ничего принципиально не измениться.

преимущества Хаскела — очень строгая типизация, отлавливающая большинство ошибок с типами, и лёгкость конструирования алгоримтов из составных частей. я не представляю себе потребности игр, но вот к примеру печать простых чисел:

main        = print primes
primes      = 2:filter is_prime [3,5..]
is_prime n  = all (\p-> n `mod` p /= 0) (takeWhile (\p-> p*p<=n) primes)

напиши это на своём родном языке

или вот это:

-- |this function finds last space in String within 80-char boundary
len_f = last . filter (<80) . findIndices (==' ')

впрочем, это только "гарики". настоящая мощь наступает когда ты передаёшь функции/процедуры куда тебе нужно, строишь из этих входных данных более сложные функции/процедуры и передаёшь их дальше. к сожалению, примеры использования этого довольно велики и их будет сложно объяснить здесь

вот напоследок ещё один небольшой алгоритм. суть его в том, что есть а-ля RAR список номеров сбойных секторов в архиве и его надо разделить на две части — секторы, чей номер по модулю rec_sectors уникален (их можно восстановить), от тех, которые накладываются друг на друга:

    let (recoverable,bad) =  bad_crcs .$ sort_and_groupOn (`mod` rec_sectors) 
                                      .$ partition (null.tail)                
                                      .$ mapFst concat .$ mapSnd concat

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

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

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

K> Мнение из середины 90-x:

<поскипал цитату>

Вообще-то это уже совершенный оффтопик, но все же отвечу. Думаю, модераторы перенесут ветку в игры, если посчитают нужным.

Я имел в виду не обязательно железно ускоряемую физику, а вообще любую. Мы тут пытаемся использовать тот самый PhysX, на который я кидал ссылку. Так вот, если бы мне сейчас довелось начинать делать игру заново, я бы сильно подумал, стоит ли использовать ее вообще. Дело в том, что физический движок весьма сложен в настройке, да и багов в нем предостаточно. Время, которое мы потратили на борьбу с ним, ужасает. А между тем, что мы с него имеем:
1) Collision detection, с помощью которой выясняем, может ли игрок идти, или он уткнулся в стену. Без этого, конечно, обойтись сложно, но есть математические пакеты, позволяющие получить такую функциональность без включения в проект полновесного физического движка
2) Динамика разнообразных твердых тел. У нас она реально нужна только для метательного оружия типа гранат. Плюс всякие предметы, которые мешаюся у игрока под ногами и прикольно разлетаются, если рядом что-нибудь взорвалось. Гранаты — это, конечно, проблема, без остального можно обойтись.
3) Рэгдолл — то, что происходит с человечком, когда он умирает. Актуально, когда нужно красиво упасть из окна или повиснуть на заборе. В остальных случаях можно просто наделать больше красивых анимаций смерти. Впрочем, падение из окна можно тоже анимировать.

Собственно, это все. Есть еще всякая экзотика типа честной (почти) льющейся воды или честно развевающихся тряпочек, без которых в большинстве случаев тоже можно обойтись.

Еще, кстати, неслабый удар по производительности вся эта физика.

Между тем, есть отличные игры, которые без нее неплохо обходятся. Посмотрите, например, на Call of Duty.

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

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

>> Нафига? Вон, Цивилизация 4 на питоне фактически написана, только движок на C++.
C>Поэтому CivIV всеми и считается жутко тормозящей

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

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

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

FDS>Конструктор электровоза самолёт не спроектирует, а наоборот — вполне.

Не верю. (c)

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

PD>В общем, эффективностью пожертвовали ради удобства и простоты. Тем более тут еще бум с ростом ресурсов произошел очень кстати, так что порой и незаметно было , что этот продукт работает в 10 раз медленнее, чем ему положено. Самолет для меня — штука прекрасная, откуда мне знать — его 900 км/час это нормально или нет ? Может, нормально 3000 км/час ? Ничего я в самолетах и аэродинамике не понимаю (допустим) . Все равно, и 900 лучше, чем поездом!

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

Вот ты привел пример про самолеты. А я привеуд пример про машины.

У меня вот — девятка. Говорят, может разогнаться до 150 км/ч, но с это опасно. На 120 км/ч — вполне сносно.
А ведь есть машины, которые легко разгоянются до 250 км/ч и отлично управляемы на такой скорости.
Есть даже (в мелкосерийном производстве) машины для скоростей за 350 км/ч..

Да. Значит, неэффективна моя девятка.

Так вот — если исходить из критерия эффективности — то мне надо срочно менять машину на такую, которая ну хотя бы уж 250км/ч развивает

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

Дальше — развитие темы.
Если выбирать между машинами:
1. макс. 60км/ч, очень удобная, безопасная и комфортная
2. макс 190 км/ч, но некомфортно.

То я просто совершенно однозначно выберу первый вариант.
И с программами та же фигня. Пользователь выбирает баланс между ценой и удобством программы, среди вариантов, которые способны решить нужную ему задачу (глупо сравнивать самолет с поездом, если нужно добраться в Автралию). Медленное выполнение — это только лишний минус к "удобству".
Платить же лишние деньги за какую-то там "эффективность", или тем более — жертвовать ради этого комфортностью работы — никто не будет.

З.Ы.
Я вот не знаю какая скорость нормальна для самолета или для поезда. Я выбираю билеты, сравниваю имеющееся у меня время и деньги, цену билета и время в пути — а потом выбираю — самолет А, самолет Б или поезд. И плевать мне на их эффективность. Ты еще про загрязнение окружающей среды вспомни, ха.

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

E>Вот сайт производителя этого ускорителя
E>Только что-то пока ничего особенного с поддержкой этого ускорителя не вышло.
E>Во многом потому, что навороченная физика для большинства компьютерных игр довольно сомнительное приобретение.
E>Многие без нее обходятся и живут отлично.
Наоборот, это сейчас самая горячая тема. Чисто в графике уже практически достигли фотореализма, дальше только трассировка лучей.
А вот реалистичность физических эффектов как раз может быть selling point. Другой вопрос, что nVidia и ATI естественно просто интегрируют поддержку физических вычислений в последнем поколении своих карт (с помощью Havok FX в частности), да и большинство геймеров в общем-то не горят желанием покупать еще одну дорогую карту.

Статья в тему: Tom's Hardware: Is AGEIA's PhysX failing?

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

E>Еще, кстати, неслабый удар по производительности вся эта физика.

Вот именно потому целесообразно переносить обсчёт физики на дополнительный процессор.

E>Между тем, есть отличные игры, которые без нее неплохо обходятся. Посмотрите, например, на Call of Duty.

Контрпример — Silent Storm.

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

VD>Здравствуйте, Константин Л., Вы писали:

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

VD>Правильно! Никому их имена не рассказвай, а то они узнают кто им код пишут и офигет сразу.

блажен кто верует...

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

AF>Здравствуйте, Константин Л., Вы писали:

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

AF>Я догадываюсь! Это наверно называется "откат-софт"?

ну что за манера говорить о том, чего не знаешь?

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

AF>Здравствуйте, Константин Л., Вы писали:

КЛ>>чего стоит мой — я знаю.

AF>Если у всех в вашей команде такой же опыт как у вашего веб-программиста, то дальше можешь не рассказывать. (подсказываю — люди пользуются многими другими браузерами, кроме IE6. И показывать им "ваш браузер не поддерживается" — вопиющий непрофессионализм)

хм...Ты business-analyst'ом работаешь? Если нет, то тогда лучше бы молчал.

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

IT>>Шаблоны и исключения появились намного позже, уже в 90-х.

E>впервые появилась в компиляторах фирм DEC и IBM в начале 1992.

Я же говорю в 90-х.

E>А Cfront, в котором шаблоны появились впервые, был как раз препроцессором.

Cfront вообще кто-нибудь использовал в коммерческих разработках?

E>>> Далее работали штатные C-компиляторы и линкеры конкретной целевой платформы. Первый "родной" компилятор C++, Zortech C++, был написан в конце восьмидесятых для MS-DOS и не поддерживал самых продвинутых возможностей языка.

IT>>Это каких?

E>Как раз шаблонов и исключений Я сталкивался с Zortech C++ годах в 92/93-м -- там этого не было.

Естественно. Этих фич в C++ тогда ещё не было.

IT>>А мозг на что человеку даден? Нужно было подумать им немного.

E>Я вот не могу себе представить другого способа для этого, кроме компиляции не в объектный код, а в код какой-нибудь виртуальной машины. С последующей трансляций в конкретный нативный код.

Можно и так. Turbo Pascal, например, великолепно справлялся с этой задачей в тоже самое время. Ещё тогда же было семейство компиляторов, не помню название, для которых эта задача решалась не для одного, а для множества языков. Так что решить эту задачу было можно, было бы желание.