Здравствуйте, konsoletyper, Вы писали:
K>Движки действительно писать можно только на C++, а жаль .
Извините за переход на личность, но у вас уже не в первый раз проскальзывает просто таки жуткое неприятие C++.
Но, как я понял, проекты в миллионы строк в компании с низкоквалифицированными программистами на C++ вам вести не приходилось. Так откуда же такая нелюбовь ожесточенная? Что же в нем такого отталкивающего?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
AndreiF wrote: > CC>На любом другом кстати тоже... > Это уже отельный вопрос. А факт — это то, что универсальность плюсов > сильно преувеличивают. И никакого Q4 "на чистом С++" никто не напишет.
Я вот заявляю, что Оффис без VB в принципе не написать. Иначе как на нем
макросы писать?
Сергей Губанов wrote: > Да! Вот именно! Но далеко не любой. Иные наборы машинных команд (к > каковым относится и набор команд x86) при всём желании невозможно > назвать чистыми. Придумать хороший набор команд не просто.
MIPS32 — очень чисто и красиво.
konsoletyper wrote: > C>Напишешь Quake4 на Питоне? > Нафига? Вон, Цивилизация 4 на питоне фактически написана, только движок > на C++.
Поэтому CivIV всеми и считается жутко тормозящей
> А в кваке нет ничего такого, что требовало бы четырёхэтажных > скриптов. Фактически, почти вся игра состоит из одного движка. Движки > действительно писать можно только на C++, а жаль . Может быть, в будущем > что-то изменится.
А зачем?
Здравствуйте, Lloyd, Вы писали:
L>А как же пачка багов, которые nikov обнаружил в компиляторе только-только начав с ним работать?
Он такие пачки где угодно находит. Компиляторы МС и РеШарпер не исключение.
L>Страшно подумать, что выплыло бы, если бы он попытался использовать его в продакшн-е.
На самом деле ничего страшного. Большинство найденных багов экзотика с которой в жизни не сталкнешся. Да и не вызвают они особых проблем. Максимум пришлось бы на форум за консультацией обратиться. Вот проблемы с Юникомдом еслине порешить, то проблем будет намного больше.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Я бы хотел услышать ответ из первоисточника. E>Поскольку твое мнение, по крайней мере на моем опыте, не имеет ничего общего с действительностью.
Слушай. Только вот похоже его не интересуют ответы тем кто не хочет уважать чужое мнение.
E>Весь стандарт в подавляющем большинстве случаев и не нужен. E>Не всегда даже нужна поддержка специализаций шаблонов, не говоря уже о частичной специализации.
Да, да. Вот разумные люди и ограничивают набор С++ фич до фич С. Далее следует разумный вывод о том, что использование за одно и С-компилятора даст им бльшую переносимость с меньшим геморроем. И я их понимаю. Уж если ограничивать себя ради совместимости, то делать это полседовательно.
E>Сколько некачественных C++ компиляторов, когда и на каких платформах тебе доводилось видеть или использовать. И сколько в это же время и на этих же платформах было компиляторов с отличных от C/C++ языков?
Я не видел ни одного качественого компилятора С++ вообще. Слышал про один, но в руках не деражал. В прочем, это не мешало мне писать код для Win32 на VC 1.5, 5, 6, 2002, 2003, а так же Ваткоме и Борланде. Конечно же о переносимости и речи не шало.
В то же время переносимых компиляторов других языков выше крыши. Одних Лиспов за это время наклепано шутк 20. А уж если считать разные Обероны и Фир Паскли, то их число наверно дойдет то сотен. И большинство из них намного более полно соблюдают стандарты языков.
VD>>Сложно потому что много UB.
E>Это к портируемости вообще имеет косвенное отношение.
Еще как имеет. Если ты допустил UB в программе (скорее всего не явно), то на одной платформе все может работать, на другой валиться с неясными причинами. А иной раз даже валиться на ровном месте без обявления войны после долгих лет безупречной работы.
VD>>Сложно потому, что язык в угоду оптимизации создает массу сложностей вроде платформно-зависимых типов...
E>Платформенно-зависимые типы не являются проблемой даже если требуется организовывать обмен данными между различными платформами.
Явяютя. И не признавать это можно только от очень большой предвзятости.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
J>Ты не согласен? Старая? И когда же метапрограммирование начало рассматриваться и применяться как полноценный метод программирования наряду с другими? До рождения С++?
Ага. За долго. Где-то в 50-тых.
J>Только не надо говорить, что метапрограммирование появилось, как только появился первый интерпретатор с командой eval (вообще говоря, тут и eval не нужен — ты можешь просто сгенерить из своего скрипта рядом файл с новым кодом и позвать его — чем не метапрограммирование).
Конечно не надо. Оно появилось за долго до этого. Первые компьютеры программировались в маш.кодах и тогда метапрограммирование очень сильно выручало.
Далее для облегчения создания компиляторов был придуман BNF и так называемые компиляторы компиляторов. Первый из них появлися где-то в 1960-1965-ом (Atlas Autocode).
С++ же появился в 1985-ом. Чувствуешь разницу? И кстати, причем тут С++. Макросы были еще в С, а метапрограммирование на шаблонах появилось вообще где-то во второй половине 90-ых.
ЗЫ
Ейбогу С++ — это вра. Более того — это отдельный мир. Для тех кто в нем живет ничего кроме него вокруг не существует.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
J>Ну и макросы макроассемблера тоже
А как же?
J>давайте все же разделим, что мы считаем метапрограммированием, а что — нет.
Давай. Мое определение очень точно — это написание программы которая порождает другую программу.
Ты удивишся, но макросы в С — это чистешей воды метапрограммирование. Причем иной раз более эффективное чем последняя версия шаблонов С++. Вот только создающая много проблем и имеющая тучу недостатков.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
J>Шаблоны в С++ тоже вон были давно, но применяться для метапрограммирования и программирования в функциональном стиле они стали совсем недавно,
Шаблоны то конечно были. Правда не очено давно (меньше чем существует С++), но вот одна загвоздка. Для их применения в целях метапрограммирвоания не просто шаблоны, а шаблоны допускающие рекурсивное определение, а это появилось в реальных компиляторах только где-то в конце 90-ых прошлого века. Даже VC 6 выпуска 1998 года имел кучу проблем в этой области и реально применяться для этого не мог. Следующая версия VC вышла в 2002 году.
Меж тем макросам С столько же лет как и самому С. И это далеко не первый случай применения специальных мета-языков.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
J>Так почему же _сейчас_ все бросились использовать шаблоны и препроцессор для вещей, на которые они изначально не были рассчитаны? Ответ простой: потому что _сейчас_ стало ясно, что без этого не жить.
Это твой взгляд на мир из твоего мира (в котором кроме С++ ничего не видно).
Но есть и другие взгляды.
Есть люди которые занимались метапрограммированием на препроцессоре С еще когда и С++ небыло. Кстати, ты будешь подавлен, но Страуструп во всю занимался метапрограммированием на макросах С. Достоверно известно, что первая реализация шаблонов была реализована на препроцессоре С. Не хило правда?
Еще были люди которые писали внешние метапрограммы, которые ты называешь кодогенераторами.
Еще были те кто использовал тот же Лисп.
Еще были те кто использовал метапрограммирование в динамических языках типа Питона. В нем метапрограммирование тоже появилось до того как Шаблоны С++ стали позволять рекурсивные вычисления.
В общем, метапрограммирование появилось практически параллельно самому программированию и все это время совершенствовалось и развивалось. Есть разные подходы к метапрограммированию. И надо признать, что подход С++ многие считают как раз неверным. И я в том числе.
Если уж мы хотим иметь встроенные в язык средства метапрограммировани, то разумно было бы хотеть так же, чтобы метапрограммы писались на том же языке, что и обычные. В Лиспе — это так. В Немерле — это так. А вот в С++ — это не так. В нем как бы был нйден новый куций функциональный язык реализованный как побочный эффект от рекурсивного определения шаблонов. И это совсем не тот же язык что С++. Плюс к тому же он интерпретируемый и очень ограниченный как в выразительном плане, так и в функциональном. Попробуй, например, с его помощью прочитать что-то из внешнего файла.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
CC>Все зависит от квалификации человека. Плохой и нечитабельный код можно написать практически на любом более менее серьезном ЯП
Несомненно! Язык — это только усилитель тех или иных свойсвт. И С++ удивительно гормонично сочетает в себе возможности по усилению ошибок и сложности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Так BrainFuck очень простой язык.
Тогда определитесь с терминалогией. Простой язык — это язык на котром просто писать? Который имеет простой синтаксис? Который имеет простую семантику? Который имеет простые синтаксис и семантику? Который логичен, интуитивно понятен и безопасен?
Все это разные вещи. И все это можно понимать под простатой.
Брэйнфак прост синтаксически и семантически, но не интуитивен и не понятен.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
CC>Нельзя быть немного беременной. Или кроссплатформ или нет. Иначе получается кросс только для негуевых прог.
Значит С++ не кросплатформный? У него в стандарте тоже нет переносимого ГУИ.
А в Моно есть поддержка GTK. И сборки написанные для него переносимы туда где есть GTK.
Вообще это бред про Моно уже достал.
Ребяты (с) Моно прекрасно переносим. Есть только две беды. Первая — моно значительно уступает дотнету в некоторых аспектах. Так он медленее, имеет больше багов, имеет меньше библиотек (например, того же WPF).
Однако это никак не мешает переносимости программ если они изначально создавались в рассчете на запуск под Моно.
Вторая — многим тем кто выбирает технологии МС просто начхать и растереть на все что делается пол Уних в общем, и под Линукс в частности.
Собственно точно так же дела обстоят и с С++. С++ от МС отличается от стандарта С++ и от других его реализаций. И если писать программы только в рассчете на С++, то непереносимая прграмма получается сама сабой в автоматическом режиме.
Собственно и с качеством дела обстаят точно так же. Даже тот же GCC во многом уступает VC или IntelC++. И там где нет этих компиляторов вы точно так же получите боьше проблем и более низкую скорость кода.
Так что это общие проблемы переносимости. Но у С++ этих проблем тем не менее больше. И сам процесс поддержания прогаммы способной одинаково хорошо работать на разных платфомах сложнее. Ведь VM, хорошо спроектированный язык и библиотеки — это оличный слой абстракции. А С++ так бездарно спроектирован и имеет такой зоопарк в ибилиотеках, что всю абстракцию в нем надо выписывать самому. В общем, если вы любите боль, то С++ — это ваш выбор. Безусловно на нем можно создавать хорошие, быстрые и надежные программы. Вопрос только какой ценой и с каким удовольствием от процесса.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Для C/C++, в принципе, можно кроме объектных файлов для каждого исходника еще какой-то прекомпилированный файл строить -- объемы винчестеров и их сейчас это позволяют.
Так все современные компиляторы и поступают. Получаетя для мегабайтных (по побъему исходников) проектов генерируются гигабайты грязи. Жаль только что компиляцию это не сильно ускоряеет... по сравнению с модульными языками.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Извините за переход на личность,
Да ничего страшного.
E>но у вас уже не в первый раз проскальзывает просто таки жуткое неприятие C++.
Есть немного. Только насчёт жуткого — преувеличение.
E>Но, как я понял, проекты в миллионы строк в компании с низкоквалифицированными программистами на C++ вам вести не приходилось. Так откуда же такая нелюбовь ожесточенная? Что же в нем такого отталкивающего?
ИМХО, язык жутковатый. Я уже приводил здесь конструкцию, необходимую для обеспечения модульности (чтобы один и тот же файл не инклюдился два раза). Есть много маленьких мелочей. Например, почему я должен к статическому члену класса обращаться через "::", а не через "."? Зачем дважды дублировать сигнатуру метода в .h и .cpp файлах? Почему чтобы сделать вложенный неймспейс, я не могу использовать точечную нотацию, а должен вкладывать друг в друга несколько блоков? Почему существуют три различных способа приведения типа? Почему метапрограммные навороты выглядят так жутко? Почему нет нормального способа прикрутить человеческий GC, свойства, события и т.д. Наконец, почему, чтобы понять C++, нужно от и до внимательно прочитать Страуструпа, а потом ещё Липпмана?
Впрочем, на все эти вопросы я и сам могу дать ответ. Я так же могу дать ответ на подобные "почему" касательно PHP. Но вот беда: есть языки, к которым подобных вопросов не задаётся.
Здравствуйте, Cyberax, Вы писали:
C>konsoletyper wrote: >> C>Напишешь Quake4 на Питоне? >> Нафига? Вон, Цивилизация 4 на питоне фактически написана, только движок >> на C++. C>Поэтому CivIV всеми и считается жутко тормозящей
Это кем? Вот мой текущий комп практически не апгрейдился с 2003 года, видюха вообще никакая, так играется вполне сносно (только на огромной карте где-то к XX веку начинается жуткий своп, и FPS низкий, на моей видюхе он где угодно низкий). А вот мой батя на новый год купил себе новый комп, причём далеко не самый лучший. Что-то я от него жалоб не слышал.
А вот если бы Civ 4 написали на .NET, то и на моём компе проблем никаких не было бы.
>> А в кваке нет ничего такого, что требовало бы четырёхэтажных >> скриптов. Фактически, почти вся игра состоит из одного движка. Движки >> действительно писать можно только на C++, а жаль . Может быть, в будущем >> что-то изменится. C>А зачем?
Затем, что в будущем игры должны становиться красивее, эффектнее, реалистичнее. Для этого нужен будет мощный движок. Вот тогда мы все и поймём, зачем.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, konsoletyper, Вы писали:
K>>Движки действительно писать можно только на C++, а жаль . АХ>Да ладно тебе, можно и на C, С#, Pascal, Java...
На C#/Java пока не время. Экспериментировал с C# + ManagedDX. Пока слабовато, для серьёзных игр не потянет. А Pascal он же слабее C++.
.
