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

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

Может ты будешь чуть тоньше?

> 0 или 1

Ну ясно, сиплюсплюсныйидеализм.

>Может ты будешь чуть тоньше?

Может до тебя наконец дойдут, что те, у кого в C++ утекает память и сегфолтятся программы, на любом языке напишет быдлокод?

>>Может ты будешь чуть тоньше?

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

Ошибки делают все. В том числе и опечатки, которые также могут приводить к компилируемой программе, но со сложно предсказуемыми сегфолтами. Если ты этого не понимаешь, то либо тролль, либо ничего не писал.

Достаточно посмотреть на любой большой проект на С++ и почитать список багрепортов.

> Достаточно посмотреть на любой большой проект на С++ и почитать список багрепортов.

А ещё лучше -- логи из vcs.

А потом ещё подумать, почему всё больше проектов приходит к использованию valgrind'а. Впрочем, этому троллю такой дзен недоступен.

Проглядел первую и последнюю (33-ю) страницы. Все это жалкое подобие объяснений ВСЛ ака Xenocephal на sql.ru С++?

как посмотреть. вроде, тут с++сники не такие безмозглые студенты, как тамошний его оппонент (там читал только первые 2 страницы). жах, с такими тупилами спорить, видать, на лоровские срачи его больше не хватает.

>как посмотреть. вроде, тут с++сники не такие безмозглые студенты, как тамошний его оппонент (там читал только первые 2 страницы). жах, с такими тупилами спорить, видать, на лоровские срачи его больше не хватает.

В том сраче, чем дальше тем тупее...

да это просто перебранка, а не лор-стайл срач, там ни одного грамотного крестовика не было

>В том числе и опечатки, которые также могут приводить к компилируемой программе, но со сложно предсказуемыми сегфолтами. Если ты этого не понимаешь, то либо тролль, либо ничего не писал.

Я неоднократно писал всякую хрень на C++, которая работает месяцами без сегфолтов, без утечек памяти и при этом выполняет задачи сложнее, чем while(1) sleep(10). И я мог сказать, что в каждой точке приложения происходит, я видел все возможные пути выполнения кода.

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

К счастью, сейчас массово пропагандируется подход, при котором не нужен порядок в голове (например extreme programming), а при написании кода мозг должен задействоваться минимально. В итоге получаем KDE 4 и еще кучу говнософта + кучу леммингов, орущих о "недружелюбности" C++.

>А потом ещё подумать, почему всё больше проектов приходит к использованию valgrind'а.

valgrind -- это слово, означающее в переводе "я ниасилил свой гениальный кодовысер"? Наверное, это второй по популярности инструмент среди быдлокодеров (первый, конечно же, gdb -- "я сам не понимаю, что такое я написал").

И тут Остапа понесло...

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

> valgrind -- это слово, означающее в переводе "я ниасилил свой гениальный кодовысер"? Наверное, это второй по популярности инструмент среди быдлокодеров (первый, конечно же, gdb -- "я сам не понимаю, что такое я написал").

Я в некотором роде разделяю ненависть к отладчикам (gdb расшифровывается как "я не использую тестирование"), но на valgrind гнать не надо, это как раз необходимый инструмент тестирования.

> Достаточно посмотреть на любой большой проект на С++ и почитать список багрепортов.

Я наслышан об одном очень крупном корпоративном приложении, написанном на j2ee. У разработчиков в JIRA несколько тысяч багов. Для их устранения регулярно проводятся bugs hunding days. Перед релизами команды работают неделями в режиме 12x7 для стабилизации имеющейся функциональности. При разворачивании системы у крупного заказчика на _рекомендованном_ разработчиками оборудовании система не стартовала из-за нехватки ресурсов.

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

Так что страшилки про жуткую сегфолтность C++ных программ можно рассказывать только пионерам, которые поработали только juniour-ами на сопровождении старого, написанного индусами C++ кода, и склепали несколько Hello, World-ов на Lisp, OCaml и Haskell-е.

Различие C++ с другими языками состоит в том, что плохой код на C++ не работает, в отличии от аналогичного на Java или C# (поскольку промышленный софт на List/OCaml/Haskell очень тяжело найти в реальной жизни, эти языки не рассматриваются). Поэтому при программировании на C++ нужно думать больше сразу -- чем больше подумаешь, тем меньше потом баги будешь искать. Что характерно, это актуально для любого языка. Но, почему-то, как только человеку дается в руки Java-вкий GC и огромный JDK, изрядная часть его мозга отключается. Человек начинает думать глобально, ему "не нужно" отвлекаться на детали реализации. В результате программы на Java пишутся быстрее, быстрее отдаются в эксплуатацию и быстрее тонут в сотнях-тысячах багрепортов и замечаний заказчиков. А C++ обвиняют в недружелюбности, поскольку C++ный говнокод не работает там, где работает Java-вский говнокод.

> И тут Остапа понесло...

По-моему, он кокаин принимает.

> да это просто перебранка, а не лор-стайл срач, там ни одного грамотного крестовика не было

Там вообще, похоже, ни одного грамотного не было, кроме Луговского.

>Различие C++ с другими языками состоит в том, что плохой код на C++ не работает, в отличии от аналогичного на Java или C#

Это все долбаная демагогия. Известно, что все представители живого, в частности человек, имеют ряд невыгодных мутаций. Однако это не мешает многим жить счастливой жизнью и нянчить внуков, а не загибаться сразу при рождении от того что вероятность к примеру рака немного больше 0.00%. Программы становятся большими и сложными. Поэтому надо обеспечить то чтобы наличие ошибок менее определенного уровня оказывало небольшое влияние на работоспособность. Увеличение выразительности языка с целью минимизации багоопасной рутины, защита памяти как в JVM или какие-то аппаратные средства наподобие виртуальной или теговой памяти это все продуктивные шаги в нужном направлении. Клеймление коллег в быдлокодерстве, штудирование тупых акронимов типа RAII, SFINEA, PIMPL это непродуктивна плюсофилия.

> Я в некотором роде разделяю ненависть к отладчикам (gdb расшифровывается как "я не использую тестирование")

Не, gdb тоже незаменимый инструмент. Когда какая-то Ж уже случилась. Как известно, тестирование может показать, что баги в продукте есть, но не наоборот.

Собственно, классический же путь по отлову падения:

1. смотрим в кору гдбой на минимуме (backtrace, распечатка стека). Понятно? Правим, закончили.

2. Пытаемся вопсроизвести на стенде. Получается? Воспроизводим под valgrind'ом и добавочным логгированием.

3. Не помогло? Опять gdb и watchpont'ы.

4. Не воспроизводится? Возвращаемся к коре, увы.

В 99% процентах случаев дело заканчивается на первом пункте.

Отладчик в процессе разработки -- это да, это какой-то вывих мозга.

> Клеймление коллег в быдлокодерстве, штудирование тупых акронимов типа RAII, SFINEA, PIMPL это непродуктивна плюсофилия.

Я излагаю объективное положение вещей. Хорошие программисты способны сделать на C++ работающий продукт, плохие нет. Вы можете считать это плюсофилией, снобизмом, зашоренностью или еще чем-нибудь. А по мне, это всего лишь один из факторов -- нужна производительность и кроссплатформенность, нужна низкая ресурсоемкость, нужен контроль за всем, нужен доступ к деталям работы ОС, есть хорошая команда? Если да, то можно смело использовать C++. Иначе -- Ruby, Python, Java, C#, Ada, Eiffel... Да даже OCaml с Haskell-ем. Флаг в руки и вперед.

А демонстрировать на форуме собственную плюсофобию, и подкреплять ее примерами говнокода (это я про ad hoc RAII) и утверждениями о том, что исключения не пересекают границ .so -- это гораздо проще, чем трезво оценить реальность.

>подкреплять ее примерами говнокода

Весьма нормальный способ обойти отсутствие finally. Потому что тут должен быть именно finally. Под виндой еще можно SEH заюзать.

> А по мне, это всего лишь один из факторов -- нужна производительность и кроссплатформенность, нужна низкая ресурсоемкость, нужен контроль за всем, нужен доступ к деталям работы ОС, есть хорошая команда? Если да, то можно смело использовать C.

Fixed.

> Если да, то можно смело использовать C.

> Fixed.

На C хорошо драйвера писать. Или ядро Linux-а, когда тысячам разработчиков платить не нужно, сроков нет, и за качество никто не еб*т.

> На C хорошо драйвера писать. Или ядро Linux-а, когда тысячам разработчиков платить не нужно, сроков нет, и за качество никто не еб*т.

БОльшая часть кода, идущая в ядро, написана специально нанятым народом. Даже если чувак шлёт патчи со своего личного адреса, это не значит, что он на какую-нибудь известнуб контору не работает. За качество кода IBM, RedHat, Novell, Oracle и прочие очень сильно волнуются: на этом коде делаются их деньги.

> За качество кода IBM, RedHat, Novell, Oracle и прочие очень сильно волнуются: на этом коде делаются их деньги.

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

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

Как-то идёт в разрез с ранее сказанным: "На C хорошо драйвера писать. Или ядро Linux-а, когда тысячам разработчиков платить не нужно, сроков нет, и за качество никто не еб*т."...

Кстати, какие бабки вбухивают конторы в разработку оупенсорса? Платят з/п нескольким разработчиками, причём, з/п довольно маленькая по сравнению с менеджерьём? Предоставляют машинное время на своём специальном железе? Всё это копейки. В производстве ПО не надо больших денег, достаточно взять в аренду офис, дешёвую в силу своей массовости технику, посадить много дешёвых работников-программистов и немного продавцов, который продукт будут сбывать - вот, собственно, и всё. Строить километровые отапливаемые цеха, брать 10-летний кредит на оборудование (которое после 12 лет работы вырабатывает ресурс), покупать материалы, заморачиваться с соблюдением миллионов норм и инструкций - вот это дорого. Открыть котельный завод даже олигарх может надорваться, а "Инфорога и IT-копыта" любой выпускник ВУЗа осилит.

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

> Как-то идёт в разрез с ранее сказанным: "На C хорошо драйвера писать. Или ядро Linux-а, когда тысячам разработчиков платить не нужно, сроков нет, и за качество никто не еб*т."...

Кроме тех разработчиков ядра, которым платят (а ведь их не мало, счет идет на сотни), есть еще и тысячи программистов, которые ковыряют ядро, присылают патчи и находят баги безвоздмездно. Опять же, есть ли жесткие сроки -- ядро 2.6.34 к такому-то числу? Опять же, какие последствия будут у разработчиков, если ядро 2.6.34 выйдет на две недели после срока и после выхода на нем не будет работать некая софтина, написанная 5 лет назад?

Все это очень сильно отличается от ситуации, когда, например, группе из 5 разработчиков ставится задача: через два месяца у нас запуск интерфеса к платежной системе YYY банка XXX для клиентов VVV, WWW и ZZZ.

> Кстати, какие бабки вбухивают конторы в разработку оупенсорса?

Не IBM ли декларировал инвестиции в 1 миллиард долларов в разработку Linux-а?

> Опять же, есть ли жесткие сроки -- ядро 2.6.34 к такому-то числу? Опять же, какие последствия будут у разработчиков, если ядро 2.6.34 выйдет на две недели после срока и после выхода на нем не будет работать некая софтина, написанная 5 лет назад?

Сроки выхода апстримных версий, а также содержание в них тех или иных фич планируются и учитываются, будь уверен.

> Не IBM ли декларировал инвестиции в 1 миллиард долларов в разработку Linux-а?

Можно подарить сорцы патентованной NUMA, которые оцениваются в половину этой суммы (ради красного слова, точную сумму я не знаю). И что? Можно вообще пакет патентов (идей) передать, которые существуют только на бумажке, но стоят ой-ой-ой. Всем известно, что ситуация с патентами аховая, до невозможности перегретая и просто членовредительская.

Можно нанять штат оглоедов-юристов, которые будут защищать клиентов IBM от нападок патентных линукс-троллей. З/п у юристов и вообще затраты на судопроизводство - ого-го!

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

C++ - это сложный язык с богатыми возможностями, который имеет очень широкое распространение. поэтому я уверен, что знать его просто необходимо. хотя бы потому, что исходники многих программ с интересными заложенными в них идеями выклыдываются именно на С++. простой пример - четыре из пяти самых распространённых фреймворков для написания прог с графическим интерфейсом под Linux написаны именно на С++ - это wxWidgets, Qt, FOX Toolkit, FLTK. я думаю, одно лишь это уже говорит о полезности и применимости языка. а кто хает плюсы - ставим диагноз "НЕ ОСИЛИЛ" и игнорируем.

> C++ - это переусложнённый язык с небогатыми для ЯП высокого уровня возможностями, который имеет по недоразумению аномально широкое распространение.

Fixed.

> Если да, то можно смело использовать C.

Кстати говоря, остряки самоучки могут попробовать переписать на чистом C умоминавшиеся здесь пенисомерки widefinder и raytracer. Чтобы почувствовать разницу.

мордарука.жыпыгы

Ещё страниц 40-50 -- и до тебя наконец дойдёт, что использовать везде C++ -- это примерно того же плана, что писать всё всегда везде на С. Или на ассемблере. Или в машкодах. Или на перле, Или на жабе. Или на лиспе. Или на хаскелле. И так далее.

Причём переписать рейтрейсер на С с плюсовки большой проблемы не составляет, что харАктерно.

> Ещё страниц 40-50 -- и до тебя наконец дойдёт, что использовать везде C++ -- это примерно того же плана, что писать всё всегда везде на С. Или на ассемблере. Или в машкодах. Или на перле, Или на жабе. Или на лиспе. Или на хаскелле. И так далее.

Зато вы никогда не перестанете считать собеседников тупее себя.

> Причём переписать рейтрейсер на С с плюсовки большой проблемы не составляет, что харАктерно.

Попробуйте для начала, потом поймете, большая это будет проблема или нет. Это же вы утверждали, что C следует использовать вместо C++.

> Это же вы утверждали, что C следует использовать вместо C++.

Что ещё я утверждал?

> Что ещё я утверждал?

Может это еще и не ваше утверждение: http://www.linux.org.ru/jump-message.jsp?msgid=4088836&cid=4144346

> кто хает плюсы - ставим диагноз "НЕ ОСИЛИЛ" и игнорируем.

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

Может, Вы ещё и читать научитесь? Там большая часть -- Ваши же утверждения с описанием требований. С такими требованиями лучше использовать C, а не C++, да. Только при чём тут тот самый рейтрейсер, например?

> Там большая часть -- Ваши же утверждения с описанием требований. С такими требованиями лучше использовать C, а не C++, да.

Значит таки "да".

> Только при чём тут тот самый рейтрейсер, например?

Чтобы показать, что ваше "да", как и другие ваши утверждения -- всего лишь форумный 3.14здеж.

> Чтобы показать, что ваше "да", как и другие ваши утверждения -- всего лишь форумный 3.14здеж.

Понять, что рейтрейсер и описанные требования -- это совсем из разных опер, тяжело? Оно и понятно, почему С++ в каждую задачу пихают, с таким-то подходом...

> Понять, что рейтрейсер и описанные требования -- это совсем из разных опер, тяжело?

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

> То, что вы от них отмахиваитесь всего лишь говорит о том, что ни на C, ни на C++ вы не программировали в достаточной мере.

То, что Вы продолжаете талдычить один и тот же бред, не делает его правдой, а так же позволяет усомниться, что Вы имеете какое-либо моральное право на утверждения, подобные процитированному. В одном случае Вы приводите требования, характерные для достаточно низкоуровневого программирования, и тут же требуете подтверждать мысль о пригодных в низкоуровневых вещах инструментах на примере, где без больших рисков для производительности удбнее пользоваться ЯП с высоким уровнем абстракции. Противоречие только мне заметно?

В этом примере, кстати, видна разница в трудоёмкости между С++ и окамлом. Дальше продолжать, или логический вывод в один шаг сделать получится и без подсказки?

> В одном случае Вы приводите требования, характерные для достаточно низкоуровневого программирования

Это нифига не характерные для низкоуровневого программирования требования. Электронная торговля, телекоммуникации, большие расчеты, нагруженные сервера, текстовые процессоры и издательские системы, CAD-инструменты, браузеры и пр. -- вряд ли это все можно назвать низкоуровневым программированием.

> В этом примере, кстати, видна разница в трудоёмкости между С++ и окамлом. Дальше продолжать, или логический вывод в один шаг сделать получится и без подсказки?

Ёптыть. Я где-нибудь пытался оспорить, что трудоемкость решения на OCaml-е в raytracer или widefinder ниже, чем на C++? Почему-то вам выгодно подчеркивать преимущества OCaml-а над C++, а вот таких же преимуществах C++ на C вы не желаете знать.

>> нужна производительность и кроссплатформенность, нужна низкая ресурсоемкость, нужен контроль за всем, нужен доступ к деталям работы ОС

> Электронная торговля, телекоммуникации, большие расчеты, нагруженные сервера, текстовые процессоры и издательские системы, CAD-инструменты, браузеры и пр.

Не стыкуется для большей части второго списка.

> Почему-то вам выгодно подчеркивать преимущества OCaml-а над C++, а вот таких же преимуществах C++ на C вы не желаете знать.

Не так. У С++ нет никаких преимуществ над С. То, что Вы называете его преимуществами, это попытка сделать язык другого уровня, они в другой плоскости лежат. Чтобы было проще: у окамла нет преимуществ над С, это языки разного уровня. Я не говорю, что для всех задач надо брать С, он там не применим.

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

Вы отказываетесь понимать один отшень простой вестчь: если задача низкого уровня, то её логичнее делать с использованием инструментов низкого уровня, и тут С выглядит предпочтительнее С++ за счёт большей простоты, предсказуемости и управляемости; если задача высокого уровня, то логичнее её делать с использованием инструментов высокого уровня, и опять-таки С++ выглядит не слишком привлекательно, заставляя программиста заботиться о таких вещах, которые нафиг не интересны в высокоуровневой разработке.

Остаются проекты на грани, но тут опять получается, что связка C + ЯП высокого уровня выглядит приятнее. Критичные вещи делаются на С, оставляя всё остальное свободным от проблем низкоуровневости.

>>> нужна производительность и кроссплатформенность, нужна низкая ресурсоемкость, нужен контроль за всем, нужен доступ к деталям работы ОС

>> Электронная торговля, телекоммуникации, большие расчеты, нагруженные сервера, текстовые процессоры и издательские системы, CAD-инструменты, браузеры и пр.

> Не стыкуется для большей части второго списка.

Можете обосновать?

По поводу задач на стыке. Об этом писал сам Страуструп в "Дизайне и эволюции языка C++". И пока таких задач вполне достаточно, как бы любителям программировать на связке из OCaml(Haskell)+C не хотелось. Более того, высокоуровневые механизмы C++ позволяют безопасно решать очень специфические низкоуровневые задачи, к примеру: http://www.research.att.com/~bs/abstraction-and-machine.pdf

> Можете обосновать?

Берём элемент из второго списка и смотрим, требуется ли там каждый элемент из второго. Просто и незамысловато. Из всего списка остаются только высоконагруженные сервера. Место ли там С++ -- тоже хороший вопрос, от задачи сильно зависит.

> По поводу задач на стыке. Об этом писал сам Страуструп в "Дизайне и эволюции языка C++".

Можно конкретную цитату или какую-нибудь другую конкретику? Без этого следующая фраза не воспринимается вообще.

> Более того, высокоуровневые механизмы C++ позволяют безопасно решать очень специфические низкоуровневые задачи, к примеру: http://www.research.att.com/~bs/abstraction-and-machine.pdf

Попозже посмотрю, на что обратить внимание?

>> Можете обосновать?

> Берём элемент из второго списка и смотрим, требуется ли там каждый элемент из второго. Просто и незамысловато.

Опять 3.14здеж. Никаких объективных причин выбрасывания чего-нибудь из списка не приведено. Например, браузерам нужна и кроссплатформенность, и скорость, и малая ресурсоемкость, и доступ к возможностям ОС.

> Попозже посмотрю, на что обратить внимание?

На реализацию вычислений на шаблонах C++ во встроенном ПО.

> Опять 3.14здеж.

3.14здёшь тут только от плюсофилов. Желаешь пойти по пути linuxfan'а -- вперёд.

> Например, браузерам нужна и кроссплатформенность, и скорость, и малая ресурсоемкость, и доступ к возможностям ОС.

Во-первых, не перевирай свои же слова. Во-вторых, начнём с малого -- зачем браузеру "доступ к *деталям* работы ОС"?

Жду ответа ещё и про "дизайн и эволюцию".

> > Опять 3.14здеж.

> 3.14здёшь тут только от плюсофилов.

Ну хоть правде в глаза не стесняйтесь посмотреть.

> Желаешь пойти по пути linuxfan'а -- вперёд.

Очередное жлобство и снобизм от плюсофобов -- мы белые и пушистые, пургу не гоним, говорим только о том, в чем разбираемся...

> Во-вторых, начнём с малого -- зачем браузеру "доступ к *деталям* работы ОС"?

Например, для интеграции с системой безопасности для хранения сертификатов. Для плотного использования IPC в случае, если закладки реализуются отдельными дочерними процессами. Для интеграции средств просмотра различных видов документов в браузер (скажем, PDF-ок в виде COM-объекта от Adobe Reader-а под офтопиком).

> Жду ответа ещё и про "дизайн и эволюцию".

Книги под рукой нет. Но в ней была глава, в которой Страуструп рассказывал, в каких областях C++ является нормальным выбором.

> Ну хоть правде в глаза не стесняйтесь посмотреть.

> Очередное жлобство и снобизм от плюсофобов -- мы белые и пушистые, пургу не гоним, говорим только о том, в чем разбираемся...

Поменяй монитор на матовый, полегчает.

> Например, для интеграции с системой безопасности для хранения сертификатов. Для плотного использования IPC в случае, если закладки реализуются отдельными дочерними процессами. Для интеграции средств просмотра различных видов документов в браузер (скажем, PDF-ок в виде COM-объекта от Adobe Reader-а под офтопиком).

Что из этого является *деталями* *работы* *ОС*, а не сопутствующих (*иногда* системных, чаще нет) сервисов, и не деталями, а API? И даже в таком варианте -- где тут насущная необходимость в С++?

> Книги под рукой нет. Но в ней была глава, в которой Страуструп рассказывал, в каких областях C++ является нормальным выбором.

Ну найди, что ли, аргумент с твоей стороны, как-никак... Перечитывать всю книгу у меня сейчас желания маловато, а сходу вспомнить там что-то такое, что убедительно объясняло бы пригодность в большинстве задач "на грани" плюсовки и непригодность в них же гетерогенных решений типа окамл+С.

>В этом примере, кстати, видна разница в трудоёмкости между С++ и окамлом.

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