Уважаемые господа.
Интересует ваше мнение относительно целесообразности конвертации С++ в С при разработке проектов реального времени. Я имею ввиду следующее: входной текст программы разработан на С++ с использованием ООП по полной программе (классы, виртуальные функции и т.д.). Эту программу монтируем на конкретную платформу DSP. Много ли я выиграю по скорости выполнения, если перепишу эту программу с С++ в С?
Также прошу сбросить все ссылки по проблеме конвертации С++ в С. Спасибо...

Если С++ использовался только ради создания иерархии классов (т.е. использования достоинств ООП - наследования и полиморфизма), то можно свои классы оставить, а все остальное делать С-шное. Т.е. никаких там STL и всего такого.

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

насчёт целесообразности... не могу сказать.

насчёт STL... теоретически: будет ли STL помехой? почему?

Автоматическое преобразование, IMHO, не рационально. Это не даст выигрыша, а только лишит программу наглядности, присущей ООП. Если и переводить, то только руками. Либо автоматически с последующей оптимизацией.

Устранение классов из программы может поднять ее быстродействие
тк снимется лишний уровень косвенности - обращение через this->
к переменным класса и вызов виртуальных методов.
Однако вообще не использовать классы - излишне, ведь обычно
лишь 5% кода выполняется 95% времени. Ну, или 20% и 80%.
Вот их-то и имеет смысл оптимизировать.

Цитата

Устранение классов из программы может поднять ее быстродействие тк снимется лишний уровень косвенности - обращение через this-> к переменным класса и вызов виртуальных методов.

А разве транслятор, генерируя выходной ассемблерный код, сразу не снимает этот уровень косвенности, заменяя конкретными адресами?

Цитата

Если С++ использовался только ради создания иерархии классов (т.е. использования достоинств ООП - наследования и полиморфизма)

Одно из достоинств С++ - это наличие виртуальных функций, значит если осталять подобные механизмы, выходной ассемблерный код будет работать с таблицами адресов этих виртуальных функции, что непременно ведёт к неоптимальности по памяти и к косвенной адресации в выходном ассемблерном коде...

Цитата

насчёт STL... теоретически: будет ли STL помехой? почему?

Выходной код монтируется на спец. платформу, так что использование STL будет крайне избыточно.

Какая ещё STL? Здесь C++ не подходит, а Вы про STL. Эта библиотека полностью обстрагирована. А val хочет оптимизировать код на уровне asm'а. Тут STL вообще запрещено использовать.

Даже если использовать ООП при программировании на ассемблере, код все равно получится неоптимальным, это происходит потому, что программист при написании основной программы абстрагируется от низкого уровня, что моментально приводит к потери производительности. Неважно, на чем писалась программа (asm,C,C++), важно как она писалась.
Простое переписывание C -> C++ не даст выигрыша потому, что при этом надо будет реализовать все использованные возможности C++ средствами C (а переплюнуть создателей компилятора вряд ли получится).

Цитата

Одно из достоинств С++ - это наличие виртуальных функций, значит если осталять подобные механизмы, выходной ассемблерный код будет работать с таблицами адресов этих виртуальных функции, что непременно ведёт к неоптимальности по памяти и к косвенной адресации в выходном ассемблерном коде...

немного посчитаем:
вызов виртуальной функции:
1. взять адрес VMT
2. увеличить его соответственно номеру функции в ней
3. взять адрес функции
4. добавить в список параметров адрес экземпляра класса
На каждом процессоре это будет занимать разное время, но порядок будет не очень различаться. Теперь нужно просто избавиться от функций, длительность выполнения которых сравнима с этим временем. Примером таких функий может служить операция взятия значения координаты вектора (если алгоритм отлажен, можно не проверять на выход за границы). А функции, которые требуют серьезных вычислений можно и не трогать (по сравнению с ними вышеописанная последовательность вызова почти ни на что не влияет)

>А разве транслятор, генерируя выходной ассемблерный код, сразу не
>снимает этот уровень косвенности, заменяя конкретными адресами?

Нет. Во всяком случае, BC 3.1 и BCB5.
Максимум, что они делают в этом смысле - могут иногда прокешировать
(подержать в регистрах) переменную класса.