Имеется проект под встроенную realtime ОС, содержащий смесь C и C++ файлов. Его необходимо "причесать" для дальнейшего усовершенствования. Коллега, программист на asm и C, задает вопросы:
1.Надо бы перевести проект на "плюса", да только надо ли? Есть ли и в чем преимущество "плюсов" в контексте поставленной задачи? С другой стороны, когда к проекту подключатся другие разработчики(C++), это потребуется все-равно.
2.Он считает, что быстродействие C-программы лучше, чем C++. Так ли это?
3.Есть ли вообще преимущество C++ в задачах такого класса, где требуется максимальная скорость и по-возможности экономия ресурсов?(вопрос ставился именно так — "зачем C++, если есть C?".

В проекте глобально решается 3 типа задач:
-первоначальная инициализация "железа", записать-считать регистр
-взаимодействие с внешним миром — задачи ip-stack, snmp,и.т.д.
-взаимодействие между блоками и внутри блоков в оборудовании

Для программиста C++ структурированная работа с использованием классов C++ — привычна и логична. Но как объяснить это C-программисту? И прав ли он, что C-программы быстрее? (размер программы и памяти не критичны). Для него работы через подпрограммы удобнее и проще, чем через методы классов.
А может быть в данном случае программа на C действительно будет более эффективна? В другом имеющемся у нас C++ проекте реально от возможностей C++ используется очень мало....

Пока был принят один аргумент:
1.перегрузка функций. Вместо набора функций write_byte(addr, data), write_word(addr, data), write_dword(addr, data) используется одна перегруженная функция write_data(addr, data).

Что можно добавить еще??????

Здравствуйте, Motoroller, Вы писали:

M>1.Надо бы перевести проект на "плюса", да только надо ли? Есть ли и в чем преимущество "плюсов" в контексте поставленной задачи? С другой стороны, когда к проекту подключатся другие разработчики(C++), это потребуется все-равно.

почему?

M>2.Он считает, что быстродействие C-программы лучше, чем C++. Так ли это?

абсолютно нет так.

M>3.Есть ли вообще преимущество C++ в задачах такого класса, где требуется максимальная скорость и по-возможности экономия ресурсов?(вопрос ставился именно так — "зачем C++, если есть C?".

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

M>Пока был принят один аргумент:
M>1.перегрузка функций. Вместо набора функций write_byte(addr, data), write_word(addr, data), write_dword(addr, data) используется одна перегруженная функция write_data(addr, data).

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

Здравствуйте, Motoroller, Вы писали:

M>Пока был принят один аргумент:
M>1.перегрузка функций. Вместо набора функций write_byte(addr, data), write_word(addr, data), write_dword(addr, data) используется одна перегруженная функция write_data(addr, data).

M>Что можно добавить еще??????

1. Исключения.
2. new вместо malloc и free.
3. Если не использовать классы, производительность такая же как и на С.

Здравствуйте, Motoroller, Вы писали:

M>Имеется проект под встроенную realtime ОС, содержащий смесь C и C++ файлов. Его необходимо "причесать" для дальнейшего усовершенствования. Коллега, программист на asm и C, задает вопросы:

M>1.Надо бы перевести проект на "плюса", да только надо ли? Есть ли и в чем преимущество "плюсов" в контексте поставленной задачи? С другой стороны, когда к проекту подключатся другие разработчики(C++), это потребуется все-равно.

Надо. C++ лучше контролирует типы, чем C, да и собирать проект на одном языке проще.

M>2.Он считает, что быстродействие C-программы лучше, чем C++. Так ли это?

Наоборот. В C даже inline функций нет а их эмуляция макросами порождает трудноуловимые ошибки.
Твой товарищь явно некомпетентен в вопросе.

M>3.Есть ли вообще преимущество C++ в задачах такого класса, где требуется максимальная скорость и по-возможности экономия ресурсов?(вопрос ставился именно так — "зачем C++, если есть C?".

Да. Разумеется язык надо правильно использовать.
Вообще, в наше время единственный разумный аргумент в использовании голого С -- отсутствие нормального С++ компилятора.

M>В проекте глобально решается 3 типа задач:
M>-первоначальная инициализация "железа", записать-считать регистр
M>-взаимодействие с внешним миром — задачи ip-stack, snmp,и.т.д.
M>-взаимодействие между блоками и внутри блоков в оборудовании

M>Для программиста C++ структурированная работа с использованием классов C++ — привычна и логична. Но как объяснить это C-программисту? И прав ли он, что C-программы быстрее? (размер программы и памяти не критичны). Для него работы через подпрограммы удобнее и проще, чем через методы классов.

А что мешает использовать С++ в процедурном стиле?
Кроме того, анализ С программ очень часто выявляет, то что С код вручную эмулирует и классы, и наследование, и виртуальные функции, а эмуляция шаблонов достигается через copy-past.
Посмотри на библиотеку stdio, например. Типичная симуляция объектно-ориентированого подхода на С.
Посмотри на API Win32 или на API своей RTOS. Тоже самое -- симуляция классов средствами C.

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Ubivetz, Вы писали:

U>Здравствуйте, Motoroller, Вы писали:

M>>Пока был принят один аргумент:
M>>1.перегрузка функций. Вместо набора функций write_byte(addr, data), write_word(addr, data), write_dword(addr, data) используется одна перегруженная функция write_data(addr, data).

M>>Что можно добавить еще??????

U>3. Если не использовать классы, производительность такая же как и на С.

Это Вы о полиморфных классах, надеюсь? Обычные классы никакой потери в производительности не несут.

Здравствуйте, Анатолий Широков, Вы писали:

АШ>Это Вы о полиморфных классах, надеюсь? Обычные классы никакой потери в производительности не несут.

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

Одна из причин почему С++ не надо использовать — это
если на данной платформе нету качественного компилятора.
Все остальные причины довольно сомнительны...

Здравствуйте, Motoroller, Вы писали:

M>Имеется проект под встроенную realtime ОС, содержащий смесь C и C++ файлов. Его необходимо "причесать" для дальнейшего усовершенствования. Коллега, программист на asm и C, задает вопросы:
M>1.Надо бы перевести проект на "плюса", да только надо ли? Есть ли и в чем преимущество "плюсов" в контексте поставленной задачи? С другой стороны, когда к проекту подключатся другие разработчики(C++), это потребуется все-равно.

Во встроенных системах C++ используют довольно редко. Вот основные причины на мой взгляд:
— С++ в разы сложнее
— разработчики на С++ дороже стоят
— в качестве программистов нередко выступают электронщики, которые не смогут программировать на С++ (точнее смогут, но лучше бы вообще не могли)
— для оптимизации потребуется использовать такие тонкости С++-а как аллокаторы и т.п. вещи. Да и вообще надо очень хорошо знать С++ для того чтобы писать быстрые программы
— не на всех РТОС есть компилятор С++ (даже есть есть компилятор, то не факт что дебагер/профайлер понимает С++)
— С быстрее и программы на С проще оптимизируются
— для С++ -а нужно таскать за собой толстые библиотеки stdc++ и т.д. Которые по сути лишь красивая обертка к libc или newlib.
— асемблерные вставки в С++ коде смотрятся как .. ээээ короче плакать после такого хочется. А без них никак.
— объекты, объекты а в РТ без функций не обойтись (регистрация сигналов, спуллинг и т.д.). Неизбежен смешанный стиль программирования и опять таки страшный С++ код.

В РТ приложениях вся сложность в системном слое ПО и тонкостях железа, а потому не стоит добавлять еще одну сложность. Да и вообще С++ нужен если предметная область довольно сложна и ее можно красиво отобразить на объекты. Там он реально помогает.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Анатолий Широков, Вы писали:

АШ>>Это Вы о полиморфных классах, надеюсь? Обычные классы никакой потери в производительности не несут.

А>А что с полиморфными классами не так?
А>Эмулировать их на С (если конечно задача этого требует)
А>не будет ни надежнее, ни быстрее, чем это сделает C++ компилятор.

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

Здравствуйте, dimon0981, Вы писали:

D>- для оптимизации потребуется использовать такие тонкости С++-а как аллокаторы и т.п. вещи. Да и вообще надо очень хорошо знать С++ для того чтобы писать быстрые программы
Прошу объяснить на пальцах как помогут аллокаторы в оптимизации проги написанной в процедурном стиле? А так же очень хорошее знание С++ опять таки для процедурного программирования? Когда используется в основном С и чуть чуть простых ништяков из С++
ЗЫ. А для встроенных систем для написания быстрых программ надо хорошо знать архитектуру системы.

D>- С быстрее и программы на С проще оптимизируются
Бездоказательно.
D>- асемблерные вставки в С++ коде смотрятся как .. ээээ короче плакать после такого хочется. А без них никак.
Нормально ИМХО смотрятся.

Ш>Наоборот. В C даже inline функций нет а их эмуляция макросами порождает трудноуловимые ошибки.
inline там есть.

Здравствуйте, Lorenzo_LAMAS, Вы писали:

Ш>>Наоборот. В C даже inline функций нет а их эмуляция макросами порождает трудноуловимые ошибки.
L_L>inline там есть.

Не знал, это расширение или стандартная фича?

АШ>Не знал, это расширение или стандартная фича?

Стандартная.

Здравствуйте, Lorenzo_LAMAS, Вы писали:


АШ>>Не знал, это расширение или стандартная фича?

L_L>Стандартная.

В С99. До этого -- только как расширения компилятора...

BF>В С99. До этого -- только как расширения компилятора...
Так C99 это не диалект С, это стандартный С. Так что не обязательно, ИМХО, уточнять, что в С99. В каком-то там С и присваивания структур не было, это ж никому не интересно.

Здравствуйте, Lorenzo_LAMAS, Вы писали:

BF>>В С99. До этого -- только как расширения компилятора...
L_L>Так C99 это не диалект С, это стандартный С. Так что не обязательно, ИМХО, уточнять, что в С99. В каком-то там С и присваивания структур не было, это ж никому не интересно.
Не обязятельно, но, ИМХО, желательно. Под целевую платформу может не быть компилятора с поддержкой С99, только С89.

Здравствуйте, Lorenzo_LAMAS, Вы писали:

Ш>>Наоборот. В C даже inline функций нет а их эмуляция макросами порождает трудноуловимые ошибки.
L_L>inline там есть.

Только в С99. Прикол в том, что С99 до сих пор не вытеснил предыдущий.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, dimon0981, Вы писали:

D>>- для оптимизации потребуется использовать такие тонкости С++-а как аллокаторы и т.п. вещи. Да и вообще надо очень хорошо знать С++ для того чтобы писать быстрые программы
CC>Прошу объяснить на пальцах как помогут аллокаторы в оптимизации проги написанной в процедурном стиле? А так же очень хорошее знание С++ опять таки для процедурного программирования? Когда используется в основном С и чуть чуть простых ништяков из С++
CC>ЗЫ. А для встроенных систем для написания быстрых программ надо хорошо знать архитектуру системы.

Если стиль процедурный то зачем браться за С++? Хорошее знание все равно потребуется, например очень желательно знать как реализованны std::string и другие контейнеры, как вызоваются виртуальные функции и т.д.

D>>- С быстрее и программы на С проще оптимизируются
CC>Бездоказательно.
Использование тех же string-ов вместо char[] приводит к массе лишних операций. Исключения "отжирают" ресурсы. Если Вы не пользуйтесь исключениями, то ими пользуются стандартные контейнеры.

D>>- асемблерные вставки в С++ коде смотрятся как .. ээээ короче плакать после такого хочется. А без них никак.
CC> Нормально ИМХО смотрятся.

Вставки в стиле gcc имеют смысл только для интегральных типов:
asm( "CODE", prm1, prm2, prm3 );
где prm — описывают входные, выходные и измененные параметры
Если вы работайте с объектами, то придется все приводить к этим типам.
Если в С асм-овые вставки можно не заморачиваясь встраивать куда угодно, то в С++ надо сначала думать. Пока на все грабли не наступишь будешь рвать волосы.
Рыться в стеке перед вызовом вертуальных ф-ии опасно. Кто знает что туда положит компилятор, это в Си все эти тонкости в стандарте описанны, в С++ — нет. После вызова ф-ии анологично.

Здравствуйте, dimon0981, Вы писали:

D>>>- для оптимизации потребуется использовать такие тонкости С++-а как аллокаторы и т.п. вещи. Да и вообще надо очень хорошо знать С++ для того чтобы писать быстрые программы
CC>>Прошу объяснить на пальцах как помогут аллокаторы в оптимизации проги написанной в процедурном стиле? А так же очень хорошее знание С++ опять таки для процедурного программирования? Когда используется в основном С и чуть чуть простых ништяков из С++
CC>>ЗЫ. А для встроенных систем для написания быстрых программ надо хорошо знать архитектуру системы.
D> Если стиль процедурный то зачем браться за С++? Хорошее знание все равно потребуется, например очень желательно знать как реализованны std::string и другие контейнеры, как вызоваются виртуальные функции и т.д.
С++ на STL клином не сошелся. Совсем не обязательно если уж используется С++ то сразу все писать на STL контейнерах и.т.п.

D>>>- С быстрее и программы на С проще оптимизируются
CC>>Бездоказательно.
D>Использование тех же string-ов вместо char[] приводит к массе лишних операций. Исключения "отжирают" ресурсы. Если Вы не пользуйтесь исключениями, то ими пользуются стандартные контейнеры.
Никто не заставляет пользовать string и исключения. STL это всего лишь набор темплейтов — хочу пользуюсь, хочу — нет. Это просто еще одна библиотека. И к ней следует точно так же присматриваться как и к другим кандидатам на использование при написании кода для встраиваемых систем. Если она не подходит по своим характеристикам то ничто не мешает от нее отказаться и написать свою. Да и ничто не мешает использовать с С++ проге char[] вместо string.
Или для вас писать на С++ это только STL, Boost, дикие классы с хитрыми наследованиями и боже упаси вызвать sprintf хоть раз.

D>>>- асемблерные вставки в С++ коде смотрятся как .. ээээ короче плакать после такого хочется. А без них никак.
CC>> Нормально ИМХО смотрятся.

D>Вставки в стиле gcc имеют смысл только для интегральных типов:
D>asm( "CODE", prm1, prm2, prm3 );
D>где prm — описывают входные, выходные и измененные параметры
D>Если вы работайте с объектами, то придется все приводить к этим типам.
D>Если в С асм-овые вставки можно не заморачиваясь встраивать куда угодно, то в С++ надо сначала думать. Пока на все грабли не наступишь будешь рвать волосы.
Ну, положим, думать надо всегда, а не только при программировании на С++.
D>Рыться в стеке перед вызовом вертуальных ф-ии опасно. Кто знает что туда положит компилятор, это в Си все эти тонкости в стандарте описанны, в С++ — нет. После вызова ф-ии анологично.
а зачем там рыться? Если делать асм вставки так делать с умом, там где есть резон и без фанатизма.

BitField wrote:
>
> BF>>В С99. До этого -- только как расширения компилятора...
> L_L>Так C99 это не диалект С, это стандартный С. Так что не обязательно,
> ИМХО, уточнять, что в С99. В каком-то там С и присваивания структур не
> было, это ж никому не интересно.
> Не обязятельно, но, ИМХО, желательно. Под целевую платформу может не
> быть компилятора с поддержкой С99, только С89.
Пример, MS VC.

Здравствуйте, dimon0981, Вы писали:

D> Если стиль процедурный то зачем браться за С++?

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

2. Шаблоны. Шаблонные классы и функции позволяют избавиться от copy-paste. Кроме того, шаблоны инлайнятся и хороший оптимизатор может сгенерировать из шаблонов более быстрый код, чем на основе обычных C-шных процедур.

3. Классы, не полиморфные. Наследование используется для агрегирования данных и/или функциональности (т.е. классы как mixin-ы). Так же позволяет избавиться от не нужного copy-paste.

4. Конструкторы и деструкторы для организации RAII.

5. Пространства имен. Чтобы избавиться от функций с длинными префиксами в именах.

6. Перегрузка функций и операторов (вроде оперетора <<). Об этом здесь уже сказали.

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