VladD2 wrote: > Мне кажется, он имел в виду, что на С++ очень *сложно* писать > переносимый код. Сложно потому, что стандарт реально почти никем не > реализован. Сложно потому, что сложно качесвтенно портировать > компиляторы. Сложно потому что много UB. Сложно потому, что язык в угоду > оптимизации создает массу сложностей вроде платформно-зависимых типов...
Да ну, не серьезно. Если хочется портируемости — пишем под GCC, который
есть даже для тостеров и чайников. Этого достаточно для всех
практических целей.
Обычный "С с классами" и умеренным использованием шаблонов тоже вполне
нормально переносится.
Здравствуйте, Cyberax, Вы писали:
C>Да ну, не серьезно. Если хочется портируемости — пишем под GCC, который C>есть даже для тостеров и чайников. Этого достаточно для всех C>практических целей.
А ты прочти рядом интервью Тененбаума. Он как раз говорит "пишите на С без расширений... стандарты... стандарты...".
C>Обычный "С с классами" и умеренным использованием шаблонов тоже вполне C>нормально переносится.
Намного сложенее чем просто С.
C>Главные проблемы, как обычно, с библиотеками.
Если перенесен компилятор С, то все библиотеки тоже перенесены. Их у него довольно мало.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>Да ну, не серьезно. Если хочется портируемости — пишем под GCC, который > C>есть даже для тостеров и чайников. Этого достаточно для всех > C>практических целей. > А ты прочти рядом интервью Тененбаума. Он как раз говорит "пишите на С > без расширений... стандарты... стандарты...".
Так зачем расширения использовать? Просто при использовании GCC будет
примерно одинаковый набор багов компилятора на всех системах.
> C>Обычный "С с классами" и умеренным использованием шаблонов тоже вполне > C>нормально переносится. > Намного сложенее чем просто С.
Уже вполне нормально — все вполне работает, если не учитывать совсем уж
убитые компиляторы. У меня есть опыт по переносу нескольких программ на
С++ между системами — проблем с САМИМ языком не было почти никаких.
> C>Главные проблемы, как обычно, с библиотеками. > Если перенесен компилятор С, то все библиотеки тоже перенесены. Их у > него довольно мало.
Вот в этом и проблема — для реального приложения нужны внешние
библиотеки, а вот они как раз часто вообще не переносятся. С .NET
ситуация, кстати, точно такая же.
На самом деле, Страуструп просто исказил идею.
Еще дедушка Брукс писал, что сложность бывает "естественная" и "добавочная". Естественная сложность — это та, которая присуща предметной области, понятиями которой оперирует специалист в этой самой предметной области. Добавочная стоимость — это та, которая связана с внутренней организацией компилятора языка и оси (опосредствованно, через библиотеки).
Вполне очевидно, что сложность конструкций языка должна быть адекватна естественной сложности решаемых задач.
И так же вполне нетрудно сообразить, что присущие С++ сложности ковыряния стека через va_arg или возни с попытками убрать детали реализации из h-файлов не имеют к сложности предметной области ни малейшего отношения.
AndreiF wrote: > Вполне очевидно, что сложность конструкций языка должна быть адекватна > естественной сложности решаемых задач.
А еще бывает ПРАКТИЧЕСКАЯ сложность.
Сложность С++ не в сложности самого языка, а в количестве базовых
понятий. В той же Java есть только константы, объекты и примитивы, а в
С++ есть: константа, указатель, массив, ссылка, автоматический объект
(встроенные и свои типы), умный указатель.
Поэтому С++ предоставляет такие фичи, которых просто НЕТ в
Nemerle/Java/C#. Соответственно, он может решать задачи, которые на
практике на Nemerle/Java/C# не решаются.
Спор о необходимости этих фич — это уже отдельный флейм.
Здравствуйте, konsoletyper, Вы писали:
K>Кстати, алгоритм получения канонической LR-системы вообще занимает менее 300 строк. Это далеко не самая сложная штука. Нужно распарсить и проанализировать входной файл (а это не так просто в моём случае). Нужно сгенерировать код. Можно ещё поэкспериментировать с нормальным error reporting в алгоритме LR, компиляцией магазинного автомата, автоматизированным построением AST и т.д. Собственно, есть уже формализованные алгоритмы построения КК и здесь главную роль играет не язык, а математика.
Собственно об этом и речь, что к "алгоритмической сложности" C++ не имеет отношения.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
E>>Главным образом я хочу получить ответ на свой вопрос: E>>
E>>Вот тут не очень понял. Ты имеешь ввиду, что сложные кроссплатформенные системы нельзя писать на C++? Или что тем, кто не пишет сложных кроссплатформенных систем, C++ с его фичами не нужен?
E>>поскольку твою фразу о разработке сложных кроссплатформенных систем я не понял
VD>Мне кажется, он имел в виду, что на С++ очень сложно писать переносимый код.
Я бы хотел услышать ответ из первоисточника.
Поскольку твое мнение, по крайней мере на моем опыте, не имеет ничего общего с действительностью.
VD>Сложно потому, что стандарт реально почти никем не реализован.
Весь стандарт в подавляющем большинстве случаев и не нужен.
Не всегда даже нужна поддержка специализаций шаблонов, не говоря уже о частичной специализации.
VD>Сложно потому, что сложно качесвтенно портировать компиляторы.
Сколько некачественных C++ компиляторов, когда и на каких платформах тебе доводилось видеть или использовать. И сколько в это же время и на этих же платформах было компиляторов с отличных от C/C++ языков?
VD>Сложно потому что много UB.
Это к портируемости вообще имеет косвенное отношение.
VD>Сложно потому, что язык в угоду оптимизации создает массу сложностей вроде платформно-зависимых типов...
Платформенно-зависимые типы не являются проблемой даже если требуется организовывать обмен данными между различными платформами.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
AndreiF wrote: > C>Соответственно, он может решать задачи, которые на > C>практике на Nemerle/Java/C# не решаются. > Он предоставляет возможность делать низкоуровневые оптимизации, которые > нельзя сделать в Nemerle/Java/C#. Но оптимизации — это не задачи.
Это НЕ оптимизации. Это примитивы, которых нет в C#/... Они могут, в том
числе, быть использованы и для оптимизации.
Кстати, оптимизация — сама по себе тоже вполне задача, которая переводит
практические задачи из категории "невозможные" в "возможные".
Здравствуйте, Cyberax, Вы писали:
C>Это НЕ оптимизации. Это примитивы, которых нет в C#/... Они могут, в том C>числе, быть использованы и для оптимизации.
А помимо этого? Приведи реальный пример, плиз. Что (кроме оптимизаций) можно сделать на С++, чего нельзя сделать на C#?
C>Напишешь Quake4 на Питоне?
На самом деле, большая (по объему) часть современных игр пишется как раз на скриптах, в том числе и Питоне. Эта часть как правило больше, чем часть кода написанного на С++. Так что вопрос можно поставить и обратный — а ты напишешь Quake 4 на чистом С++?
Здравствуйте, VladD2, Вы писали:
R>>Какие интересно задачи не позволяет решать С++? Имхо, если С++ сегодня не позволяет, то ни один язык сегодня не позволяет её решить. VD>Ой, всего лишь одну. Писать надежный и хорошо читаемый код.
Все зависит от квалификации человека. Плохой и нечитабельный код можно написать практически на любом более менее серьезном ЯП
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Gajdalager, Вы писали:
G>В теории .Нет кроссплатформенный, а моноплатформенность .Нета происходит не от каких-либо просчетов в архитектуре или спецификации, а из-за политики МС.
Ну, то что в теории можно выбросить сразу — интересует только практика. Какой смысл от того что он в теории кроссплатформенный когда на практике это использовать нельзя? Когда в этом плане что либо изменится — тогда можно говорить о кроссплатформенности. А покуда — .NET НЕ кроссплатформенный.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, AndreiF, Вы писали:
C>>Напишешь Quake4 на Питоне? AF>На самом деле, большая (по объему) часть современных игр пишется как раз на скриптах
AF>Эта часть как правило больше, чем часть кода написанного на С++.
AF> Так что вопрос можно поставить и обратный — а ты напишешь Quake 4 на чистом С++?
Да.
В том же Q4 скрипты предназначены только для того, чтобы можно было быстро и просто менять игровую логику не пересобирая движок.
Ничто в общем то не мешает весь этот код запихать в DLL как это было во времена того же HL.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
AF>> Так что вопрос можно поставить и обратный — а ты напишешь Quake 4 на чистом С++? CC>Да. CC>В том же Q4 скрипты предназначены только для того, чтобы можно было быстро и просто менять игровую логику не пересобирая движок. CC>Ничто в общем то не мешает весь этот код запихать в DLL как это было во времена того же HL.
Смелый парень. И много квейков 4, или хотя бы ХЛов ты за свою жизнь написал?
AndreiF wrote: > C>Это НЕ оптимизации. Это примитивы, которых нет в C#/... Они могут, в том > C>числе, быть использованы и для оптимизации. > А помимо этого? Приведи реальный пример, плиз. Что (кроме оптимизаций) > можно сделать на С++, чего нельзя сделать на C#?
Написать Q4. В теории это возможно хоть на Brainf**k, но на
практике только С++.
> C>Напишешь Quake4 на Питоне? > На самом деле, большая (по объему) часть современных игр пишется как раз > на скриптах, в том числе и Питоне. Эта часть как правило больше, чем > часть кода написанного на С++. Так что вопрос можно поставить и обратный > — а ты напишешь Quake 4 на *чистом* С++?
А почему нет? Вот Q3 на С написан, а скрипты там — это просто входные
данные.
А ты напишешь ВЕСЬ Q4 на Питоне? Ведь оптимизация — это не задача.
Здравствуйте, konsoletyper, Вы писали:
FR>>Интересно как вывод типов в продукте может зависеть от языка реализации этого продукта? По твоему трансляторы пролога тоже невозможно на C/C++ написать?
K>Возмножно, но весьма сложно. В принципе, можно браться за любой сложности задачу, однако, когда сложность превышает все возможные пределы, можно сказать, что решить задачу невозможно (на самом деле, экономически невыгодно).
В чем сложность то? Мне кажется ты сильно преувеличиваешь то упрощение которое дают для данного класса задач ML подобные языки. Если бы ты был прав, то компиляторя уже очень давно писались бы только на чем то ML подобном например на Ocaml.
K>>>А вот компилятор C++ на Немерле написать — проще некуда. Только всё равно на 100% поддержку C++ сделать нельзя, как говорится, by design.
FR>>выделеннное
K>Такая же гипербола, как и выделенное ниже:
Нету там внизу никакой гиперболы.
L_L>>>>Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
K>А вообще, рад, что развеселил. Смех продляет жизнь. Приятно сделать доброе дело
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, Cyberax, Вы писали:
C>>Написать Q4. В теории это возможно хоть на Brainf**k, но на C>>практике только С++.
AF>шейдеры тоже на С++ написаны?
Обычно на специализированном си подобном языке.
Кстати в подобных Q4 шутерах скрипты обычно очень мало используются.
Здравствуйте, eao197, Вы писали:
E>Идеи есть какие-нибудь? E>А то у меня они слишком радикальные -- использовать Scala и D вместо C++.
Идеи давно есть, проблема в претворении их на практике.
Ну, кстати, пресловутый экспорт шаблонов будучи должным образом реализованный мог бы помочь делу.
