Здравствуйте, Константин Л., Вы писали:
КЛ>не говори о том, чего не знаешь. Это просто смешно. Очень очень смешно. К сожалению я не могу раскрывать имена заказчиков. Всем бы таких, да далеко не все могут получить.
Правильно! Никому их имена не рассказвай, а то они узнают кто им код пишут и офигет сразу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Hobot Bobot, Вы писали:
HB>Однозначного отображения процесса строительства на процесс программирования нет и, ясен пень, быть не может. Впрочем, думаю, что между рядовым строителем и программистом, пишущим код по подробной спецификации, общего достаточно для проведения аналогий.
Аналогии можно провести между много чем. Только одни получаются ближе чем другие
И к "программисту, пишущему код по подробной спецификации", все же гораздо ближе младший инженер, делающий чертеж отдельных несложных этажей по подробной спецификации, составленной ведущим инженером
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну а дальше началось то, что называется "террор среды". Проще говоря. эта среда начала диктовать свои правила и профессионалам — они начали так или иначе эти новые правила игры принимать. Не все, конечно, но многие. Ну и соответствующие средства появились — Java, потом .Net, хоть и идеология от VB, но синтаксис и семантика нормальные. Удобно. Легко. Просто. Много знать не надо — садись и пиши. Что надо — по ходу действия разберешься. И заменить тебя, если что , легко — поточное производство. Качество ? Да ладно вам, летает ведь. Что, говорите, быстрее должен летать ? В 5 раз быстрее, говорите, должен ? Ну и идите стройте его, этот самолет, а пока Вы его построите, мы этот сломаем и новый построим. Он, правда, летать не быстрее будет...
Самолет, которого нет, летает с нулевой скоростью. "Профессионалы", которые строят гипотетические самолеты, которые должны летать быстрее в 5 раз, но не летают вообще — это не профессионалы.
Здравствуйте, Andir, Вы писали:
АХ>>а вот библиотек больше всего у MS.NET.
A>Основания у такого заявления есть? В том смысле хотелось бы узнать источник таких данных.
Reflector?
У меня даже нет сомнения, что если отбросить Яву, то это чистейшая правда.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ну а дальше началось то, что называется "террор среды". Проще говоря. эта среда начала диктовать свои правила и профессионалам — они начали так или иначе эти новые правила игры принимать. Не все, конечно, но многие. Ну и соответствующие средства появились — Java, потом .Net, хоть и идеология от VB, но синтаксис и семантика нормальные. Удобно. Легко. Просто. Много знать не надо — садись и пиши. Что надо — по ходу действия разберешься. И заменить тебя, если что , легко — поточное производство. Качество ? Да ладно вам, летает ведь. Что, говорите, быстрее должен летать ? В 5 раз быстрее, говорите, должен ? Ну и идите стройте его, этот самолет, а пока Вы его построите, мы этот сломаем и новый построим. Он, правда, летать не быстрее будет...
AF>Самолет, которого нет, летает с нулевой скоростью. "Профессионалы", которые строят гипотетические самолеты, которые должны летать быстрее в 5 раз, но не летают вообще — это не профессионалы.
Может быть правильней сказать, что одни делают электровозы, а другие — самолёты?
Конструктор электровоза самолёт не спроектирует, а наоборот — вполне.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, dr.Chaos, Вы писали:
DC>>Красиво слил, чесслово. . . WH>Почему слил? Лично я еще ничего хорошего разработанного комитетом не видел.
А ты видимо главный оценщик и цензор?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>По поводу того с чем работает движок мне рассказывать не надо , мне приходилось участвовать в разработке одного движка.
VD>И что из этого следует? Это твои фобии ничего не имеющие общего с реальность. МС уж точно не стала бы делать управляемый фрэймворк если бы заранее было известно, что он не приемлем попроизводительности.
Влад я сказал, что в MC не смогут разработать нормальный фреймворк для этого? Мало того после требований Висты, что-то у меня возникают сильные опасения, что "приемлемым по производительности" оно станет благодаря новым железкам, а не разработчикам в MC.
VD>>>В общем-то ОКамл или Немерле удовлетворяют большинству указанных там требований. Не всем конечно, но уж точно они в сто раз ближе к тому идеалу чем С++.
DC>>А движки на них есть?
VD>Да. На ОКамле даже не мало рендереров написано. А для них вычислительные возможности отнюдь не лишние.
Рендерер = Движок ?
DC>>Здорово, вот сошлась куча специалистов отрасли, потрындела 10 лет и в итоге выдала полный бред??
VD>Я говорю о конкретных требованиях конкретного человека. Блин, скачай ppt-у и пчитай. В его требованиях основными критериями являются надежность и безопасность. Ни шагу в этом направлении в новм стандарте нет.
Хм, ну С++ вобщем то универсальный язык, полагаю комитет руководствовался не пожеланиями конкретного человека. Верю что решения комитета могут не решить его проблем. Но утверждать, что улучшения которые появятся в 2009 году — бред, который ничего не изменит — глупо, по меньшей мере.
DC>> Я так понял твое высказывание? Т.е. несколько сотен непоследних специалистов по твоему неспособны решать какие-либо проблемы?
VD>По этому поводу отлично ответил Синклер.
Сразу видно команда . Ты пойми Влад, я не против новых инструментов, если они появятся и решат проблемы в какой-то отрасли это просто здорово. Но просто не понимаю смысла говнять имеющийся инструментарий. Язык С++ далеко не идеален, но он достаточно хорош для решения большинства задач.
Вернемся к началу. Т.е. ты считаешь что С++ из области написания графических движков вытеснит другой инструмент типа Немерле или ОКамл? Поскольку требования к языку в статье и немало рендереров на ОКамле являют какую-то тенденцию. Когда это по твоему произойдет?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Ну почему, все что подчиняется правилам компоновки С может быть слинковано и работать себе без особых проблем.
VD>Ссылу на эти правила, плиз. По моим сведниниям стандарт С++ никаких правил не определяет, и стандартов де-факто тоже нет.
Стандарт С++ их и не регламентирует. Влад я думаю ты прекрасно знаешь принцип работы простейшего компоновщика, который заменяет имена функций и переменных, определенных в др единице компиляции, на их адрес. Не знаю есть ли стандарт или какие-то регламентирующие документы, если тебе это так важно могу поискать.
DC>>Где? DC>>Вот твой вопрос:
DC>>
DC>>Что касается прикладных задач... а какие задачи не прикладные?
DC>>На что я тебе привел мнение создателя языка. Или я чего не домыслил в твоем вопросе? .
VD>Я просил привести списко задач, а не тавои измышления о С++. Улавливаешь разницу?
Хм, значит так спросил что я тебя не понял. Мало того привел я не свои измышления, а цитату из книги Страуструпа. Улавливаешь разницу? Правда, извини, не оформил как цитату, но указал что это не мои слова.
А по поводу задач: задачи системного программирования: написание ОС, драйверов, компиляторов и т.п. Хотя я думаю, что для написания компиляторов есть более подходящие инструменты, но я тут профан . Научные расчеты на большом количестве процессоров (ядер), будут быстрее выполнять функциональные языки, хотя в общем случае — . По поду прикладного ПО — вполне можно использовать С++ для написания ядра системы, а сверху накручивать прикладную логику каким-нибудь интерпретируемым языком, если грамотно сделать то будет и эффективность и скорость разработки.
DC>>Но твой вопрос все таки постараюсь ответить. Но сначала уточни — какие именно другие средства, ты имеешь ввиду?
VD>А какая разница? К задачам это отношения не имеет. Средства могут различаться в зависимости от задач.
Тогда зачем спрашивал?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, AndreiF, Вы писали:
AF>>> Так что вопрос можно поставить и обратный — а ты напишешь Quake 4 на чистом С++? CC>>Да. CC>>В том же Q4 скрипты предназначены только для того, чтобы можно было быстро и просто менять игровую логику не пересобирая движок. CC>>Ничто в общем то не мешает весь этот код запихать в DLL как это было во времена того же HL.
AF>Смелый парень. И много квейков 4, или хотя бы ХЛов ты за свою жизнь написал?
Парень он, возможно, смелый, зато работает, судя по профилю, в геймдеве. А вот ты, судя по высказываниям — нет. Не мог бы для начала привести какое-нибудь подтверджение вот этому своему высказыванию:
На самом деле, большая (по объему) часть современных игр пишется как раз на скриптах, в том числе и Питоне. Эта часть как правило больше, чем часть кода написанного на С++.
Здравствуйте, dr.Chaos, Вы писали: DC>Стандарт С++ их и не регламентирует. Влад я думаю ты прекрасно знаешь принцип работы простейшего компоновщика, который заменяет имена функций и переменных, определенных в др единице компиляции, на их адрес. Не знаю есть ли стандарт или какие-то регламентирующие документы, если тебе это так важно могу поискать.
Я тебе поясню скепсис Влада: во времена С всё, с чем работал линкер — тупые текстовые имена. А поскольку кроме глобальных переменных и функций линковать было нечего, то не было и проблем. А в С++ сразу появляются проблемы с перегрузкой функций и линковкой классов. Поскольку линкер ничего не знает про сигнатуры, для функций приходится выполнять так называемый манглинг, т.е. формирование "внутреннего" имени из настоящего имени и типов аргументов. Никакого стандарта на этот манглинг в природе не существует, поэтому С++ библиотеки от разных компиляторов между собой не совместимы. Это уже копец.
Далее, Страуструп намеренно отказался от стандартизации внутреннего представления метаданных. Т.е. всё, начиная от VMT и заканчивая таблицей фиксапов для приведения типов при множественном наследовании отдается на откуп компилятору. И, естественно, в этом компиляторы тоже несовместимы. Поэтому взять и отнаследоваться в компиляторе X от класса, определенного в библиотеке, скомпилированной компилятором Y в общем случае нельзя.
DLL в эту благостную картину ничего нового не добавляют. Они работают точно так же — биндинг к адресу по имени — только в рантайме, а не при компоновке. Поэтому все проблемы несовместимости реализаций в них присутствуют в полный рост.
Вот COM откуда по-твоему вырос? А вот как раз из того и вырос, что надо было стандартизовать структуру VMT и способ приведения типа. Ну и еще много чего, чтобы можно было заставить разные реализации ООП интероперировать друг с другом. Это ответ на отсутствие стандарта ровно в тех областях, от которых отказался Бъярни.
DC>А по поводу задач: задачи системного программирования: написание ОС, драйверов, компиляторов и т.п. Хотя я думаю, что для написания компиляторов есть более подходящие инструменты, но я тут профан . Научные расчеты на большом количестве процессоров (ядер), будут быстрее выполнять функциональные языки, хотя в общем случае — . По поду прикладного ПО — вполне можно использовать С++ для написания ядра системы, а сверху накручивать прикладную логику каким-нибудь интерпретируемым языком, если грамотно сделать то будет и эффективность и скорость разработки.
DC>>>Но твой вопрос все таки постараюсь ответить. Но сначала уточни — какие именно другие средства, ты имеешь ввиду?
VD>>А какая разница? К задачам это отношения не имеет. Средства могут различаться в зависимости от задач.
DC>Тогда зачем спрашивал?
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, dr.Chaos, Вы писали:
DC>Вернемся к началу. Т.е. ты считаешь что С++ из области написания графических движков вытеснит другой инструмент типа Немерле или ОКамл?
Лично у меня нет сомнения в том, что это таки произойдет. Я, конечно, дилетант в гейминдустрии, но свои две копейки вставлю.
Насколько мне известно, плюсы — вовсе не такой уж суперпопулярный в ГД язык. Грубо говоря, современная игра состоит из трех уровней:
— низкоуровневые битхаки для рисования (ассемблер)
— ядро движка (С/С++)
— геймплей (язык описания уровней)
Оказывается, что очень большой вес играет именно последний уровень. Вон — почитай отзывы на конкурсах по разработке уровней. Банальное дописывание скрипта, который закрывает двери за героем может ускорить игру в два-три раза. Потому как главное в 21 веке — не выплевывание пикселов со скоростью шины, а аккуратное отсечение лишних треугольников
Опять же большую роль в скорострельности играет способность ядра использовать метаинформацию с верхнего уровня — в частности, просекать отсутствие необходимости рисовать треугоьники за закрытой дверью. Здесь рулят алгоритмы, а С++ не слишком-то хорошо подходит для написания сложных алгоритмов. Граблеват, знаете ли. Конечно, там очень удобно писать умножение матриц благодаря наличию шаблонов. Но все равно, специализированный DSL с поддержкой умножения матриц будет позволять записать алгоритмы компактнее, и оптимизироваться еще сильнее, чем С++. Так что есть у меня подозрение, что и для верхнего уровня, и для среднего слоя в геймдевелопменте должны рулить DSL.
Nemerle, в частности, выглядит как хороший кандидат для платформы для построения DSL. Конечно, старую гвардию на него не переведешь. Тот же Кармак собаку съел на С, он и на плюсы-то переходить не хочет (несмотря на то, что у них значительно более сильный оптимизатор). Так что платформа ждет своего героя — если вдруг появится хороший DSL для 3d-engine на Nemerle, народ достаточно быстро перелезет туда. Особенно c учетом перспективы получить поддержку снизу в виде компилятор типа Бартока для генерации нативного кода (чтобы успокоить тех, кто считает JIT слишком дорогим) и мегапроекта от МС с compile-time profile-based optimization.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndreiF, Вы писали:
E>>Не мог бы для начала привести какое-нибудь подтверджение вот этому своему высказыванию:
AF>Какая конкретно его часть нуждается в подтверждении?
Та, в которой написано, что объем кода на скриптовых языках в современных играх больше, чем объекм кода на С++. Как правило
Здравствуйте, Sinclair, Вы писали:
S>Я тебе поясню скепсис Влада: во времена С всё, с чем работал линкер — тупые текстовые имена. А поскольку кроме глобальных переменных и функций линковать было нечего, то не было и проблем. А в С++ сразу появляются проблемы с перегрузкой функций и линковкой классов. Поскольку линкер ничего не знает про сигнатуры, для функций приходится выполнять так называемый манглинг, т.е. формирование "внутреннего" имени из настоящего имени и типов аргументов. Никакого стандарта на этот манглинг в природе не существует, поэтому С++ библиотеки от разных компиляторов между собой не совместимы. Это уже копец.
Копец начался еще раньше, когда появились различные и несовместимые между собой форматы OBJ-файлов статических библиотек. Даже в рамках одной платформы. Причем C++ не имел к этому никакого отношения.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали: DC>>Стандарт С++ их и не регламентирует. Влад я думаю ты прекрасно знаешь принцип работы простейшего компоновщика, который заменяет имена функций и переменных, определенных в др единице компиляции, на их адрес. Не знаю есть ли стандарт или какие-то регламентирующие документы, если тебе это так важно могу поискать. S>Я тебе поясню скепсис Влада: во времена С всё, с чем работал линкер — тупые текстовые имена. А поскольку кроме глобальных переменных и функций линковать было нечего, то не было и проблем. А в С++ сразу появляются проблемы с перегрузкой функций и линковкой классов. Поскольку линкер ничего не знает про сигнатуры, для функций приходится выполнять так называемый манглинг, т.е. формирование "внутреннего" имени из настоящего имени и типов аргументов. Никакого стандарта на этот манглинг в природе не существует, поэтому С++ библиотеки от разных компиляторов между собой не совместимы. Это уже копец.
Ооо. Ты открыл мне глаза
S>Далее, Страуструп намеренно отказался от стандартизации внутреннего представления метаданных. Т.е. всё, начиная от VMT и заканчивая таблицей фиксапов для приведения типов при множественном наследовании отдается на откуп компилятору. И, естественно, в этом компиляторы тоже несовместимы. Поэтому взять и отнаследоваться в компиляторе X от класса, определенного в библиотеке, скомпилированной компилятором Y в общем случае нельзя.
А ты себе представляешь сложность задачи? Унифицировать представление объектов в памяти на ВСЕХ возможных платформах. Кроме того к языку программирования это относится слабо. Кстати именно благодаря такому способу линковки С++ получил такое распространение и может использовать модули написанные на С, Fortran и т.д.
S>DLL в эту благостную картину ничего нового не добавляют. Они работают точно так же — биндинг к адресу по имени — только в рантайме, а не при компоновке. Поэтому все проблемы несовместимости реализаций в них присутствуют в полный рост.
S>Вот COM откуда по-твоему вырос? А вот как раз из того и вырос, что надо было стандартизовать структуру VMT и способ приведения типа. Ну и еще много чего, чтобы можно было заставить разные реализации ООП интероперировать друг с другом. Это ответ на отсутствие стандарта ровно в тех областях, от которых отказался Бъярни.
CORBA выросла примерно там же, только еще и с транспортом.
Я вот не пойму что вы мне пытаетесь доказать? То что сборки под дот нет или компоненты Делфи лучше? Дык я не спорю. Я сказал что благодаря, в том числе, такой компонентной модели С++ плох для прикладного ПО.
С чем ты споришь? Я понимаю что такая линковка — это тормозная и часто неудобная штука. Я понимаю что неунифицированное представление объектов — это проблемы совместимости платформ и компиляторов.НО!!! Простой как сибирский валенок механизм линковки, обеспечивает простоту реализации этого инструмента на любой платформе!! Мало того очень трудно сделать одинаково хорошее представление для микроконтроллера/PC/RISC-сервера/... Ты еще не забывай, что на специфических платформах нет ни шаблонов, ни множественного наследования и т.д. Т.е. создав единый стандарт представления — не угодили бы никому.
Помимо всего прочего — кто мешает, собраться MC, GNU GCC и Comeau — и сделать стандарт представления и ему следовать??
Правильно — деньги, очень не хочеться прибавлять их в чужом кармане. Разработчики компиляторов в этом не заинтересованы. А этот вопрос строго говоря языка то и не касается.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали:
DC>>Вернемся к началу. Т.е. ты считаешь что С++ из области написания графических движков вытеснит другой инструмент типа Немерле или ОКамл? S>Лично у меня нет сомнения в том, что это таки произойдет. Я, конечно, дилетант в гейминдустрии, но свои две копейки вставлю. S>Насколько мне известно, плюсы — вовсе не такой уж суперпопулярный в ГД язык. Грубо говоря, современная игра состоит из трех уровней: S>- низкоуровневые битхаки для рисования (ассемблер)
Насколько я знаю — это в основном уже к шейдерам относиться. S>- ядро движка (С/С++) S>- геймплей (язык описания уровней)
Все верно.
Вот только я не заметил, чтоб было крайне сложно реализовать алгоритмы оптимизации сцены. Может я что-то не так делал? Море кода для этого, как открытого, так и не очень.
Собственно, С++ хорош не для ГД, а для 3D движка. В ГД — купил движок, накрутил скриптов, заплатил художникам — игра готова.
Ну чем Немерле принципиально лучше для алгоритмов оптимизации сцены? ФП? Я этот стиль и на С++ могу использовать, только он там редко где подойдет. Насколько я понимаю Немерле не чисто функциональный язык, поэтому оптимизации с многопоточностью здесь не пройдут, да и не видно пока 80-тиядерников.
Чем микрософтовские фреймворки для 3D принципиально лучше OpenGL — промышленного стандарта проверенного временем?
В чем принципиальное отличие о котором можно сказать — да это сильно упростит/удешевит/сделает более надежной разработку?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Если нам не помогут, то мы тоже никого не пощадим.
.
. Научные расчеты на большом количестве процессоров (ядер), будут быстрее выполнять функциональные языки, хотя в общем случае — 
. По поду прикладного ПО — вполне можно использовать С++ для написания ядра системы, а сверху накручивать прикладную логику каким-нибудь интерпретируемым языком, если грамотно сделать то будет и эффективность и скорость разработки.
1.2.0 alpha rev. 655
