Обзор наступающего С++0х стандарта

>> _Эта_ популярность равна здравому смыслу.

> ЛОЛШТО?

Я думаю, ты меня понял. Если нет - это твои проблемы.

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

Один из главных законов программирования - Преждевременная оптимизация - Зло. Сюрприз, ага?

> подозреваю что там туева хуча работы с графами и сложными структурами данных. Подозреваю что выбрал бы для этой области Common Lisp и не прогдал бы.

Не *ML? Не Хаскель? 8)

> Ты забыл добавить, сколько человек потребуется на поддержку такой системы с зоопарком языков (раз уж ты сам затронул эту тему).

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

> Чушь Костыль

>> Чушь

>Костыль

Тема костыля не раскрыта! Костыль, помогающий от каких проблем? :D

>я закачал за пару часов 16% из 684M По bittorent я за такое же время скачал всё, да и то скорость явно упиралась в мой канал

> Один из главных законов программирования - Преждевременная оптимизация - Зло. Сюрприз, ага?

А потом будет позно пить боржоми.

Хорошая новость.

Вниманию особо продвинутых анонимусов, сейчас я в Windows (ну нету у меня на работе Линуха), просто пройдусь по каталогу Program Files в поисках характерных следов С++ в исполняемых файлах:

7Zip
Acrobat Reader 8.1
Adobe Photoshop CS2
Cisco VPN Client 4.3
Diskeeper 9.0 (дефрагментатор популярный такой под венду)
eMule 1.2 (клиент P2P сети eDonkey)
EPSON PhotoQuicker 3.5
FAR 1.7
Folding@Home (типа распределенный проект биологических вычислений)
Google Earth
Intel Matrix Storage Manager
Apple iTunes 7.3
Sun JDK/JRE 6.0_01
Kaspersky Antivirus 7.0
Logitech SetPoint (утилита для моей мыши и клавиатуры)
Ahead Nero 7
Pinnacle Studio 10
Apple Quick Time Player
Radmin Viewer 3.0
RivaTuner 2.01
Apple Safari 3.03 (браузер такой новомодный)
SAP Frontend 7.10 (здоровенная клиентская программа для продуктов SAP AG)
Serv-U (FTP сервер такой с продвинутыми возможностями для Windows)
WinRAR 3

Итого 80% софта, что стоит в моей вЕнде писано на С++. Остальные тоже может быть без С++ не обошлись, но упакованы всяким aspack'ами и UPXами, мучиться с ними в поисках истины лень. К общему числу надо добавить мелкомягкие программы и саму венду, многие части которой писаны на С++.

Игр у меня нет, но сколько их у меня ни было, почти все были в частью или полностью писаны на С++.
Так что получается С++ нужен и применяется в куче весьма известных и популярных софтин.
На жабе писана только одна - Oxygen XML Editor 8.0

Охренеть, Skype 3 для Windows на Delphi писан оказывается!!!

Что до Linux у меня, то навскидку это будут все те же

KDE со всеми программами, которые для нее написаны (а это все таки немало)
Sun JDK/JRE 6.0_02

Домой приду, поинтересуюсь поподробнее

P.S. Не придирайтесь к набору софта, который не совсем подходит к рабочей машинке, - это мой ноутбук и я его часто домой беру.

Чушь вот: http://www.boost.org/libs/spirit/ Точнее не чушь, а издевательство над людьми.

> Чушь вот: http://www.boost.org/libs/spirit/

Ну давай объявим чистый Си чушью и издевательством по результатам IOCCC.

> А потом будет позно пить боржоми.

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

> а если делать всё достаточно модульно

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

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

> Чушь вот: http://www.boost.org/libs/spirit/

Не нравится не используй. Мне например stl не нравится. Я юзаю свои классы.

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

Это не вопрос "веры" - это уже делается. Известный мне пример - Mercurial. Наверное, есть и другие.

>"...Обобщённое программирование, императивная, объектно-ориентированная..." И ещё они почему-то забыли шаблонное метапрограммирование.

Шаблоны это и есть обобщенное программирование

> Достаточно модульно можно делать только очень простые системы, которые связаны м-ду собой отношениями использования. А если подсистемы связаны наследованием: например подсистема сохранения требует чтобы в обьектах был реализован нужный интерфейс.

Ну так и нужно _всегда_ делать простые системы. Когда система становится сложной значит что-то не в порядке с уровнями абстракции и модульностью и пора эту сложноую систему разбивать на несколько простых подсистем. Например реализовать DSL который будет работать в предметной области на боллее высоком уровне.

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

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

> > Чушь вот: http://www.boost.org/libs/spirit/ Точнее не чушь, а издевательство над людьми.

> Ну давай объявим чистый Си чушью и издевательством по результатам IOCCC.

Вот чистого C там как раз нет в помине.

>а в С++ это будет вычисление энергии взрыва a при попадании ракеты b в ближайший истребитель с, с попутным запуском ракеты и форматированием корневого раздела ;-)

Иди поспи. И все наладится у тебя.

>> > Чушь вот: http://www.boost.org/libs/spirit/ Точнее не чушь, а издевательство над людьми.

>> Ну давай объявим чистый Си чушью и издевательством по результатам IOCCC.

>Вот чистого C там как раз нет в помине.

Еще раз, медленно и печально: ты считаешь, что шаблоны - это "чушь и издевательство над людьми" на основании кода Spirit? Если да, то почему бы не считать чистый Си "чушью и издевательством" на основании IOCCC?

>P.S. http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gcc&;. ..

интересны результаты для free pascal.

пример core и логики: http://debet.kiev.ua/index.php?pageid=23

также, в KDE внедряется удачная с моей точки зрения инфраструктура скриптинга в приложениях (Kross) -- она будет исп. в koffice, для апплетов (в т.ч. amaroK) и многих других KDE-программ

Намек понял :) Да, я зря не уточнил, что чушью называю шаблоны, как средство реализации функционала, а не сокращения записи однотипного кода.

> чушью называю шаблоны, как средство реализации функционала

ИМХО, зря. Шаблоны - это (Тьюринг-полный?) язык в языке :) Хотя писать на этом языке - страшное дело :D

Рекомендую почитать Александреску

Приватные конструкторы

(виски зеленкой смазал уже, ага)

> также, в KDE внедряется удачная с моей точки зрения инфраструктура скриптинга в приложениях (Kross) -- она будет исп. в koffice, для апплетов (в т.ч. amaroK) и многих других KDE-программ

в виндоус еще ранее начала внедряться аналогичная система под названием monad. Спасибо за аргументированный плевок в сторону KDE.

"Стратегия самоудушения Linux заключается в том, что она пытается быть похожей на Windows больше, чем сам Windows" (c) лень_вспоминать, была новость на никспе

да, Тьюринг-полный. к тому же, еще и функциональный.

> Приватные конструкторы

Вроде речь шла о шаблонах O_O

> (виски зеленкой смазал уже, ага)

Боюсь даже спросить - зачем...

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

На ассемблере надо писать, хотя и там макросы, мнемоники... бр! =)

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

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

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

>в виндоус еще ранее начала внедряться аналогичная система под названием monad.

kross - это не скриптинг лэнгвидж, а инфраструктура для поддержки джаваскрипта, пайтона, руби и может быть ещё чего-нибудь.

>Спасибо за аргументированный плевок в сторону KDE.

«что в сердце у него, то в пьесе видит он» -- Гёте.

>шаблоны - возможность иметь нормальные, строго типизированные структуры данных: массивы, списки и т.п.

>RAII - автоматическое освобождение ресурсов в деструкторе при выходе из блока.

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

>Больше удобства, меньше копипасты, меньше ошибок. Более компактный код.

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

ИМХО, С++ - неудачная переделка Си, ведь там столько знаков препинания и т.д. и т.п., что бошка едет. В Си всё намного проще.

>fluxbox

Справедливости ради, стОит заметить, что во Флаксе кода не так уж и много, и IMHO он не может претендовать на звание большого проекта.

>> Любые программы чей код превышает 10000 строк кода,

>И как же их мерить, строки. Вот у меня прога на руби 4000 строк, но если её переписать на плюсах будет 30000 строк. Мне срочно нужно идти переписывать?))

30K строк -- это явно гипербола. При наличии качественных библиотек размер кода на C++ может не сильно проигрывать Ruby. Например, размер кода с использованием POCO может быть гораздо меньше, чем с использованием ACE.

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

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

Боюсь, что языки с поддержкой DesignByContract (Eiffel, D, Nice, Spec#) в этом плане окажутся _гораздо_ предпочтительнее C++.

> впрочем пусть и так, тебе уже объяснили, что для С это будет сложение чисел, и вариантов в зависимости от типов не так много

> а в С++ это будет вычисление энергии взрыва a при попадании ракеты b в ближайший истребитель с, с попутным запуском ракеты и форматированием корневого раздела ;-)

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

io.put_string ("A=") io.put_integer (a) io.put_string ("B=") io.put_real (b) io.put_new_line

и сравни это с C++:

std::cout << "A=" << a << "B=" << b << std::endl;

и подумай, во что выльется сопровождение очевидного кода при необходимости смены типа a с INTEGER на NATURAL, и b с REAL на COMPLEX.

> С++ такой же низкоуровневый как и С.

Т.е. такой же "портабельный ассемблер" ? Ты ничего не путаешь.

> При этом он еще и на порядок удобнее благодаря шаблонам, перегрузке, RAAI.

Читать чужой кой код код на C++ написанный с использованием низкоуровневых фич языка вперемешку с шаблонами - это проще сразу застрелиться.

Вообщем в язык тянут всё что можно, и он становиться всё монструознее (а ля PL/1). Никогда не понимал - зачем всё тянуть в один язык ? Нельзя обьять необьятное. Что мешает разбить проект на части, и каждую писать на наиболее подходящем языке. Один хрен те же средства параллельного программирования в C++0x к Адовским и близко не подходили. Или тяжело несколько языков осилить ?

> По теме: нововведения радуют, но сам язык станвится уже даже не сложным, а офигенно сложным :/

Угу. Обнадеживает, что к моменту официального выхода C++0x уже может быть D2.0, который более простой и не менее мощный. Да и компилируется на пару порядков быстрее.

> > Один из главных законов программирования - Преждевременная оптимизация - Зло. Сюрприз, ага?

> А потом будет позно пить боржоми.

Бред. Ибо основная оптимизация делается алгоритмами. И только потом (месте так на десятом) идёт быстродействие генерируемого кода, если конечно у нас языки не на порядки скоростью отличаются. Пишем, прогоняем профайлер, узкие места переписываем. Правило 80/20 еще никто не отменял. Против связки CL+C/Ocaml+C (или против Ады) у C++ преимуществ нет.

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

> Бред. Ибо основная оптимизация делается алгоритмами

Бред. Производительность может падать из-за чего угодно: дурацких схем ввода-вывода, распределения памяти, и т.п.

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

А ты кернел-маньяк, для которого все user-mode приложения - детский сад?

> С++ славился своей простотой

Я тоже хочу этой травы

>>шаблоны - возможность иметь нормальные, строго типизированные структуры данных: массивы, списки и т.п.

>>RAII - автоматическое освобождение ресурсов в деструкторе при выходе из блока.

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

>>Больше удобства, меньше копипасты, меньше ошибок. Более компактный код.

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

Судя по категоричности высказываений, ты ветеран программирования ядер ОС круче Дэвида Катлера и Линуса Торвальдса вместе взятых. Раскрой тему, а? Ну вроде "строго типизированные структуры данных в ядре ОС не нужны, потому что ,,,".

> Против связки CL+C/Ocaml+C (или против Ады) у C++ преимуществ нет.

Кроме одной мелочи - C++ знает на порядок-два больше людей, Ада... она за 25 лет не вышла за пределы свой песочницы, у Ocaml - неотключаемый сборщик мусора, CL - это просто нагромождение дурацких скобочек :-P. В общем, некуда податься, кроме как в Си++ :)

P.S Против связки Си++ и Питон вообще ни у кого преимуществ нет ;)

>> По теме: нововведения радуют, но сам язык станвится уже даже не сложным, а офигенно сложным :/

> Угу. Обнадеживает, что к моменту официального выхода C++0x уже может быть D2.0, который более простой

D - более простой? o_O ИМХО, его сложность даже и оправдать никак нельзя (в отличие от сложности Си++). Кроме того, в нем сборка мусора, а это значит - в сад до появления realtime-сборщиков.

> Да и компилируется на пару порядков быстрее.

аха, за отрицательное время :)

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

По сравнению с алгоритмической оптимизацией это мелкие проценты от всего готового продукта.

> Кроме одной мелочи - C++ знает на порядок-два больше людей,

Не аргумент. Хороший спец новый язык выучивает достаточно быстро, при условии знания парадигмы. "Быдлокодеров за еду" (C) мы не учитываем.

> Ада... она за 25 лет не вышла за пределы свой песочницы,

У неё своя оччень жирная ниша в сфере встраиваемых систем. Просто у неё слава очень сложного языка, и всё - бояться. Хотя куда ей до сложности, а уж тем более неочевидности и неоднозначности C++.

> CL - это просто нагромождение дурацких скобочек :-P.

Аргументы будут ?

> В общем, некуда податься, кроме как в Си++

Я вот наоборот - ушёл от C++ на CL+C и Аду.

> "Быдлокодеров за еду" (C) мы не учитываем.

_Вы_ не учитываете. Мы - учитываем.

>> Ада... она за 25 лет не вышла за пределы свой песочницы,

>У неё своя оччень жирная ниша в сфере встраиваемых систем.

Ну, может быть... я не видел. Объективные данные есть?

>> CL - это просто нагромождение дурацких скобочек :-P.

>Аргументы будут ?

Ты чо, это же была провокация флейма :D А вообще - те же аргументы, что и по Аде... только у Лиспа было не 25 лет, а 50.

>> В общем, некуда податься, кроме как в Си++

>Я вот наоборот - ушёл от C++ на CL+C и Аду.

Если не секрет - какие задачи? Сколько человек в команде?