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

>>QNX

И еще BeOS, кстати ;-)

>Ты бы сначала определил, каким именно значением термина "исключение" ты пользуешься.

нормальным. Из ядра QNX исключения не передаются приложениям иначе чем через SIG* или как ошибки, возвращаемые функциями.

>И еще BeOS, кстати ;-)

помянем

> Пока у нас не используются java-CPU надо быть полным идиотом чтобы говорить что низкоуровневые языки программирования не нужны. Товарищ, на чём вы напишете java-машину?

Надо быть полным идиотом, чтобы так отвечать на

> даже MS VC поддержка С++ на уровне текстового редактора с подсказками, недалеко ушло от Турбо Паскаля, про остальное вообще молчу Программеры на C++ это кустари-краснодеревщики - комодик с витыми ножками настругать.Этот язык отжил свое.Будущее за управляемыми языками со сборкой мусора. А восторженные вопли про С++ это типа дедовщины - мы мучились, учили эту никому теперь ненужную хрень, надо чтоб и вам досталось

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

Посмотрите и послушайте Страуструпа: http://video.google.com/videoplay?docid=5262479012306588324

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

>> Ты бы сначала определил, каким именно значением термина "исключение" ты пользуешься.

> нормальным

Ты его сформулируй :)

> Из ядра QNX исключения не передаются приложениям иначе чем через SIG* или как ошибки, возвращаемые функциями.

o_O причем здесь это?

> Интересно, а Гик отметился в теме? А то я его заигнорил ;)

ага :)

> си плюс плюс оу икс, думаю так будет ближе всего к оригинальному произношению

си плас плас о-экс (если оу, то длино получается, "у" съедается на конце).

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

Как новость относится к Linux ? :)

>Но тебе достаточно просто показать ядро ОС на C++ с подержкой исключений как аргумент в свою пользу ;)

>QNX

вообще-то в линуксе подержкой исключений в ядре - это нонсенс

>> си плюс плюс оу икс, думаю так будет ближе всего к оригинальному произношению > си плас плас о-экс (если оу, то длино получается, "у" съедается на конце).

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

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

>Как новость относится к Linux ? :)

http://gcc.gnu.org/gcc-4.3/cxx0x_status.html

К Linux никакого. Зато к LOR самое прямое. Светлой памяти Луговского.

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

ты тоже не прав. Икс в конце - лзначает что они еще не определились с полным названием этого стандарта. например, уже были C++98 и C++03.

про это написано в википеддии

>The ISO/IEC JTC1/SC22/WG21 C++ Standards Committee aims to introduce the new standard in 2009 (hence the standard that is today called C++0x will become C++09)...

>>Как новость относится к Linux ? :)

>http://gcc.gnu.org/gcc-4.3/cxx0x_status.html

И что Вы хотели этим сказать ?

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

>И что Вы хотели этим сказать ?

Что планируется к использованию

> ты тоже не прав. Икс в конце - лзначает что они еще не определились с полным названием этого стандарта. например, уже были C++98 и C++03.

Афигеть, какой левый ответ.

>> просто это лучшее IDE под линукс для написания сишных программ
>Почему лучшее? Я NetBeans использую, а Eclipse вообще не нравится. Может NetBeans лучше?
Лучшее - враг хорошего. А хорошее IDE - то, которое ты всегда/привык/умеешь/знаешь_как пользовать...

> Да кого волнует эта классификация в педивикии.

А кого интересует твое мгнение, если на то пошло?

> С++ низкоуровневый по возможностям, а не по классификации.

Да, у него есть C как подмножетсво. :)

>> Язык C компилируется в машинные коды очевидным образом. В отличие от C++, где этот процесс, мягко говоря, неочевиден

> Бред.

Поясняю.

/* Язык С. Это сложение двух чисел (указатели - тоже числа), возможно вещественных */

c = a + b

// Язык C++: а это на самом деле вывзов переопределенных операторов

c = a + b

> Так же дрова пишут на С++.

Покажите пожалуйста дрова, для которые используют C++ для взамодействия с ядром. ОС.

Значит, другу-программеру никогда не приходилось обрабатывать графы? Ничего себе "быдлокод" у него получается!

>> Скажи, друг-программер, shared_ptr могут учитывать циклические ссылки?

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

Надо же, а мужики-то не знают...

> QNX

Кстати, а где доказательства этого факта? Я не нагуглил.

> // Язык C++: а это на самом деле вывзов переопределенных операторов

> c = a + b

И это называется неочевидностью _генерируемого_ кода? o_O

> Покажите пожалуйста дрова, для которые используют C++ для взамодействия с ядром. ОС.

Ну зачем прикидываться шлангом? Даже если ядро ОС написано на Си++ и внутри всё из себя объектно-ориентированное, он должно обеспечивать интерфейс с модулями на Си (пригодный и для Си++), поэтому не имеет смысла экспортировать интерфейс для чистого Си++.

беги рассказывать ;)

> И это называется неочевидностью _генерируемого_ кода? o_O

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

One of the original design goals for C was that it be fairly easy to determine what the generated object code would be, thus making it quite suitable for kernel-mode work. C++ is a much more complex language, and consequently making it work in the kernel environment has proven to be much more difficult.

> Даже если ядро ОС написано на Си++ и внутри всё из себя объектно-ориентированное, он должно обеспечивать интерфейс с модулями на Си (пригодный и для Си++), поэтому не имеет смысла экспортировать интерфейс для чистого Си++.

Исключений нет, интерфейс на 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++, комментарии "//" ?

>> // Язык C++: а это на самом деле вывзов переопределенных операторов >> c = a + b

>И это называется неочевидностью _генерируемого_ кода? o_O

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

по поводу взаимодействия C++ с ядром и др. могу напомнить что ABI С++ это тоже головная боль, в отличие от прозрачного ABI С

по поводу вопрос прозвучавших ко мне - я пишу на С и на С#,для души на Nemerle каждому своя ниша, С++ просто излишен, на мой взгляд это зомби, и каждая ревизия стандарта это просто лишнии кило штукатурки на его страшное рыло. хотите свежих идей - Nemerle,хотите продакшн - С#, в нем реально развиваются фичи для производсва, взять хотя бы тот же LINQ на счет наукоемкого кода - гляньте на бенчмарки - С# проигрывает проценты c++

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

Аналогично можно наехать на Си со стороны ассемблера (взять хотя бы приведение типов). В С++ тебе даётся функционал, которым ты можешь пользоваться, а можешь и не пользоваться

>> И это называется неочевидностью _генерируемого_ кода? o_O

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

Цитирую: "Язык C компилируется в машинные коды очевидным образом. В отличие от C++, где этот процесс, мягко говоря, неочевиден". Ну и что же неочевидного в _генерируемом_ коде? Каждый оператор - это вызов функции, всё. Неочевиден _исходный код_, это да. Но бороться с этим - элементарно (ну не перегружайте операторы), хотя выгоды от этого неочевидны.

> One of the original design goals for C was that it be fairly easy to determine what the generated object code would be, thus making it quite suitable for kernel-mode work. C++ is a much more complex language, and consequently making it work in the kernel environment has proven to be much more difficult.

Это рекламный материал на C#, да?

> Исключений нет, интерфейс на 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."

Уффф... я не понял, к чему это. К тому, что Микрософт ниасилил (или не захотел осиливать) Си++ (точнее, исключения) для ядра? А с каких пор MS - светоч технологий? Тем более что ядро NT написано не на Си++, а на расширенном (с исключениями) Си.

А писать драйверы на Си++ можно... для Линукса есть минимум одна такая среда. В других системах практиковался kernel-mode код на Си++ (GFS написана на Си++), есть ядра на Си++ (BeOS). Так что _принципиальных_ ограничений нет, хотя runtime-поддержка более сложная.

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

Под RAAI подразумевалось Resource acquisition and/as/is Initialization (RAII) или таки вы имели ввиду RTTI ?

>> И это называется неочевидностью _генерируемого_ кода? o_O

> ну и объясни что тут очевидного?

Еще раз, медленно и печально - речь шла о _генерируемом_ коде, а не исходном.

> могу еще добавить, что тут еще кучка конструкторов

Да неужели? Ты, наверное, хотел сказать "может вызываться"... а может и не вызываться.

> могу напомнить

Спасибо. Только почему ты решил, что я забыл об этом?

> ABI С++ это тоже головная боль

ABI нужно проектировать, и опыт проектирования ABI на Си++ есть - используй его.

> К тому, что Микрософт ниасилил (или не захотел осиливать) Си++ (точнее, исключения) для ядра?

Ну он не то чтобы ниасилил - просто он не даёт этот фреймворк разработчикам. От сторонних разработчиков такие фреймворки существуют (в том числе самопальные). Там и C++ и исключения в ядре. Вот поэтому он и "не рекомендует" ;)

>Еще раз, медленно и печально - речь шла о _генерируемом_ коде, а не исходном.

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

>> могу еще добавить, что тут еще кучка конструкторов

>Да неужели? Ты, наверное, хотел сказать "может вызываться"... а может и не вызываться.

я не только хотел это сказать, а даже написал :-)

>> ABI С++ это тоже головная боль

>ABI нужно проектировать, и опыт проектирования ABI на Си++ есть - используй его.

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

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

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

> мне неочевидно какой код будет сгенерирован

А по-моему, тебе неочевидно, что там написано

> не появился ли еще один тип который может быть применен компилятором в моем не изменявшемся коде

А думать о том, не изменились ли какие-то алгоритмы обычных Си-функций тебе не нужно? /me пожимает плечами

>>ABI нужно проектировать, и опыт проектирования ABI на Си++ есть - используй его.

>а ничего, что я хочу непосредственно свою задачу решать

Ничего. В смысле - твои желания не имеют большого значения.

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

Если ты не переписывал, то откуда знаешь, сколько строк будет? :D

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

И кто тебе мешает решать задачи, велосипедных дел мастер? :)

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

> А думать о том, не изменились ли какие-то алгоритмы обычных Си-функций тебе не нужно? /me пожимает плечами

представь себе, в приведенном случае определенно нет. /me улыбается

>>>ABI нужно проектировать, и опыт проектирования ABI на Си++ есть - используй его.

>>а ничего, что я хочу непосредственно свою задачу решать

>Ничего. В смысле - твои желания не имеют большого значения.

равно как и твои предложения

>> А думать о том, не изменились ли какие-то алгоритмы обычных Си-функций тебе не нужно? /me пожимает плечами

>представь себе, в приведенном случае определенно нет. /me улыбается

"Приведенном"? Слишком уж невнятно описан этот "приведенный" случай.

>> Ничего. В смысле - твои желания не имеют большого значения.

> равно как и твои предложения

Я вроде ничего не предлагал. То, что ABI нужно проектировать - это просто факт жизни.

> А что там остается от C++, комментарии "//" ?

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

>"Приведенном"? Слишком уж невнятно описан этот "приведенный" случай.

попробую еще раз, гляди внимательнее: a = b + c;

>Я вроде ничего не предлагал. То, что ABI нужно проектировать - это просто факт жизни.

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

> хотите продакшн - С#, в нем реально развиваются фичи для производсва, взять хотя бы тот же LINQ

MS опять делает удивительные инновации десятилетней давности? Embedded SQL есть уже у всех, кроме MS :) Который не осилил сделать автодополнение в обычном синтаксисе SELECT x FROM y ( у них там FROM y SELECT x)

Жжоте, сударь :)

>>"Приведенном"? Слишком уж невнятно описан этот "приведенный" случай.

> попробую еще раз, гляди внимательнее: a = b + c;

Ну хорошо... предположим, это Си. Что значит этот фрагмент? Какой код будет сгенерирован?

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

[Я не работал с eCOS, поэтому не могу судить о ней]

Может быть, потому, что ОС на Си пишут уже 35 лет, а на Си++ - всего 10-15? Если вам не преподавали историю нашего ремесла, скажу, что лет 20-25 назад C ABI тоже вызывал проблемы.

> Цитирую: "Язык C компилируется в машинные коды очевидным образом. В отличие от C++, где этот процесс, мягко говоря, неочевиден". Ну и что же неочевидного в _генерируемом_ коде? Каждый оператор - это вызов функции, всё. Неочевиден _исходный код_, это да. Но бороться с этим - элементарно (ну не перегружайте операторы), хотя выгоды от этого неочевидны.

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

> MS опять делает удивительные инновации десятилетней давности? Embedded SQL есть уже у всех

Вообще-то Embedded SQL - это 25-30 лет назад. Но LINQ - это _не_ Embedded SQL, а гораздо более мощная вещь (хотя стоит ли оно усложнения языка - вопрос).

>> попробую еще раз, гляди внимательнее: a = b + c;

>Ну хорошо... предположим, это Си. Что значит этот фрагмент? Какой код будет сгенерирован?

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

>Может быть, потому, что ОС на Си пишут уже 35 лет, а на Си++ - всего 10-15? Если вам не преподавали историю нашего ремесла, скажу, что лет 20-25 назад C ABI тоже вызывал проблемы.

предлагаешь подождать лет десять? ну так бы сразу и сказал!

> С++ просто излишен, на мой взгляд это зомби, и каждая ревизия стандарта это просто лишнии кило штукатурки на его страшное рыло. хотите свежих идей - Nemerle,хотите продакшн - С#, в нем реально развиваются фичи для производсва, взять хотя бы тот же LINQ на счет наукоемкого кода - гляньте на бенчмарки - С# проигрывает проценты c++

В наукоемких программах дот-нетовский фреймворк не востребован и все преимущества С# сводятся к нулю.

> (типы только задай)?

Аааа, так типы задать всё-таки нужно? С этого и нужно начинать. Кстати, а почему типы должен задавать я? Это твой пример.

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

Я? Волновался? Да ТНБ с тобой, я просто не понимал тебя (и сейчас не понимаю). Пример - если тип a изменится с целого на плавающий, код разве не изменится?

>>Может быть, потому, что ОС на Си пишут уже 35 лет, а на Си++ - всего 10-15? Если вам не преподавали историю нашего ремесла, скажу, что лет 20-25 назад C ABI тоже вызывал проблемы.

>предлагаешь подождать лет десять?

Не предлагаю. Стандарт ABI для Си++ уже принят и реализован - пользуйся.

Да, и еще... чего ты так привязался к ABI? Ты что, пишешь исключительно библиотеки, распространяемые в бинарном виде?