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

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

/me давно этого ждал

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

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

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

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

я пишу просто портируемый код, вам привести, к примеру, кусок скрипта линкера для С++ платформы?

>Единственная фича С++ которую нельзя использовать в ядре - это исключения.

Речь про какое ядро ? Linux или NT ?

Про первое точно не помню (давно смотрел C++ фреймворк для ядра) а во втором можно точно.

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

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

Если код писал идиот с хорошо развитой фантазией, так и будет. И что? Если бы это делал код:

assign(a, plus(b, c))

было бы легче?

>>Единственная фича С++ которую нельзя использовать в ядре - это исключения.

>>Речь про какое ядро ? Linux или NT ?

> Про первое точно не помню

Можно

вы такие вещи руками делаете?

>вы такие вещи руками делаете?

увы, для embedded приходится делать это руками

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

>я пишу просто портируемый код, вам привести, к примеру, кусок скрипта линкера для С++ платформы?

Куда портируемый? На каких платформах Си ABI одинаковые?

> привести, к примеру, кусок скрипта линкера для С++ платформы?

Да. И, если можно, с комментариями - "вот это можно было бы не делать, если бы я не использовал Си++".

А что такое "С++ платформа"?

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

Ссылочку можно. а то я видимо пропустил.

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

ЛОЛНУБ, ты хоть раз С++ код дизасемблером смотрел?

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

> Ссылочку можно. а то я видимо пропустил.

http://gcc.gnu.org/gcc-3.2/c++-abi.html (заметь ссылку в самом начале страницы). Это первый кросс-компиляторный стандарт, реализованный GCC. Впоследствии дополнен, и компиляторы ветки 4.x реализуют 2 стандарта - старый и новый.

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

Можно дурной вопрос ? Зачем это всё в ядре ?

>> есть еще шаблоны, наследование, полиморфизм и RAII.

> Можно дурной вопрос ? Зачем это всё в ядре ?

Шаблоны? <linux/list.h> Наследование? Любая ФС или драйвер. Полиморфизм? Везде полезная вещь. RAAI? В ядре тоже выделяют/освобождают ресурсы, и бывают утечки памяти.

Или ты хотел сказать, что без всего этого можно обойтись? Так с этим никто не спорит.

> Можно дурной вопрос ? Зачем это всё в ядре ?

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

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

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

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

>Куда портируемый?

это так важно?

>На каких платформах Си ABI одинаковые?

если бы они были одинаковые, портирования бы не было вообще ;-)

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

для С++ это сделать НЕ-РЕ-АЛЬ-НО, поэтому для embedded он мягко говоря не годится, впрочем как и для OS kernel тоже, хотя костыль всегда можно назвать вертолетом.

> Да. И, если можно, с комментариями - "вот это можно было бы не делать, если бы я не использовал Си++".

угу, разбежался. я уже привел один из примеров, ну еще можно сказать о name-mangling которого достаточно для того, чтобы о надежном использовании function-pointers в С++ модулях можно было забыть

Он просто не понимает разницы между возможностью, удобством и необходимостью.

> угу, разбежался. я уже привел один из примеров, ну еще можно сказать о name-mangling которого достаточно для того, чтобы о надежном использовании function-pointers в С++ модулях можно было забыть

Каким образом name-mangling связано с function-pointers?

>> Куда портируемый?

> это так важно?

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

>>На каких платформах Си ABI одинаковые?

>если бы они были одинаковые, портирования бы не было вообще ;-) .

Тогда зачем вообще ты упомянул портирование вместе с ABI?

> на С эта проблема вполне решаема, и давно опробована, есть стандарты и соглашения для разных применений

На Си++ эта проблема тоже решена. Не так давно, как на Си, конечно.

> для С++ это сделать НЕ-РЕ-АЛЬ-НО,

Делали уже. Не надо кричать, тем более 4.2

> поэтому для embedded он мягко говоря не годится

Embedded бывает сильно разный.

> угу, разбежался.

*shrug* ты сам предлагал, Хозяин своего слова, понятно.

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

ищи не только под фонарём.

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

Угу. После интегрированных лямбд это звучит особенно феерично :-)

> В нормально спроектированных программах таких проблем нет.

"Этого не может быть, потому что этого не может быть никогда" (C)

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

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

>На Си++ эта проблема тоже решена. Не так давно, как на Си, конечно.

4.2, увы. Ссылку на gcc 3.2 больше не давай, несерьезно. Дай лучше ссылку на что-нибудь подобное например MISRA (гугль тебе в помощь). Про коммерческие среды контроля кода, думаю бесполезно рассказывать. С++ там в мальчиках для битья.

> Embedded бывает сильно разный.

пример пожалуйста, действительно успешного применения С++, а не битвы с трудностями, предварительно самостоятельно созданными

> *shrug* ты сам предлагал, Хозяин своего слова, понятно.

ты пока не ответил даже на то, что было приведено, или я на тебя должен пахать а ты левой пяткой отпихивать?

>>если бы они были одинаковые, портирования бы не было вообще ;-) .

>Тогда зачем вообще ты упомянул портирование вместе с ABI?

странно, а что в С портировать кроме как ABI зависимости? (а вот для С++ я даже такого сказать не могу, там такой зоопарк компиляторов и стандартов, что мама не горюй)

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

>боюсь, они останутся для тебя туманными и дальше, ты просто не в теме,

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

> С++ постоянно бракуется консорциумами при стандартизации встроенных применений

Еще раз - embedded бывает разный, причины для браковки - тоже (например, фирме XXX не под силу реализовать в своем компиляторе фичу YYY, и фича бракуется).

И не embedded'ом единым живет мир.

> Ссылку на gcc 3.2 больше не давай, несерьезно.

Ссылка на 3.2, т.к. это первая свободная реализация Си++ ABI, все последующие версии GCC его реализуют тоже. А почему это несерьезно? Ты им не пользуешься? Ну а куча народа - пользуется

>> Embedded бывает сильно разный.

>пример пожалуйста, действительно успешного применения С++

Ну, мы пишем на нем. Правда, у нас вполне обычный Линукс, а не eCOS.

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

И это недостаток _языка_? Ну а MISRA - это круто, да. Для них даже обычный Си слишком наворочен, им MISRA C подавай.

>< *shrug* ты сам предлагал, Хозяин своего слова, понятно.

> ты пока не ответил даже на то, что было приведено

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

>> Тогда зачем вообще ты упомянул портирование вместе с ABI?

> странно, а что в С портировать кроме как ABI зависимости?

Портировать _куда_? Между Виндой и Линуксом ABI - наименьшая головная боль.

>Портировать _куда_? Между Виндой и Линуксом ABI - наименьшая головная боль.

дружище ))) забей )))

нет смысла спорить с упёртыми людьми, ну не нравится им плюсы ну и не надо )) Я вот на них пишу с 16 лет уже почитай 15 лет и всё нормально ))

> ищи не только под фонарём.

То есть фактов не будет?

ну ладно, давай завязывать

>И не embedded'ом единым живет мир.

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

> дружище ))) забей )))

Дык хочеться понять человека - вдруг он встретил реальные грабли, на которые я еще не наступал :D

>> странно, а что в С портировать кроме как ABI зависимости?

>Портировать _куда_? Между Виндой и Линуксом ABI - наименьшая головная боль.

мучитель, да причем тут OS вообще?! ширина слова, модели памяти, bit & byte endianess, объявление секций кода и др. вот особенности C ABI

или для тебя gcc + x86 = наше все?!

>>Портировать _куда_? Между Виндой и Линуксом ABI - наименьшая головная боль.

> мучитель, да причем тут OS вообще?!

ну ты же не говоришь, что и куда ты портируешь :( Приходится гадать :/

> ширина слова, модели памяти, bit & byte endianess

Фигассе у вас архитектуры - bit endianness o_O

> или для тебя gcc + x86 = наше все?!

Нет, еще PowerPC :) А gcc - таки да, наше всё :D

Термин:
Application Binary Interface (ABI)

Описание:
Бинарный интерфейс приложений. Спецификация, определяющая способ
доступа приложения к ресурсам _операционной системы_.
Обеспечивает переносимость откомпилированного приложения между системами с одинаковым ABI.

> Дай лучше ссылку на что-нибудь подобное например MISRA

http://www.misra.org.uk/misra-cpp.htm

вот тебе ссылка :) ничто не стоит на месте.

> способ доступа приложения к ресурсам _операционной системы_

а если у меня сейчас вообще ОС нетути, значит и ABI нема? хи-хи

а еще представь себе у идет поставка продукта в смешанном бинарном/source виде и без завязки на OS вообще (в смысле линкуется с любой OS удовлетворяющей определенному стандарту)!

и продукты такие делаются человеко-годы и стоят сотни килобаксов...

> Бинарный интерфейс приложений. Спецификация, определяющая способ доступа приложения к ресурсам _операционной системы_.

Понятие ABI традиционно относят и к библиотекам, особенно динамически загружаемым.

>http://www.misra.org.uk/misra-cpp.htm

>вот тебе ссылка :) ничто не стоит на месте.

гы-ы-ы, ты прочитал что там написано? (скажу тебе по секрету - все так примерно и останется лет десять)

> идет поставка продукта в смешанном бинарном/source виде и без завязки на OS вообще (в смысле линкуется с любой OS удовлетворяющей определенному стандарту)

О, конкретика пошла :) Да, типично для deeply embedded. Но тогда оно должно указывать свой ABI и компилятор, которые его поддерживает.

> а еще представь себе у идет поставка продукта в смешанном бинарном/source виде и без завязки на OS вообще

Это для сферическеского коня в вакууме чтоле? Проснись друк. Нет бинарей в native-code без завязки на OS. В таких случаях поставляют зоопарк либ свои под каждую OS, а если это венда, то еще и под каждую версию CRT

>Понятие ABI традиционно относят и к библиотекам, особенно динамически загружаемым.

А как же Calling-convention к системным вызовам, к примеру?

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

в том то и фишка, что С + стандарты + доп. средства позволяют от этого спастить.

ладно извини, уходить пора.

>Это для сферическеского коня в вакууме чтоле? Проснись друк. Нет бинарей в native-code без завязки на OS.

знаешь, тебя вроде бы тоже нет, и отвечать я тебе не буду ;-)

Вообще не пойму к чему все это пустословие про С++ АБИ? В С++ либах стабильность АБИ достигается применением паттерна PImpl и запрета на добавление виртуальных функций в существующие классы. Все остальные требования такие же как и для С.

З.Ы. Это применимо только к динамическим либам. Для статических либ проблем с АБИ не существует т.к. при новой версии либы прога все равно перекомпилируецца.

Да это просто жёсткие проприетарщики жалуются, что их говнобинарники, скомпиленные со случайными опциями в MSVC не работают под линуксом :)

>> Понятие ABI традиционно относят и к библиотекам, особенно динамически загружаемым.

> А как же Calling-convention к системным вызовам

Это тоже (я же так и сказал :))

> Для статических либ проблем с АБИ не существует т.к. при новой версии либы прога все равно перекомпилируецца.

Если доступны исходники. Если нет, то спасет только стандарт ABI

все ближе и ближе к любимой Жаве :))))

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

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

читал, и что? 10 лет назад и MISRA-C не было (9 т.е.) MISRA Guidelines появилось в 94-ом году.

>MISRA-C:2004 is based on the C language as defined by ISO 9899:1990 (plus corrigenda). C99 has not been considered in MISRA-C:2004 due to the limited support for C99 on embedded microprocessors.

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

тонны самого разнообразного кода проходят сертификацию по DO-178B. и ничего, как-то обходятся там без и без мисры, и без embedded C++, который тоже кастрирован по самое не балуй.

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

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

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

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

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

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