C++ ld тупит, а может я..

>> Ну-ну. А от использования какого языка оно _не_ страдает?

> верифицируемого. статически (как в http://programatica.cs.pdx.edu/

Я с уважением отношусь к CS, но меня интересуют технологии, применимые прямо сейчас. И вся эта статическая верификация - это игрушка на сегодня (да, я читал о SPARK).

> очень многие конструкции приводят к неопределённому поведению

Есть почти в любом языке.

> перегрузка операторов

Есть в Аде.

> плюс специфика control flow (порядок вызова конструкторов в иерархии с виртуальным наследованием, например

Просто не используй это.

> у подхода "лепим всё в кучу" их намного больше

Не лепи всё в кучу - проектируй разумно, используй модульные средства языка.

>>Да и в пределе мы всё равно получим необходимость интеграции всего в рамках одного языка

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

Насколько я знаю, там выносят некритические участки кода в скрипты. Представь, это делается не только в играх :)

>Я с уважением отношусь к CS, но меня интересуют технологии, применимые прямо сейчас

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

>И вся эта статическая верификация - это игрушка на сегодня

есть задача. есть решение. оно работает. почему игрушка ? потому что его не разрекламировали M$ и Sun ?

да и просто покажи мне сколько-нибудь серьёзный проект на C++, не использующий средства вроде LInt. верификацию выполняют в любом случае, вопрос только в том - насколько эффективно. для C++ сделать её эффективной очень сложно

>Есть почти в любом языке

не в таком количестве

>Есть в Аде

бывает. я не писал на ADA

>Просто не используй это

это был только один пример из множества подобных. если не использовать возможности C++ из-за того, что они могут привести к неопределённому поведению - мне потребуется отказаться от 90% языка. чего я совершенно не хочу

>Не лепи всё в кучу - проектируй разумно, используй модульные средства языка

>Насколько я знаю, там выносят некритические участки кода в скрипты. Представь, это делается не только в играх :)

мне одному кажется что эти две фразы немножко противоречат друг другу ?

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

>>Не лепи всё в кучу - проектируй разумно, используй модульные средства языка

>>Насколько я знаю, там выносят некритические участки кода в скрипты. Представь, это делается не только в играх :)

>мне одному кажется что эти две фразы немножко противоречат друг другу ?

Это только кажется.

>порядок вызова конструкторов в иерархии с виртуальным наследованием, например - это ведь просто праздник

По-моему, как раз здесь все довольно просто и логично. У Липмана это неплохо расписано в "Inside The C++ Object Model".

>да и просто покажи мне сколько-нибудь серьёзный проект на C++, не использующий средства вроде LInt.

Чтобы далеко не ходить - Aldec ALint, linting tool для Verilog/VHDL, в разработке которого принимаю непосредственное участие. Т.е. при разработке статического анализатора кода для HDL не используются инструменты статического анализа кода для C++ :). Во многом это благодаря правильному проектированию и отсутствию быдлоко^W низкоквалифицированных программистов в команде. Хотя, признаю, такие вот проекты - большая редкость.

Да согласен, у "плюсов" очень много недостатков. А сам синтаксис делает довольно сложной разработку полноценных рефакторилок, линтинг тулов и тому подобных вещей. Но факт остается фактом - во многих областях C++ остается незаменимым. Хотя бы по той причине, что для окамля нет такого количества библиотек и инструментов разработки).

P.S. Когда узнаешь о проблемах, которые окружают hardware design, все эти плюсовые мемори лики кажутся такими мелкими пустяками... :) Вот уж где действительно никак без средств верификации!

P.P.S. Раз уж начал о проектировании и верификации устройств - в мире HDL тоже есть своеобразный "С++", только называется он System Verilog. Разработчики стандарта, гады, сделали настоящий винегрет из языковых конструкций. Тем не менее, громоздкий и неуклюжий SV уверенно вытесняет красивый и стройный VHDL из традиционных ниш последнего (а в Японии - уже давно вытеснил) по одной простой причине - он эффективен и велосип^W многофункционален.

>и, кстати, почему это LISP ленивый ?

неточно выразился. В том смысле, что на Хаскелле ленивость надо специально писать в синтаксисе, а в Лиспе -- в семантике.

просто интересно стало другое: есть системы разной "жёсткости": по одной оси статическая-динамическая типизация, по другой оси -- императивный код, функциональный "жестко заданный" в каких-то пределах, функциональный с "ленивыми" вычислениями. (Время выполнения, производительность) где-то точкой на графике в этих двух осях. Для реального времени, имхо, ленивость мешает -- с какими нижними/верхними ограничениями по времени может выполняться такой код? Для императивного, по крайней мере, эта цифра предсказуема (теми же статическими верификаторами. Для ленивых вычислений -- что, верификатор должен быть динамическим? или max(все варианты трассы кода) ? или тупо втыкать что-то вроде dtrace в рантайм функциональщины?)

То, что прототип проще набросать на функциональщине -- понятно (особенно, если есть формализованная спецификация, для которой можно написать компилятор). Не очень понятно, как профилировать код на стыке функциональщины/императивного кода (разве что свою остнастку написать, которая вряд ли подойдет для другого проекта ), где искать боттлнеки(которые могут уйти куда-то в другие места при другой нагрузке).

>>а если шкала неравномерна? ну типа вот тут лаги возникли, а тут -- попустило

>в таком примере шкала остаётся той же, просто мы выбрасываем ряд кадров. в полном соответствии с нашим "реальным временем", никак его не искажая при этом

ну для шутеров наверно да (можно выкинуть кадры, и ходить сквозь стены большими прыжками), гладкость пофигу. Время у разных игроков синхронизировать чем-то вроде протокола NTP , шкала оси времени будет одинаковая, а скорости -- разные, в зависимости от производительности железа/канала каждого игрока.

А для стратегий/космосимов с червоточинами/что-то типа Portal по сети -- наверно нет (если развитие зависит от отыгранного времени, тот, у кого будет лучше "гранулярность", будет иметь больше квантов времени и лучшее развитие).