[C++?] Серьезный вопрос.

> Как это говорят: talks don't cook rice...

У нас есть один американец, который больше всех языком чешет, заткнуть прям-таки невозможно, вот у него такая же ~/.signature в мейлах...

Софт на крестах когда массово стал появляться?

> Да, на форумах его становиться все больше и больше.

Это плохо? О существовании Хаскелла я узнал именно на ЛОРе. :)

> > Адекватной современной замены для C++ сейчас нет - на этом я буду настаивать.

> Ну так вам говорят про Лисп, Хаскель и Окамл,

Так говорят уже лет десять. А про Лисп так со времен появления C++. И все без толку. Никто из них не является адекватной заменой C++, ни раньше, ни сейчас. А у OCaml-а и в будущем перспектив не будет, после появления F#.

> а вы в ответ: жаба -- говно.

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

>Тред не читал, о чем тред?

все серьёзно спрашивают что-то у C++; уже > 1700 раз спросили, а ответа всё нет

> Софт на крестах когда массово стал появляться?

С конца 80-х.

>у OCaml-а и в будущем перспектив не будет, после появления F#

F# это не совсем OCaml. вернее, это совсем не OCaml

>>у OCaml-а и в будущем перспектив не будет, после появления F#

>F# это не совсем OCaml. вернее, это совсем не OCaml

AFAIK, в команду F# ушло несколько разработчиков OCaml-а. Что вряд ли добавило бодрости OCaml-у.

> С конца 80-х.

К концу 80-х лиспового софта уже два железнодорожных состава написано было. Когда стандарт ANSI на язык разрабатывали, чуть ли не до драк доходило, из какого лиспа подход к реализации той или иной фичи брать.

Аргумент "я этот софт не видел" - нелеп. У меня в системе тоже софт на крестах почти отсутствует.

>AFAIK, в команду F# ушло несколько разработчиков OCaml-а

вот это может быть, да

> К концу 80-х лиспового софта уже два железнодорожных состава написано было. Когда стандарт ANSI на язык разрабатывали, чуть ли не до драк доходило, из какого лиспа подход к реализации той или иной фичи брать.

К концу 80-х сколько Lisp-у годков исполнилось? Под 30-ть где-то.

> Аргумент "я этот софт не видел" - нелеп. У меня в системе тоже софт на крестах почти отсутствует.

А что за система? Браузер?

> Если вы внимательно посмотрите, то увидите, что Java была упомянута в ответ на претензии о количестве багов в C++ из-за ручного управления памятью. А Java ручного управления памятью нет, а багов в Java проектах -- выше крыши. Так что тезис о сложности ручного управления памятью не срабатывает.

Ты хочешь сказать, что багов, *связанных с управлением памятью* в жабских проектах не меньше, чем в плюсовых? То, что они есть, я знаю.

> Ты хочешь сказать, что багов, *связанных с управлением памятью* в жабских проектах не меньше, чем в плюсовых? То, что они есть, я знаю.

Нет, я хочу сказать, что общее количество багов в C++ных и Java проектах не сильно отличаются (из того, что я видел). При этом в C++ ручное управление памятью, в Java автоматическое. Т.е. отсутствие ручного управления памятью не повышает автоматически качество программы.

>Но ты это к чему? Неужели ты решил, что mv под языком, уровнем выше C++, подразумевал похапе?

Я первым брошу камень в того, кто скажет, что похапе более низкоуровневый язык, чем C++.

> А что за система? Браузер?

Fedora rawhide

>Йа, йа, натюрлих!

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

>Ну вот, скоро начнёт появляться софт :)

Меня не покидает уверенность, что функциональные языки форумного троллинга не пойдут дальше форумов.

>Аргумент "я этот софт не видел" - нелеп. У меня в системе тоже софт на крестах почти отсутствует.

Пословица "мал золотник, да дорог" о чем-нибудь говорит?

rm -fr /usr/lib/libstdc++* и придется тебя из lynx/links/dillo троллить.

s/тебя/тебе/

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

Учитывая, что движок-рендер разрабатывают единицы контор, а остальные просто его используют... Да и то, основная нагрузка на отрисовку давно ложится на железо.

По поводку физических движков, так это вообще не программистская стезя. Не напишет человек без многолетней подготовки нормальный физический движок. Скорее, инженер программирование освоит.

> Пословица "мал золотник, да дорог" о чем-нибудь говорит?

Конечно, у меня же Емакс!

> rm -fr /usr/lib/libstdc++* и придется тебя из lynx/links/dillo троллить.

Я из емакса (+ w3m) могу троллить.

> Нет, я хочу сказать, что общее количество багов в C++ных и Java проектах не сильно отличаются (из того, что я видел). При этом в C++ ручное управление памятью, в Java автоматическое. Т.е. отсутствие ручного управления памятью не повышает автоматически качество программы.

С++ vs Java -- отдельная тема.

Но логичность выводов просто восхищает: В программах на жабе много багов. В жабе есть GC. Следовательно, GC -- херня.

Каких багов? Где? Их спровоцировал GC? Если бы те же люди использовали С++, они бы написали более качественный код?

> Но логичность выводов просто восхищает: В программах на жабе много багов. В жабе есть GC. Следовательно, GC -- херня.

Ёптыть, на себя посмотрите, как вы такой вывод сделали?

Есть GC -- много багов.

Нет GC -- много багов.

По-моему, наличие или отсутствие GC не влияет на качество программ настолько серьезно, чтобы ставить его отсутствие в вину C++.

>По-моему, наличие или отсутствие GC не влияет на качество программ настолько серьезно, чтобы ставить его отсутствие в вину C++.

Плбсофильские софизмы навроде "Наполовину полное это тоже самое что и наполовину пустое, значит полное есть пустое."

> Тебе шашечки или ехать?

Мне, вообще-то, лететь.

Мелкие синтаксические преимущества окамла, конечно, интересны, но не играют решающей роли (ибо легко достигаются в собственном not-type-aware трансляторе с выхлопом в с++).

Действительную ценность имеют новые абстрации. Но мне не известны хорошие книжки, объясняющие именно это (а то, что я пытался читать, ужасно скучно). Для ады тут пробегала хорошая ссылка на 13 пдф-ок Safe and Secure Ada. Их было интересно читать. Еще есть Rationale для стандарта ады, тоже вроде интересно.

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

Кстати, абстракции, в ложном понимании некоторых, противополжны низкому уровню. Так вот, с++ интересен тем, что в нем абстракции помогают выжимать такты (а не только и не столько сокращать время на написание программы или на обучение программера).

>> чем рестарт лучше передачи в g анонимной функции, определенной во фрейме стека f (что вполне реально в с++0х или boost::lamdba)?

> Так и дженерики легко руками при помощи boost::function делаются! Ваще кресты отличный выразительный язык, пиши, да пиши.

Что за ... ? Вполне возможно, что разница есть, например при вложенных рестартах и х.з. в комбинации с чем. Так что разберись.

> Меня не покидает уверенность, что функциональные языки форумного троллинга не пойдут дальше форумов.

Хаскель полезно знать (и то не факт что всем), но писать на нем даже что-то stateless (например, транслятор) я бы наверно не стал.

а может быть и стал...

может для прототипа транслятора он и сгодится

>Каких багов?

Пройди курс принудительного лечения от дислексии. Тебе же написали: жрут дохера памяти, хоть и GC.

>Если бы те же люди использовали С++

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

>Хаскель полезно знать

Зачем? Может быть лучше знать, к примеру, диаметр колес марсохода или подобную никому не нужную хрень?

Так вот, с++ интересен тем, что в нем абстракции помогают выжимать такты (а не только и не столько сокращать время на написание программы или на обучение программера).

По поводу fps-a шутера написал и проверил вот такой код. В откомпилированной matrix-mul нет ни одного библиотечного вызова или цикла - только простыня из fmul и fadd. Интересно что таким же макаром можно в compile-time смастерить любую параметрическую матрицу пространственного преобразования.

(defmacro genmul(m1 m2 result dim)
  `(progn
     ,@(labels ((cij (i j)
		     `(+
		       ,@(let ((muls nil))
			      (loop for q from (- dim 1) downto 0
				 do (push `(* (aref ,m1 ,i ,q) (aref ,m2 ,q ,j)) muls))
			      muls)))
		(els0 (i j)
		      `(setf (aref ,result ,i ,j) ,(cij i j)))
		(els ()
		     (let ((exprs nil))
		       (loop for c from (- (* dim dim) 1) downto 0 
			  do (push (els0 (rem c dim) (truncate (/ c dim))) exprs))
		       exprs)))
	       (els))))

(defun matrix-mul(m1 m2)
  (declare (type (array double-float (4 4)) m1 m2)
	   (optimize (speed 3) (safety 0)))
  (let ((result (make-array '(4 4) :element-type 'double-float)))
    (genmul m1 m2 result 4)
    result))

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

Плюсофилов в реальный прокт на С++ пускать нельзя. Лучше отправить их на жабу для прочистки мозгов. В нормальном проекте на С++ должны учавствовать только те кто имел с этим языком большой опыт и от всего сердца ненавидит это говно. Если нельзя их с самого начала отправить на жабу, то можно заставить делать RAII и SFINEA абстракции, а потом отклонять их код под предлогом "принять код нельзя, больше 10 строчек - это новый релиз, а новый релиз не запланирован"

Афигеть! Математика в обратной польской записи стала очевиднее C++ного кода!

Еще более простым макаром можно смастерить генерацию различных матриц через Ruby/Python скрипты перед компиляцией.

> >Каких багов?

> Пройди курс принудительного лечения от дислексии. Тебе же написали: жрут дохера памяти, хоть и GC.

Кстати не только и не столько. Просто баги, вызванные повисшими и битыми указателями в C/C++, в Java сменяются таким же количеством багов с null-ссылками, не возвращенными ресурсами, выброшенными из finally исключений и пр.

>Еще более простым макаром можно смастерить генерацию различных матриц через Ruby/Python скрипты перед компиляцией.

Альтернатива на С++ это наверное expression templates над матрицами. И не факт что оно будет лучше читаться.

Сегодня в одной книге прочитал хороший пример(хотя книга и не по нашей с вами теме). Попытаюсь коротко пересказать.

Еще 1000 лет назад люди с трудом могли умножать или складывать произвольные целые числа. Это была нетривиальная задача. Несмотря на то, что тогда уже были представления о простых числах, найбольшем общем делителе итд... Проблема была в том, что не было удобного представления чисел в арабской форме.

Представьте себе, что Мухамед ал-Хорезми пришел в Самарканд(положим, что там римская система) и показал десятичную систему исчисления. Врядли его будут носить на руках. Скорее он встретит сильную критику в свой адрес.

1) Наглядность. 247 нагляднее, чем CCXLVII. Ведь сразу видно, что речь идет о C+C+(L-X)+V+I+I, а что-бы найти, то же значит 247 надо вычислить 2*10^2 + 4*10^1 + 7*10^0. Так что теперь вместо того, что-бы умножать только тогда, когда надо мы это будем делать каждый раз, когда нужно лишь узнать о каком числе идет речь.

2) Ненагляден способ сложения. Ведь намного яснее, что V + II = VII чем 5 + 2 = 7.

3) Нужно 10 символов вместо 7(I V X L C D M). Конечно нельзя выражать числа больше MMMCMXCIX, но для практических задач этого достаточно, а числа больше - это уже витание в облаках, наука для науки.

4) нужно помнить 100 правил(таблицу умножения).

Мухаменд мог бы возразить, задав вопрос, а сколько же дукатов следует заплатить за CCLXXIV овец, если каждая из них стоит XLIX дукатов. В ответ бы услышал что-то в духе:

Кто же продаёт CCXLXXIV овец? На практике это либо CC, либо CCC, в худшем случае уж CCL овец. А что за идиотская цена в XLIX дукатов? На практике это всегда L дукатов. А уж на практике умножить CC и L мы и без всех этих заумных теорий можем. 5) Мы ведь не можем переучить всех торговцев в Самарканде и заставить их писать числа по новому лишь для того, что-бы тебе было удобно складывать и умножать.

---------------

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

Так вот. Тут прямая аналогия со спором C++ vs. (OCaml, Haskell, Lisp...). Надеюсь очевидно, кто тут есть кто?

>В откомпилированной matrix-mul нет ни одного библиотечного вызова или цикла - только простыня из fmul и fadd.

Детский сад, штаны на лямках. Где SSE? Где параллельное выполнение N операций за раз? Уж лучше транслировать в C, затем натравливать icc на результат и автоматически генерировать FFI биндинги. Но чутье подсказывает мне, что в этом месте начнутся ненужные переливания из пустого в порожнее (читай: динамическое выделение памяти и копирование данных).

>Альтернатива на С++ это наверное expression templates над матрицами. И не факт что оно будет лучше читаться.

Тому, кто будет пользоваться очень даже понравится: (M1 * M2 + M3) * C. Проблема в том, что неокрепший ум из-за одной опечатки увидит такой ужас, что может отвергнуть темплейты и попытаться искать убежища в круглых скобках.

>Тому, кто будет пользоваться очень даже понравится: (M1 * M2 + M3) * C

Я писал что хочу получить параметрический оператор, а не просто перемножить матрицы.

BTW, на x86_64 он таки использует SSE

>Я писал что хочу получить параметрический оператор, а не просто перемножить матрицы.

Единственный параметр, который я тут усмотрел -- размерность матриц. Нахрена он нужен при работающем array-dimension я не осилил понять.

Кстати, я уже заметил, что всем функциональщикам надо не что-то полезное сделать, а насладиться каким-то неведомым процессом.

>>Я писал что хочу получить параметрический оператор, а не просто перемножить матрицы.

>Единственный параметр, который я тут усмотрел -- размерность матриц. Нахрена он нужен при работающем array-dimension я не осилил понять.

Параметрический оператор делается так же. Пишется макрос который строит из списка пространственных преобразований большой (progn), захватывая переменные из контекста.

>Кстати, я уже заметил, что всем функциональщикам надо не что-то полезное сделать, а насладиться каким-то неведомым процессом.

Тут чисто императивный двойной loop в макросе который порождает чисто императивный (progn (setf...) ...). Где ты тут функциональщиков нашел я не понимаю.

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

> Так вот. Тут прямая аналогия со спором C++ vs. (OCaml, Haskell, Lisp...). Надеюсь очевидно, кто тут есть кто?

Не катит ваша аналогия. Вы бы поинтересовались, насколько продвинулось производство ПО, когда на смену ассемблеру пришел C, а на смену Simula -- С++.

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

Вклад OCaml-а с Haskell-ем в производство ПО еще предстоит оценить. Хотя, если вспомнить лозунг отца Haskell "Avoid success at any cost", то этот вклад будет невелик. В развитие языков программирования -- может быть очень большой вклад, в производство ПО -- ?

> Альтернатива на С++ это наверное expression templates над матрицами. И не факт что оно будет лучше читаться.

Существование expression templates вовсе не означает, что они обязательно должны использоваться. Кодогенерация часто оказывается более простым и выигрышным вариантом.

>Не катит ваша аналогия. Вы бы поинтересовались, насколько продвинулось производство ПО, когда на смену ассемблеру пришел C, а на смену Simula -- С++.

В том то и дело, что прекрасная аналогия. С каким скрипом инудстрия меняется. Языки высокого уровня появились давно. В то время, как еще в начале 80-ых были умники, которые писали софт на ассемблере.

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

> Языки высокого уровня появились давно. В то время, как еще в начале 80-ых были умники, которые писали софт на ассемблере.

Ануткать примеры умников, которые в начале 80-х писали на ассемблере? А то ведь может оказаться, что их число, как и сейчас, было исчезающе малым. Cкажем, они писали VisiCalc для Apple II с парой десятков килобайт памяти. Не от хорошей жизни они это делали, а из-за слишком больших накладных расходов тогдашних языков высокого уровня.

> Как раз о том, что на смену ассемблера должен был прийти С я и говорю. Теперь вы не понимаете выразительности языков таких как хаскель и лисп защищая нелепицу под названием с++. Точно так-же, как противились арабским цифрам.

А вы понимате, что вы пытаетесь с академическими поделками в индустрию влезть? Индустрии, как показывает практика, нужны Java и IDEA под Unix-ом и C# с VS под виндой. Поскольку нефиг микроскопами гвозди забивать.

Когда выразительность языков будет сочетаться с применимостью в индустрии, то от наследия в виде C++ и Java избавятся, не сомневайтесь. С COBOL-ом и PL/1 это произошло (хотя они и продолжают жить свой жизнью), произойдет и с C++. Но вряд ли благодоря OCaml-у с Haskell-ем.

Так что не катит ваша аналогия, нет еще арабских цифр.

>> Хаскель полезно знать

> Зачем? Может быть лучше знать, к примеру, диаметр колес марсохода или подобную никому не нужную хрень?

Из-за

1. хорошей системы типов (аналог которой едва не включили в с++0х)

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

3. там кое-что сделано в кажущемся-правильном-направлении, и полезно знать подводные камни, с которыми они сталкиваются.

и обязательно надо было сохранить в цитате "и то не факт что всем"

> Теперь вы не понимаете выразительности языков таких как хаскель и лисп защищая нелепицу под названием с++.

Это у хаскеля-то выразительность? При отсутствии способа выразить плюсовое template<int n>?

>писать на нем даже что-то stateless (например, транслятор) я бы наверно не стал

ну и ладненько

>Хотя, если вспомнить лозунг отца Haskell "Avoid success at any cost"

в силу объективных причин лозунг уже был признан неактуальным