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

> А быстродействие при этом во сколько раз падает?

А пофигу. Хоть в 500 раз. Мы не про это спорим, я говорю что есть например проект на 4000 который могут поддерживать 2 человека. А тот же C++ код в 30К будут поддерживать уже 6-7. Всё равно будет намного дешевле писать на высокоуровневом языке, а потом искать боттелнеки и переписывать их на С или например erlange в случае высоконагруженных систем массового обслуживания. Чем писать всё изначально на языке в несколько раз ниже уровнем с самого начала.

>> А быстродействие при этом во сколько раз падает?

> А пофигу. Хоть в 500 раз.

/me завидует

> искать боттелнеки и переписывать их на С или например erlange

IIRC, в системах на эрланге критический код пишеться на Си :)

> отношение руби кода к c++ коду 4/1 на самых простых программах и увеличивается с ростом приложения.

4/1, говоришь? 4 строки руби к одной строке с++? да, впечатляет отношение к арифметике и далеко идущим выводам :)

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

Это намёк на vala/GObject? Список "вменяемых" и критерий вменяемости языков огласите зрителям в зале :)

> IIRC, в системах на эрланге критический код пишеться на Си :)

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

>> IIRC, в системах на эрланге критический код пишеться на Си :)

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

Ну да, в роли запускалки Си-процедур :) Раньше так Occam использовали.

> Это намёк на vala/GObject?

Это намёк на многие другие способы проведения границ абстрацкии. Например LOP.

> Список "вменяемых" и критерий вменяемости языков огласите зрителям в зале :)

C, Ruby, Lisp, Haskell, Erlang, Nemerle :)

Критерии у каждого свои в своей нише.

> Ну да, в роли запускалки Си-процедур :) Раньше так Occam использовали.

В задачах высоконгруженных систем массового обслуживания числодроблики занимают от силы 5-7% функционала. А чаще и меньше. Вот например в yaws из 28000 строк кода, только 500 на С.

>Критерии у каждого свои в своей нише.

Вы лично не видите никакой ниши для С++?

> В задачах высоконгруженных систем массового обслуживания числодроблики занимают от силы 5-7% функционала.

В статье об использовании Erlang в коммутаторах Ericsson цифра была другая - на эрланге было менее половины кода.

Плохо, у меня инет барахлит, а так закачал бы.. а ещё инглиш фигово знаю

> Вы лично не видите никакой ниши для С++?

Возможно те вещи, где само нагруженное ядро с досточно сложной логикой, там где С будет слишком низкоуровнево. 3D игры, те же CAD системы. Но всё равно всю бизнес логику стоит писать на более высокоуровневом языке и тока ядро на плюсах. Но конечно у него и здесь есть альтеративы, пускай немного более тормозные но с учётом роста производительности железа это не существенно. Разве опять же только в 3D играх, где нужно выжимать всё из железки до последей капли.

> В статье об использовании Erlang в коммутаторах Ericsson цифра была другая - на эрланге было менее половины кода.

Ну да, но это всё же коммутаторы, там много системщены. Но, если не изменяет память, в этой статье говорилось что эти "менее половины" обеспечивали 80% функционала.

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

глупости. смотрите ISO/IEC 9899:1999 (С99), 5.1.2.3. если у вас нет стандарта, то в кратце и утрировано - доступ к volatile переменным, модификация обьектов ос, ввод-вывод - все это side effects. выполнение программы - это последовательность side effects. все, что не влечет за собой изменения последовательности side effects, может быть заоптимизировано вплоть до полного исчезновения.

сравните это с ISO-IEC-14882 (С++), 1.9 и найдите 10 отличий.

>Исключений нет, интерфейс на C, "we do not recommend using Standard Template Library functions in a kernel-mode driver", "Microsoft developers have discovered a number of areas where C++ presents particular problems for kernel-mode drivers." А что там остается от C++, комментарии "//" ?

вы видимо полагаете, что с++ - это Microsoft С + Dincumware STL + исключения?

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

ваши личные половые проблемы. вы и объясняйте.

писец, название в стиле Страуса-Труппа ); лаконичнее бы было C++%v#qKc%bbNp8jS@q@e8&KQzP

> все, что не влечет за собой изменения последовательности side effects, может быть заоптимизировано вплоть до полного исчезновения.

Это конечно позволяет уровнять С с C++, где при сложении вызываются конструкторы копирования и переопределенные операторы?

> вы видимо полагаете, что с++ - это Microsoft С + Dincumware STL + исключения?

Ну как покажут драйвер на С++ - так и будем на него смотреть.

>Разве опять же только в 3D играх, где нужно выжимать всё из железки до последей капли.

"только в 3D играх" ??? Интенсивный путь развития полупроводниковой промышленности остановился давно, экстенсивный вскоре заставит больше думать о MIPS/кВт - тогда и увидим, чем будут пренебрегать

> Ну как покажут драйвер на С++ - так и будем на него смотреть.

То-то на Си много драйверов...

int main(){

.asm{
драйвер
}


}

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

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

А что такой большой файл? У них там что, круглый стол с перерывами на кофе? Хотел было скачать, но скорость что-то не очень...

P.S. В настоящее время делаю проект на гремучей смеси C/C++, пока живой (и я и проект).

"...In C, the volatile keyword is provided to inhibit optimisations which remove or reorder memory operations on a variable marked as volatile. This will provide a kind of barrier for interruptions which occur on a single CPU, such as signal handlers or concurrent threads on a uniprocessor system. However, the use of volatile is insufficient to guarantee correct ordering for multiprocessor systems because it only impacts reorderings performed by the compiler, not those which may occur at runtime such as those performed by the CPU."

http://en.wikipedia.org/wiki/Memory_barrier

"...A proposal for C++0x includes using the volatile keyword for communication between threads. Under this proposal, the compiler would guarantee thread-safety for concurrent reading and writing of volatile objects. This would, in effect, cause compilers to emit thread-synchronization code for accessing/modifying co-modified objects. However, this solution appears inappropriate if applied to complex objects and its use is still in discussion."

"...At this stage, full support for multiprocessing appears too dependent on the operating system used, and too complex to be resolved only through an extension of the core language. The common understanding is that multiprocessing support shall be created via a high-level library instead of a low-level library (with potentially dangerous synchronization primitives), as the Committee's goal is not to motivate programmers to use a potentially dangerous standard library instead of a secure but non-standardized library."

http://en.wikipedia.org/wiki/C++0x

в общем, старые гланды были и будут, остальное в "Multitasking utilities" кроме future это украшательства для облегчения

>Ну как покажут драйвер на С++ - так и будем на него смотреть.

А что вы там хотите увидеть? Файл с расширением cpp, работа с свойствами объекта внутри драйвера, передача данных объекта через IRP-стек? Так это и я могу за несколько минут сделать. Только никакой функционально нагрузки на объектную модель не будет, если в том нет необходимости.

> Это конечно позволяет уровнять С с C++, где при сложении вызываются конструкторы копирования и переопределенные операторы?

-- доктор, мне больно, когда я так делаю. -- а Вы так не делайте.

echo "grep -r operator /home/the_biggiest_repo | mail -s 'кастрировать того, кто это сделал' team_alias@mail.localdomain" > /etc/cron.daily/check_repo

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

> Ну как покажут драйвер на С++ - так и будем на него смотреть.

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

>Рисуем графики количества вакансий на тех (C\C++\Delphi) и на других (все остальные из распространенных?), экстраполируем.

Рисуем графики по вакансиям на Win- и Lin-админов, экстраполируем.

Ура, будущее за мыше-администрированием!

> Возможно те вещи, где само нагруженное ядро с досточно сложной логикой, там где С будет слишком низкоуровнево. 3D игры, те же CAD системы. Но всё равно всю бизнес логику стоит писать на более высокоуровневом языке и тока ядро на плюсах

Ты ничего не выиграешь от такой схемы. Во первых тебе потребуется создать биндинг к С++ ядру, во вторых ты потеряешь доступ к advanced фичам С++.

Сейчас посмотрел у себя: ядро 2 мегабайта кода на С++, гуй - 650Кб При этом С++ меня устраивает настолько, что я не вижу вообще никакого смысла в использовании дополнительных языков. Единственным исключением является встроенный в программу простенький механизм для вызова команд из встроенной консоли.

>> Возможно те вещи, где само нагруженное ядро с досточно сложной логикой, там где С будет слишком низкоуровнево. 3D игры, те же CAD системы. Но всё равно всю бизнес логику стоит писать на более высокоуровневом языке и тока ядро на плюсах

> Ты ничего не выиграешь от такой схемы.

Тем не менее она сейчас набирает популярность

> Во первых тебе потребуется создать биндинг к С++ ядру

SWIG, Boost.Python

> во вторых ты потеряешь доступ к advanced фичам С++.

Каким, например? И нужны ли они в скриптовом языке?

>Это конечно позволяет уровнять С с C++, где при сложении вызываются конструкторы копирования и переопределенные операторы?

точно так же как уравнять автомобиль с телегой. все дело в волшебных пузырьках, а имено любите садомозахизм? объявляйте все конструкторы explicit, не перегружайте операторов и пишите вместо непонятного, громоздкого и угребищного c = a + b легкое, приятное и короткое

assign(c, add((xx)a, (yy)b))

только не забудьте, что assign может позвать некоторую ngissa, а та в свою очередь еще чего нибудь и т.д.

меня вот только одно смущает, такая "несомненно вредная штука" как перегрузка операторов, а присутствует и в С# и в Ada и в Python и в Ruby и ... короче ее нет только в жаба, да и там скоро появится. ну не прислушиваются к вам люди!

В переводе Гоблина есть где уже?

struct NonCopyable
{
  NonCopyable & operator=(const NonCopyable&) = delete;
  NonCopyable(const NonCopyable&) = delete;
  NonCopyable() = default;
};

охренеть, они в энтом кометете чуть не на каждый use case по перегрузке/ключевому слову добавляют, ещё пара итераций стандарта и полностью знать язык не будет никто, цпп мне нравится всё меньше и меньше, бритва Оккама тут не сущности, а яйца разрабов стандарта должна резать :E

эээ... а кто видел интервью? :-D

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

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

2. Какие таки "advanced" фичи есть в С++, которые я не найду в дргуих языках?

или это - оффтопик?))

я закачал за пару часов 16% из 684M, завтра надеюсь посмотрю, надо где-нить на широкополосном выложить, есть предложения?

> они в энтом кометете чуть не на каждый use case по перегрузке/ключевому слову добавляют, ещё пара итераций стандарта и полностью знать язык не будет никто

О, наконец-то пошли претензии по делу :)

>в общем, старые гланды были и будут, остальное в "Multitasking utilities" кроме future это украшательства для облегчения

есть куча предложений (proposals), где фигурируют явные барьеры что то типа

atomic<aquire>(p) = y; ... atomic<release>(m) = x;

( Hans Boehm & Aleksander Terekhov )

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

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

2 ключевых слова (не новых к стати) - delete и default, которые ни разу не напрягает, а очень даже полезны.

Вот и новый стандарт подоспел.

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

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

Или вам напомнить из-за чего Торвальдс отказался брать курс на микроядра?

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

>> Ты ничего не выиграешь от такой схемы.

>Тем не менее она сейчас набирает популярность

Популярность и здравый смысл - разные вещи

>> во вторых ты потеряешь доступ к advanced фичам С++.

>Каким, например? И нужны ли они в скриптовом языке?

Шаблоны. Они рулят.

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

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

> Шаблоны. Они рулят.

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

> Популярность и здравый смысл - разные вещи

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

> Шаблоны. Они рулят.

В статически компилируемом языке - да. В динамическом - бесполезны.

>> Шаблоны. Они рулят.

>Хз, ниасилил.

Тогда ты ниасилил Си++ :)

> Вообще, насколько я знаю, нормальные люди стараются избегать шаблонов

Чушь

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

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

ЛОЛШТО?

>>А быстродействие при этом во сколько раз падает?

>А пофигу. Хоть в 500 раз

Мдя....

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

Кстати Variadic templates на подходе. Наконец то мы получим типизированный printf вместо этих быдло-iostream

>Всё равно будет намного дешевле писать на высокоуровневом языке, а потом искать боттелнеки и переписывать их на С или например erlange в случае высоконагруженных систем массового обслуживания.

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

> В случае с CAD/CAD - ты получишь только босый хер и потерю времени.

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