Здравствуйте, AndreiF, Вы писали:
E>>Да я что, я так Сижу на работе, пишу игру, почитываю форум в перерывах. Вижу, человек пишет вещи, не соответствующие действительности, данной мне в ощущениях, да еще гнобит тех, кто пытается его поправлять
А вот, ни в коем случае не в плане аргументации, просто как заметка.
Ради интереса посмотрел объем исходиков в проекте, над которым сейчас работаю (3D-шутер для PC, находится на завершающей стадии разработки).
Примерно 5 мегов исходников на C++, не считая сторонних библиотек, и 1 мег скриптов.
Реальность, данная мне в ощущениях
Здравствуйте, eugene0, Вы писали:
E>А вот, ни в коем случае не в плане аргументации, просто как заметка. E>Ради интереса посмотрел объем исходиков в проекте, над которым сейчас работаю (3D-шутер для PC, находится на завершающей стадии разработки). E>Примерно 5 мегов исходников на C++, не считая сторонних библиотек, и 1 мег скриптов. E>Реальность, данная мне в ощущениях
Кстати, вот была такая игра — "Казаки" (реал-тайм стратегия, отличается тем, что может держать одновременно на игровом поле 16т юнитов (первая версия, сейчас до 64т дошли, по-моему, не помню). Конкурентам такие цифры и не снились. Имхо, одна из лучших отечественных игр.
Я всего ее кода не видел, только маленький кусок, но что я увидел там: она была написала на С++, и более того, стратегии AI для игры за разные страны (там у разных стран разные строения, оружие, стоимость ресурсов и прочее, поэтому по-разному надо действовать) были тоже написаны на С++ и упрятаны в DLL-ки с названиями стран (т.е. если ты хотел играть против, скажем, Австрии, то просто подгружалась соответствующая DLL-ка и начинала против тебя играть). На моей тогдашней слабенькой машинке все летало.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>И AWT . Правда, насколько я понимаю, его уже мало кто использует.
AVK>Swing, вобще то, поверх AWT работает .
"Не флейма ради, а токмо чтобы ясность дополнительную внести"
Не совсем да, но и не совсем нет AWT использует нативные контролы (в терминологии Свинга "тяжеловесные компоненты"). Swing из нативных использует только окна, остальные компоненты делает сам(т.е. свинг отвечает полностью и за их отрисовку, и за событийную модель, и т.д.). Кстати, Swing — прекрасный пример, что "программы и библиотеки на Java — таааакие тормоза!" — не более чем миф.. Продуманной оптимизацией все издержки Java покрываються много раз.. На "тормознутость" интерфеса Свинговых прог никогда не жаловался (разве что какой умник не выносил длинные расчеты в отдельный поток, но тут уже /dev/hands).
С другой стороны, компоненты Swing наследуються от абстрактных классов AWT (пример), хотя, конечно, реализация у них "с ноля" и они не являються обёртками над AWT-компонентами. Исключение — JFrame, JDialog, JWindow, JApplet и другие им подобные, которые наследуються от конкретных классов AWT и используют их логику (т.е. создают нативные контролы).
Так что утверждение "Swing поверх AWT работает" скорее неверно, чем верно
DC>>А ты себе представляешь сложность задачи? Унифицировать представление объектов в памяти на ВСЕХ возможных платформах. S>Да, представляю. Благо решения есть. Велкам в управляемые среды. Java, .Net.
Когда вышел ARM, когда вышла Java и .Net? Мало того за эти 20 лет очень сильно поменялось железо. Так что в далеком 85, даже 91 было несколько иначе. Но как тогда, так и сейчас остается приоритетом именно портируемость на уровне исходников, а это уже не мало для платформы где нет VM, но есть компилятор С++.
DC>>Кроме того к языку программирования это относится слабо. Кстати именно благодаря такому способу линковки С++ получил такое распространение и может использовать модули написанные на С, Fortran и т.д. S>Ничего подобного. Не благодаря, а вопреки. Обратный пример: дотнет, с совершенно другим способом линковки, может использовать модули написанные на С, Fortran и т.д. И С++ тоже очень бы сильно выиграл, если бы автор вовремя спустился с небес на землю.
Какую землю? см. ответ eao197. Я думаю это тебе надо чуток спуститься на землю, или хотя бы вернуться в то время мыслью.
DC>>Я вот не пойму что вы мне пытаетесь доказать? То что сборки под дот нет или компоненты Делфи лучше? S>Нет, мы просто иллюстрируем тебе какую-то фатальную близорукость комитета в совершенно очевидных вещах.
У комитета есть четкие задачи и цели, которые были сформулированы еще во время его создания, вместо обвинений в близорукости почитай в чем они заключаются. Кроме того, для тебя они могут казаться очевидными, а для членов комитета очевидными и более нужными могут казаться другие вещи. Мало того есть инструменты удовлетворяющие твоим потребностям. Внимание вопрос: Зачем хаять комитет? За то что они решают другие проблемы? Почему ты решил что то, что тебе кажеться очевидным является необходимым в первую очередь? Если оно действительно так оформляй предложение в комитет, предлагай реализацию и т.п. Wellcome.
DC>>С чем ты споришь? Я понимаю что такая линковка — это тормозная и часто неудобная штука. S>Не, пока не понимаешь. Проблема не в линковке. Ведь работают же компиляторы С++ поверх неё? Вот и нужно было уточнить спецификацию протокола. Безо всякого изменения механизма линковки — тем более, что комитет на линкер не влияет, а только на компиляторы.
А компилятор видимо сам программы собирает ? Т.е. ты полагаешь, что проблемы с разной кодировкой имен это самая важна проблема совместимости? Да проше простого написать тулзу которая будет перекодировать манглинг различных компиляторов. Толь вот функцию я то вызвать смогу, а объект передать — уже нет.
DC>>Я понимаю что неунифицированное представление объектов — это проблемы совместимости платформ и компиляторов.НО!!! Простой как сибирский валенок механизм линковки, обеспечивает простоту реализации этого инструмента на любой платформе!! Мало того очень трудно сделать одинаково хорошее представление для микроконтроллера/PC/RISC-сервера/... Ты еще не забывай, что на специфических платформах нет ни шаблонов, ни множественного наследования и т.д. Т.е. создав единый стандарт представления — не угодили бы никому. S>Всем бы прекрасно угодили. Это всё достижимо, нужно только понимать, что заниматься этим необходимо.
Как? Ты представляешь себе различие в представлении компилятором множественного наследования, витртуального множественного наследования на разных компиляторах? Мало того для платформы которая работает в реальном времени, от этого производители компилятора вообще отказались, как и от обработки исключений, ради оптимизации и эффективности. Вот тебе и разница. Здесь нет компромисса, мало того это не противоречит основным идеям создателя С++. Совместимость С++ с С и стремление к равенству по скорости кода, причина такой популярности С++, но так же и причина его основных недостатков.
DC>>Помимо всего прочего — кто мешает, собраться MC, GNU GCC и Comeau — и сделать стандарт представления и ему следовать?? S>Ну а комитету, который некоммерческий, кто мешает? Эрго: Хайнлайн прав.
Никто. Внеси предложение . .
Думаю можно найти предложения которые решали бы эту проблему и посмотреть причины отказов. Полагаю, что они будут довольно вескими.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Стандарт С++ их и не регламентирует. Влад я думаю ты прекрасно знаешь принцип работы простейшего компоновщика, который заменяет имена функций и переменных, определенных в др единице компиляции, на их адрес. Не знаю есть ли стандарт или какие-то регламентирующие документы, если тебе это так важно могу поискать.
VD>Я то как раз знаю. Стандартов нет. Точнее у каждого свои. Борланд с МС еще как-то пытались кооперироваться, но толку было мало. Интел еще что-то там под МС косить пытается. Но те же GCC и VC не совместимы. Так что С++ — переносим только на уровне исходников.
Переносимость на уровне исходников, это и есть основной приоритет комитета.
DC>>А по поводу задач: задачи системного программирования: написание ОС, драйверов, компиляторов и т.п.
VD>ОС, драверы и темболее компиляторы пишутся на управляемых языках ничем не хуже, и даже лучше. И если первое пока, что находится в эксперементальной стадии, то компиляторы уже давно пишутся как на управляемых языках так и на неуправляемых функцинальных. Причем все кто пробовал использовать хорошие ФЯ для написания компиляторов находят, что это значительно удобнее нежели использовать С/С++ для этой цели.
VD>Так что это утверждение ошибочно. Это всего лишь самообман.
Влад в чем заключается мой самообман? В том, что ОС и Драйверы на управляемых языках экспериментальные? Или в том что на данный момент подавляющее большинство ОС и драйверов написано на С++ и/или С?
DC>> Хотя я думаю, что для написания компиляторов есть более подходящие инструменты, но я тут профан .
VD>Зато я кое что понимаю. С++ — это самый неудобный иструмент для этогою.
Т.е С++ говно полюбому? Да Влад это как мантра.
DC>> По поду прикладного ПО — вполне можно использовать С++ для написания ядра системы, а сверху накручивать прикладную логику каким-нибудь интерпретируемым языком, если грамотно сделать то будет и эффективность и скорость разработки.
VD>Остается вопрос зачем использовать С++ для того, что в несколько раз проще пишется на других языках? Я еще понимаю супер-корпорации вроде МС которые вполне могут позволить себе создать прототип, а потом приказать переписать его на С++ просто ради оптимизации. Но лишние мегабаксы есть только у 5-6 компаний в мире. Остальные живут в рамках жесточайшей конкурениции. И стло быть использовать С++ равносильно надеванию на себя гандикапа.
А если компания его использует уже 10-15 лет? Зачем при налаженном процессе переходить куда-то?
VD>>>А какая разница? К задачам это отношения не имеет. Средства могут различаться в зависимости от задач.
DC>>Тогда зачем спрашивал?
VD>Затем, что С++ практически всегда наихудший выбор. Вот и интересно с какой целью люди выбирают именно его? Не уж то так тяжело переучиваться?
Нет, просто на С++ тонны кода, возможности его не сильно хуже существующих управляемых языков. Понимаешь чтобы вытеснить С++ нужно предложить что-то намного лучшее. Для Java и .Net снижают стоимость разработки, и порог вхождения низкий, специалистов проще найти. Но только для некоторых областей!!! Где собственно С++ наиболее плох для применения.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Собственно, С++ хорош не для ГД, а для 3D движка. В ГД — купил движок, накрутил скриптов, заплатил художникам — игра готова.
VD>Ну, так продемонстрируй хоть что-то что делало бы С++ предпочтительным для этих самых движков.
Да хотя бы то, что возможностей у языка не меньше, а библиотек просто море + это проверенный инструмент.
А теперь все таки ответьте на мой вопрос. Что кардинально изменит Немерле или ОКамл. Не просто уменьшат многословность, а именно дадут?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>> Влад я сказал, что в MC не смогут разработать нормальный фреймворк для этого? Мало того после требований Висты, что-то у меня возникают сильные опасения, что "приемлемым по производительности" оно станет благодаря новым железкам, а не разработчикам в MC.
VD>Виста как и другой софт выпскаемый МС создается в рассчете на сегодняшнее зелезо. И это правильно, так как если у меня в машине 3D-акселератор с поддержкой DX 9.0, двух-ядерный процессор и 1-2 гига памяти, то глупо не задействовать это богатство для улучшения комфорта и удобства. Лично Вистой я очень доволен.
Влад, я мощьности на свой комп ставлю не для микрософта и ее ОС, а для того чтоб прикладное ПО там быстрее бегало.
[оффтопик]
Меня если честно удручает такое положение, я всерьез задумался над переходом на KUbuntu. Я понимаю что мне дал XP — большую стабильность, у меня он стоит уже 4 года, при этом синих экранов вообще не вспомню, подвисаний не больше 3-5 в год, учитывая то, что ставил я много всяких программ. Что мне даст виста? 3D интерфейс который мне не нужен? Какие принципиальные удобства я получу? Исправление собственных багов ценой моих денег и ресурсов моего компа?
[/оффтопик]
DC>>Рендерер = Движок ?
VD>По вычислетльной нагрузке это значительно больше. По сложности алгоритмов — тоже.
. А по сложности задачи? Движок в том или ином виде содержит в себе рендерер. Он правда заточен на другое.
DC>>>>Здорово, вот сошлась куча специалистов отрасли, потрындела 10 лет и в итоге выдала полный бред??
VD>>>Я говорю о конкретных требованиях конкретного человека. Блин, скачай ppt-у и пчитай. В его требованиях основными критериями являются надежность и безопасность. Ни шагу в этом направлении в новм стандарте нет.
DC>>Хм, ну С++ вобщем то универсальный язык,
VD>Ага. А в Киеве дядка. И что?
Сколько в комитете людей от компаний занимающих производством движков?
DC>>полагаю комитет руководствовался не пожеланиями конкретного человека. Верю что решения комитета могут не решить его проблем. Но утверждать, что улучшения которые появятся в 2009 году — бред, который ничего не изменит — глупо, по меньшей мере.
VD>Я не утверждал, что это бред. Я сказал, что С++ как раз то, что они исползуют и в чем находят (на мой взгляд совершенно обоснованно) море проблем. Интересно, что в качестве сравнения они использую C#, Java и Хаскель. Причем находят у всех языков ряд недостатков (впрочем как идостоинств).
Ты сказал, что стандарт ничего не изменит. Т.е. этот стандарт бред, несуразица
DC>>Сразу видно команда . Ты пойми Влад, я не против новых инструментов, если они появятся и решат проблемы в какой-то отрасли это просто здорово. Но просто не понимаю смысла говнять имеющийся инструментарий. Язык С++ далеко не идеален, но он достаточно хорош для решения большинства задач.
VD>Он недостаточно хорош почти для любой задачи. Может в те времена когда Страуструп произнес эту фразу, она и была справедлива, но сейчас это не так.
Достаточно хорош — это означает, что любую задачу можно решить используя высокоуровневые конструкции и современные приемы проектирования, при этом добиться максимальной эффективности.
DC>>Вернемся к началу. Т.е. ты считаешь что С++ из области написания графических движков вытеснит другой инструмент типа Немерле или ОКамл?
VD>Это дело времени. С++ если и останется, то как средство оптимизации узких мест.
DC>> Поскольку требования к языку в статье и немало рендереров на ОКамле являют какую-то тенденцию. Когда это по твоему произойдет?
VD>Срок может оказаться большим из-за косности мышления. Первые управляемые движки уже появились. Думаю, что через лет 5-10 можно ожидать, что народ перейдет на некую альтернативу. Нужда в ней назрела. Пока об этом говорят, только действительно дальновидные люди, но чем дальше, тем больше людей будет это понимать. Даже D и тот намного лучше чем С++.
Здорово . Только вот переход будет долгим не столько из-за дальновидности или еще чего-то, новый инструмент должен себя зарекомендовать, мало того чтобы вытеснить, он должен дать что-то что кардинально улучшит процесс разработки.
VD>Применение же дотнета в играх пока может сдерживаться тем фактом, что он доступен только на Xbox 360 и Windows. Но моно уже работает на туче платформ и если его подкрутят (и реализуют XNA), то проблема будет очень неплохим решением.
Возможно, время покажет.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Насчет линкинга — где посмотреть, не знаю. Но интероп в дотнете сделан очень тщательно. Подохреваю, что JNI на джаве должен работать с фортраном и на аиксе.
E>Автор C++ сделал язык. Инструменты для этого языка писали совсем другие люди и конторы, которые при этом преследовали свои корысные интересы.
Что именно ты имеешь в виду под инструментами? Линкер? Он не для этого языка. Ок, я согласен с тем, что автор свою роль сыграл. Но комитет почему-то не сделал столь очевидных шагов. И это притом, что язык позиционируется как системный! Т.е. в нем предусмотрена масса платформенных фич, типа моделей памяти (кто еще помнит, что это такое?) и битовых полей.
Почему при этом комитет не удосужился стандартизовать такую простую вещь, как манглинг — я не понимаю.
E>Пора бы уже понять, что C++ возник в совсем иных условиях. И достиг критической массы, после которой уже нельзя было ничего менять, C++ в условиях, когда принципа write once run everywhere в мейнстриме еще не было.
Ну почему нельзя-то? Ведь меняли же. Язык бурно развивался. Это не ошибка, это намеренный саботаж. E>Это потом уже богатая контора Sun учла опыт, в том числе и C++. И затратив N мегадолларов на разработку Java и еще M мегадолларов на ее раскрутку (причем не понятно насколько N меньше/больше M) поначалу получила медленного уродца, который более-менее оправился только к 99-му-2000-му. Вполне возможно, что на разработку C++ было потрачено даже меньше средств за все время его существования, чем на рекламу Java.
Это никак не оправдывает некомпетентность комитета.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Насчет линкинга — где посмотреть, не знаю. Но интероп в дотнете сделан очень тщательно. Подохреваю, что JNI на джаве должен работать с фортраном и на аиксе.
Дык и работает, только вот фортрановский модуль на AIX-е нигде кроме AIX-а работать не будет. Да и работать будет, потому что JNI на AIX-е реализуется через нативные AIX-овские коды. В таких условиях и к C++ модули C/Fortran спокойно линкуются.
E>>Автор C++ сделал язык. Инструменты для этого языка писали совсем другие люди и конторы, которые при этом преследовали свои корысные интересы. S>Что именно ты имеешь в виду под инструментами? Линкер?
И компилятор. C++ные компиляторы денег стоили, а некоторые и сейчас стоят (сами компиляторы, даже без IDE).
S>Почему при этом комитет не удосужился стандартизовать такую простую вещь, как манглинг — я не понимаю.
Боюсь, что одного манглинга мало. К тому же, к моменту начала стандартизации (89-90 гг) уже был большой зоопарк разных компиляторов с собственными правилами манглинга. Заставить их тогда что-то переделывать было вряд ли возможно, ведь тогда могли пострадать клиенты этих производителей компиляторов (ведь пришлось бы переходе на новые версии перекомпилировать весь ранее написанный код, а может еще и править его).
E>>Пора бы уже понять, что C++ возник в совсем иных условиях. И достиг критической массы, после которой уже нельзя было ничего менять, C++ в условиях, когда принципа write once run everywhere в мейнстриме еще не было. S>Ну почему нельзя-то? Ведь меняли же. Язык бурно развивался. Это не ошибка, это намеренный саботаж.
Изменений в языке, которые бы нарушали совместимость с предудущим кодом было не так уж и много. В основном язык обрастал возможностями.
S>Это никак не оправдывает некомпетентность комитета.
Не могу судить о комитете. Более того, я сам придерживаюсь мнения, что комитеты вряд ли могут привести к чему-нибудь хорошему. Но, по крайней мере, в одной области комитет уже сыграл свою положительную роль -- стандарт хоть как-то обеспечивает переносимость C++ программ в исходных текстах между платформами и компиляторами. Что для языка, с самого начала жизни которого различных компиляторов которого было множество, означало очень и очень многое.
Большего от комитета я и сам не жду. Имхо, самые лучшие черты C++ приобрел, когда им занимались отдельные конкретные люди -- Страуструп, как дизайнер языка, и Степанов, как автор STL.
Я просто прошу воздерживаться от резких высказываний в адрес автора C++, поскольку мы сейчас находимся совсем в других условиях. Да и не сделал никто из нас ничего настолько же значимого, чтобы иметь моральное право брать на себя роль судьи.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, dr.Chaos, Вы писали:
DC>Когда вышел ARM, когда вышла Java и .Net? Мало того за эти 20 лет очень сильно поменялось железо.
За какие 20 лет? С++ в современном виде едва ли не моложе джавы. Когда в него ввели частичную специализацию шаблонов?
DC>Так что в далеком 85, даже 91 было несколько иначе. Но как тогда, так и сейчас остается приоритетом именно портируемость на уровне исходников, а это уже не мало для платформы где нет VM, но есть компилятор С++.
Приоритетом должны оставаться потребности пользователей, а не стремление к прекрасному.
DC>Какую землю? см. ответ eao197. Я думаю это тебе надо чуток спуститься на землю, или хотя бы вернуться в то время мыслью.
В то время — это в какое? Когда был принят актуальный стандарт С++? Сколько еще нужно ждать, чтобы комитет наконец задумался о вопросах интеропа? Бред какой-то. Газотурбинный двигатель изобрели, а до щеколды не додумались.
DC>У комитета есть четкие задачи и цели, которые были сформулированы еще во время его создания, вместо обвинений в близорукости почитай в чем они заключаются. DC>Кроме того, для тебя они могут казаться очевидными, а для членов комитета очевидными и более нужными могут казаться другие вещи. Именно поэтому я и ушел с плюсов — разошелся, видишь ли, в целях и задачах с комитетом.
Да, кстати, пользуясь случаем передаю привет от Хайнлайна комитету W3C.
DC>Мало того есть инструменты удовлетворяющие твоим потребностям. Внимание вопрос: Зачем хаять комитет? За то что они решают другие проблемы?
Конечно.
DC>А компилятор видимо сам программы собирает ? Т.е. ты полагаешь, что проблемы с разной кодировкой имен это самая важна проблема совместимости? Да проше простого написать тулзу которая будет перекодировать манглинг различных компиляторов. Толь вот функцию я то вызвать смогу, а объект передать — уже нет.
Вот именно, только почему-то комитет вообще не счел нужным упомянуть о такой тулзе или подумать о том, какая информация может быть ей нужна. Передачу объектов тоже можно было сделать вполне человеческим образом — мне, если честно, лень тут в двух строках делать работу, с которой не смогла справиться Вся Королевская Рать за двадцать лет. Просто им хотелось заниматься не этим.
DC>Как? Ты представляешь себе различие в представлении компилятором множественного наследования, витртуального множественного наследования на разных компиляторах?
Конечно представляю. Я вот только не могу понять одного — почему нельзя было стандартизовать формат метаданных для интеропа, оставив возможность внутренней реализации для повышения производительности? Это же ничему не противоречит. DC>Мало того для платформы которая работает в реальном времени, от этого производители компилятора вообще отказались, как и от обработки исключений, ради оптимизации и эффективности.
Производители компилятора — вообще отдельные люди. DC>Вот тебе и разница. Здесь нет компромисса, мало того это не противоречит основным идеям создателя С++. Совместимость С++ с С и стремление к равенству по скорости кода, причина такой популярности С++, но так же и причина его основных недостатков.
Да ничего подобного. С++ не стремился к равенству по скорости; лозунг С++ — не надо платить за то, чем не пользуешься. Поэтому вполне в рамках концепции была бы стандартизация интеропа, пусть даже она и приводила бы к потерям производительности при кросс-компиляторной линковке. Главное — что а) эта линковка была бы возможна и б) производительность в случае ее отсутствия не страдала бы.
Причем заметь — это мы обсудили одну только маахонькую фичу — компонентность, а ведь это не она одна. То, что комитет наплевал на возможность поставлять библиотеки в кросс-компиляторном бинарном виде, это только их вина. Ты упорно отказываешься видеть, что нету в С++ никакой компонентности. И уже 15 лет комитет страдает фигнёй от избытка интеллекта. DC>Никто. Внеси предложение . .
Да у них этих предложений тонны.
DC>Думаю можно найти предложения которые решали бы эту проблему и посмотреть причины отказов. Полагаю, что они будут довольно вескими.
Мне всё равно, насколько вески эти причины. Хотя скорее всего причина ровно одна — отсутствие консенсуса. См. Р. Хайнлайна.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, dr.Chaos, Вы писали: DC>А теперь все таки ответьте на мой вопрос. Что кардинально изменит Немерле или ОКамл. Не просто уменьшат многословность, а именно дадут?
А кроме уменьшения многословности ничего дать-то и нельзя. См. Тезис Чёрча. Впрочем, с учетом константности плотности ошибок ничего, кроме краткости, и не требуется.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, jazzer, Вы писали:
J>Кстати, вот была такая игра — "Казаки" (реал-тайм стратегия, отличается тем, что может держать одновременно на игровом поле 16т юнитов (первая версия, сейчас до 64т дошли, по-моему, не помню). Конкурентам такие цифры и не снились. Имхо, одна из лучших отечественных игр.
J>Я всего ее кода не видел, только маленький кусок, но что я увидел там: она была написала на С++, и более того, стратегии AI для игры за разные страны (там у разных стран разные строения, оружие, стоимость ресурсов и прочее, поэтому по-разному надо действовать) были тоже написаны на С++ и упрятаны в DLL-ки с названиями стран (т.е. если ты хотел играть против, скажем, Австрии, то просто подгружалась соответствующая DLL-ка и начинала против тебя играть). На моей тогдашней слабенькой машинке все летало.
Предполагаю, что такой подход использовали именно из-за того, что там такое огромное кол-во юнитов на поле одновременно. Возможно, скриптовый движок не потянул такое кол-во выполняемых одновременно скриптов.
IMHO если юнитов поменьше (у нас, например, обычно не больше 20), то лучше все-таки писать скрипты. Тогда можно будет переложить работу с программистов на дизайнеров миссий, что во многих отношениях правильно.
Здравствуйте, VladD2, Вы писали:
DC>> Влад я сказал, что в MC не смогут разработать нормальный фреймворк для этого? Мало того после требований Висты, что-то у меня возникают сильные опасения, что "приемлемым по производительности" оно станет благодаря новым железкам, а не разработчикам в MC.
VD>Виста как и другой софт выпскаемый МС создается в рассчете на сегодняшнее зелезо.
Сегодняшнее железо бывает разным, и скажем, на ноутбук, где проблема времени жизни от аккумулятора является одной из важнейших не имеет смысла ставит операционную систему которая будет впустую потреблять много энергии.
VD> И это правильно, так как если у меня в машине 3D-акселератор с поддержкой DX 9.0, двух-ядерный процессор и 1-2 гига памяти, то глупо не задействовать это богатство для улучшения комфорта и удобства.
Глупо не иметь возможности задействовать это богатство. Но так же бессмысленно требовать DX 9.0 видеокарту, двух-ядерный процессор и 1-2 гига памяти на офисном компе у секретарши на котором в основном читают почту и серфят Инет.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали: DC>>А теперь все таки ответьте на мой вопрос. Что кардинально изменит Немерле или ОКамл. Не просто уменьшат многословность, а именно дадут? S>А кроме уменьшения многословности ничего дать-то и нельзя. См. Тезис Чёрча. Впрочем, с учетом константности плотности ошибок ничего, кроме краткости, и не требуется.
FR,
DC>>>А теперь все таки ответьте на мой вопрос. Что кардинально изменит Немерле или ОКамл. Не просто уменьшат многословность, а именно дадут? S>>А кроме уменьшения многословности ничего дать-то и нельзя. См. Тезис Чёрча. Впрочем, с учетом константности плотности ошибок ничего, кроме краткости, и не требуется.
FR>Все бежим изучать J?
Вывод неправильный. Видел программы для J которые используют OpenGL? Чудес не бывает: любая достаточно сложная программа на J так же будет использовать некоторый API, а следовательно там уже не получишь такой краткости, как на ядре. Подобные API просто предоставляют список методов, которые можно подёргать.
Мне думается, в выигрыше язык, который обладает наиболее продвинутым клеем (просто "дёрнуть функцию" недостаточно) и возможностями по созданию библиотек которые предоставляют такие клеящие поверхности.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали: DC>>А теперь все таки ответьте на мой вопрос. Что кардинально изменит Немерле или ОКамл. Не просто уменьшат многословность, а именно дадут? S>А кроме уменьшения многословности ничего дать-то и нельзя. См. Тезис Чёрча. Впрочем, с учетом константности плотности ошибок ничего, кроме краткости, и не требуется.
Хм, т.е. все улучшения которые дают Немерл и Окамл это уменьшение многословности? Мда уж что-то тогда индустрия на месте топчется получается, только шаги красивше и меньше выходят.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, dr.Chaos, Вы писали:
DC>Хм, т.е. все улучшения которые дают Немерл и Окамл это уменьшение многословности? Мда уж что-то тогда индустрия на месте топчется получается, только шаги красивше и меньше выходят.
Ну ИМХО Асм -> С тоже в значительной мере уменьшение многословности...
Здравствуйте, eao197, Вы писали:
E>Не мог. Первые версии компилятора C++, даже с поддержкой шаблонов и исключений, были всего лишь препроцессорами, генерившими C-шный код.
Шаблоны и исключения появились намного позже, уже в 90-х.
E> Далее работали штатные C-компиляторы и линкеры конкретной целевой платформы. Первый "родной" компилятор C++, Zortech C++, был написан в конце восьмидесятых для MS-DOS и не поддерживал самых продвинутых возможностей языка.
Это каких?
E>И я не очень представляю себе, как в 87-м или 89-м можно было выработать единый стандарт объектных файлов для 16-ти битовой MS-DOS с разными моделями памяти и 32-х битовыми мейнфреймами и RISC-рабочими станциями.
А мозг на что человеку даден? Нужно было подумать им немного.
E>Тем более, что в отличии от нынешних времен, когда компиляторы менстримовых языков (Java и C#) принято раздавать бездвоздмездно (т.е. даром), в то время на продажах компиляторов деньги зарабатывали.
Вот он корень зла!
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Сижу на работе, пишу игру, почитываю форум в перерывах. Вижу, человек пишет вещи, не соответствующие действительности, данной мне в ощущениях, да еще гнобит тех, кто пытается его поправлять
AWT использует нативные контролы (в терминологии Свинга "тяжеловесные компоненты"). Swing из нативных использует только окна, остальные компоненты делает сам(т.е. свинг отвечает полностью и за их отрисовку, и за событийную модель, и т.д.). Кстати, Swing — прекрасный пример, что "программы и библиотеки на Java — таааакие тормоза!" — не более чем миф.. Продуманной оптимизацией все издержки Java покрываються много раз.. На "тормознутость" интерфеса Свинговых прог никогда не жаловался (разве что какой умник не выносил длинные расчеты в отдельный поток, но тут уже /dev/hands). 
.
1.2.0 alpha rev. 655
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Если нам не помогут, то мы тоже никого не пощадим.
