[_Pasha 0]

А что это вот такое:

C++-code requires significant additional costs on verification staff

 

Какой смысл стоит за этой фразой? У меня вариант такой: "У нас нет специалистов достаточной квалификации, способных понимать и сопровождать С++ код, поэтому пишите на С".

 

Они под MISRA сидят, вероятно. Это ужасно, но, говорят, что надёжно.

[dxp 34]

Они под MISRA сидят, вероятно. Это ужасно, но, говорят, что надёжно.

Конечно, надёжно, когда самые могучие возможности С, такие как, например, адресная арифметика, запрещены. Ещё надёжнее вообще не писать код. У меня друг работал 8 лет в крупной успешной телекоммуникационной чешской компании, подробно рассказывал про тамошние дела. Действительно, доходило до того, что отдельным подразделениям, преимущественном состоящим из местных чехов, корпоративно запрещали, например, использовать STL, т.к. использовалось это без должного понимания, что приводило к ужасному неработоспособному, несопровождаемому коду. Но те в массе только рады были. DSP группе, где он работал, не запрещали. :)

 

MISRA - привязать себя к стулу, чтобы не упасть. Но в один прекрасный момент упасть вместе с ним. Это весьма больнее.

[halfdoom 0]

Какой смысл стоит за этой фразой?

 

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

[dxp 34]

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

Спасибо, интересно.

 

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

Ну, почти та же история, что и в той чешской компании. Разница только в том, что там подошли дифференцировано - у кого получается, тем разрешили. Точнее не так - у кого не получается, тем запретили. Уже когда-то говорил, повторю - у С++ есть только один серьёзный объективный недостаток - этот язык сложный.

[mikeT 0]

Заинтересовало упоминание языка Ада в задачах, где требуется надежность и т.д. В свое время читал "общеразвивающую" инфу про то, что этот язык был специально создан по заказу МО США именно для сложных, высоконадежных систем, например, для ПО на каких-нибудь крылатых ракетах, истребителях...

 

Полез сейчас в инет посмотреть (ради любопытства) "а на чем написано ПО для А-380, F-35?" Нашел инфу про F-35, про А-380 искать пока лень.

 

Но насчет ПО для F-35 я был несколько удивлен, хотя и ожидал чего-то подобного. Если коротко, то на С++. Один из слайдов документа (ссылка ниже) содержит фотографию Joint Strike Fighter (F-35 Lightning II) и ниже подпись со стрелочкой, указывающей на самолет, "C++ inside".

 

SafetyCriticalC++Presentation.pdf

 

На других ресурсах по этой же теме (софт для F-35) приводятся данные что первоначально там была "солянка" из Ады, С, С++, ассемблера, но потом было решено все 100% кода перевести на С++.

 

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

 

[halfdoom 0]

SafetyCriticalC++Presentation.pdf

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

Ничего нового, очередная демонстрация известных проблем обоих языков и костылей для их решения. Правда, что имел в виду автор под фразой "C is insufficiently specified" остается загадкой.

 

Они под MISRA сидят, вероятно.

Нет, MISRA ни разу не упоминалась. По данным контрразведки еще одна российская фирма и поляки претендуют на этот контракт, если здесь кто есть из них, может дополнят (hint: директор той фирмы весьма колоритный ирландец).

[SSerge 4]

и ниже подпись со стрелочкой, указывающей на самолет, "C++ inside".

Это покруче будет:

По теме.

Если у программера в голове кю вместо мозгов - ни MISRA, ни ADA не поможет, всё равно не полетит.

[Marto 0]

А что именно? Мне кроме исключений (которые можно отключить при компиляции) ничего в голову не приходит...

 

 

RTTI - даже на декстопе забавная штука:)

 

[haker_fox 60]

Почему у Вас new/delete потянули дополнительные 260 килобайт, ума не приложу.

А вот и я не знаю... но стоит убрать эти операторы, как код становится 40 кБ...

 

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

 

З.Ы. Компилятор у меня Code Sourcery...

 

[sasamy 9]

Сегодня С++ - мэйнстрим в embedded, это факт.

 

Смотря что называть в embedded мэйнстрим - в вашем понимании - возможно, про это я уже намекал, в моем - нет :)

http://techcrunch.com/2012/09/05/eric-schm...ations-per-day/

и С++ в ядре Linux нет и не будет, потому что он там не нужен, а для middleware основной язык Java (хотя надо признать С++ там тоже есть) . Есть проекты которые переходят с С на С++ - например GCC начал миграцию, но это либо далеко не embedded мэйнстрим или далеко не такие значимые проекты чтобы называть их мэйнстримом.

 

PS и телеком тоже понятие растяжимое

http://www.rsdn.ru/article/erlang/GettingS...dWithErlang.xml

Изменено 9 сентября, 2012 пользователем sasamy

[alx2 0]

А вот и я не знаю... но стоит убрать эти операторы, как код становится 40 кБ...

Но Вы-то, в отличие от нас, узнать это можете - достаточно заглянуть в map-файл...

Вы, надеюсь, использовали nothrow-версию оператора new?

А вот с такими реализациями:

void * operator new(size_t n) throw() { return malloc(n); }
void operator delete(void *p) { free(p); }

тоже тянет 260 кбайт?

 

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

К языку программирования это не имеет никакого отношения. Язык C++ позволяет использовать любой менеджер памяти (включая использование нескольких менеджеров одновременно - для разных объектов разных). Свой менеджер памяти может потребоваться писать по тысяче разных причин - это зависит от решаемой задачи. И необходимость писать свой менеджер не означает, что все прочие существующие менеджеры плохи. Это всего лишь означает, что они не подходят для данной конкретной задачи. При этом для другой задачи какой-то из них может подойти гораздо лучше, чем "выдуманный" Вами. Но это совсем другая тема - не о языках программирования...

[andrewlekar 0]

Ada, насколько я знаю, очень хороший язык.

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

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

[haker_fox 60]

Но Вы-то, в отличие от нас, узнать это можете - достаточно заглянуть в map-файл...

Вы, надеюсь, использовали nothrow-версию оператора new?

Я не знаю :crying:

Использовал так

int* p = new int[ 1000 ];

А вот с такими реализациями:

void * operator new(size_t n) throw() { return malloc(n); }
void operator delete(void *p) { free(p); }

тоже тянет 260 кбайт?

Попробую...

Но Вы-то, в отличие от нас, узнать это можете - достаточно заглянуть в map-файл...

Вы, надеюсь, использовали nothrow-версию оператора new?

Честно говоря, никогда не пользовался map-файлом... видимо пришло время)

 

Спасибо!

[haker_fox 60]

В общем new (std::nothrow) объем кода не уменьшает...(((

[Артём__ 0]

В общем new (std::nothrow) объем кода не уменьшает...(((

 

haker_fox, а какие у вас объёмы получаются?

Почему бы не сравнить свои исходники/либы/скрипты с вариантами которые не генерят большой код.