А зря не верится. И я тоже не верил. Более того, когда писал на асме вообще не использовал данные команды. Считал их бесполезными. Оно и понятно. Применение команд типа LDD где используется смещение делает прогу на асме фактически нечитаемой. К чему обращаешься - непонятно. Другое дело компилятор. Ему на читаемость результирующего листинга асм - наплевать. Он даже мнемонические имена в константы рубит. Зато автоматически расчитывает смещение.

Не смею утверждать, но по моему он даже делает анализ совместного применения переменных и размещает их рядом в памяти. Чтобы удобнее было.

Во всяком случае применение команд LDD и STD очень широкое.

С++ на С не переносится в принципе, т.к. С является подмножеством С++ (хотя и не 100% совместимым). А вот С-код на С++ переносится достаточно легко, в некоторых случаях даже делать ничего не надо, он сразу работает. И по эффективности тут никаких потерь нет. Попробуйте какую-нибудь С программу, написанную под IAR С скомпилить тем же IAR'ом в С++ режиме. Сравните результат.


Это вы про С с классами говорите, который компилировался С front. Ну, так это еще не полноценный С++, а его предтеча. Давайте уже оперировать реалиями сегодняшнего дня.


Ну, это как писать. Сделайте смещения именованными и все сразу станет понятно. Когда-то, когда я в целях тренировки кое-что еще писал на асм для AVR, делал так (писано было еще в 1998 году, пакет - незабвенный IAR 1.40 ):



и т.д. Как видите, все вполне читаемо и понятно. Код оптимален. По сути тут руками сделана оптимизация Clustering variables.

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

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

А вот C++ - штука двоякая, главное достоинство - чуть меньше писанины, но есть и подводные камни. Например, в связи с ограниченностью количества индексных регистров возможно код с классами будет хуже - из-за неявного this, занимающего пару регистров.

Писанины поменьше - это не главное.
А главное, на мой взгляд, следующее:
- наращивание проекта при нормальном наследовании не ведет к его необозримости;
- все ошибки локализованы в объектах;
- простая корректировка.
С++ был создан для больших проектов. В С нужно в куче мест подправить, а в С++ в одном.

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

ключевое слово в моем посте - "возможно".

Хуже будет если, например, размер класса больше максимально допустимого смещения в команде индексной адресации. Или нужен лишний указатель. И еще можно придумать сто вариантов. Или будет также как и на чистом Си. Лучше - не будет. Следовательно - плюс цпп - только уменьшение писаниы.

Если у бабушки были бы усы и борода - она была бы дедушкой. (Народная мудрость).
А серьезно, все может быть.

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

Вы не внимательно читали мои посты, я говорил лишь о том что любую прогу
на С++ можно написать на С не менее эфективно(почти всегда более эфективно).
Правда, усилий может понадобится больше.
В конечном итоге это примерно такой же спор как насчет С vs ASM.
Очевидно что на ASM всегда можно написать лучше(быстрее/компактнее по коду) чем на С.
так же для меня вполне очевидно, что то же будет касаться С++ vs C.
Вопрос скорее в решаемой задаче и в количестве железных ресурсов которые
не жалко...
Ок, задам Вам такой вопрос:
как Вы относитесь к "прерываниям с классами" ?
Да, это действительно был Cfront в редакции AT&T кажись..., подзабылось уже...
Тока тогда он уже был С++ с практически всеми атрибутами современных версий,
по моему, исключений еще небыло в современном виде, а шаблоны уже были...
Вобщем здесь уже спорить не буду, не помню всех деталей...

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

Когда в 80x годах я взялся за C++, причем за именно ++, а не 'С', то с моей первой программой приключилась такая история - я выиграл спор . Потребовалась во времена IBM PC/XT для сугубо личных целей простенькая псевдографическая текстовая библиотечка. В общем ничего сверестественного открять окошко-(вывести текст) - еще несколько огошек, перекрытие, всплытие - все без особых затей. Ну и начал С++ изучать. Был у менгя парень, очень талантливый, уже несколько лет много пишущий на 'C' и виртуозно на ASM - он меня от плюсов отговаривал сильно, ну монстрально, тормознуто и т.д.... Я не отступал и он предложил мне доказать, написав библиотеку на 'C' и используя ее в одной и той-те тестовой программе убедиться в жуткой тормознутости C++. Причем в те времена 4,7 Mhz процессоров скорость прекрасно оченивалась невооруженным взглядом .
За несколько недель, вечерами-урывками почти за одинаковое время были написаны две библиотеки.
Напоминаю, это была моя первая программа! Моя C++ была меньше по размеру исходников, меньше по размеру кода и работала быстрее. Причем при этом я Турбодебагером не пользовался - ну просто некогда было изучать , да и само заработало, а коллега довольно плотно в отладке сидел. Случай, конечно, несколько вырожденный, ибо уж больно оконные задачи на плюсы хорошо легли... На самом деле обе работали очень медленно Пошли вставки на ASM, коллега уязвленный потратил массу времени на вылизывание сишного варианта, все находки были реализованы, листинги вычитаны... В конце-концов библиотека стала сишной с очень большими вкраплениями ASM. Но в принципе переход на C был обусловлен изрядной тупостью первого Борландячего плюсового компилятора. Уже в более поздние времена работая с Watcom явных претензий к реализации С++ не было. Да и Борланд попозже исправился, до того, что я стал старые Борландячие проекты (да и вообще все) компилить плюсовым компилятором - эффективнее получалось!

Вот с этим соглашусь практически полностью,
ну на 50% процентов как минимум,
нужно тока рассматривать это относительно существуещего железа,
С действительно уже практически заменил АСМ,
C++ Еще совсем нет. То есть его уже как бы вполне можно использовать, но тока
пока не в критичных по времени выполнения процедурах.
Повторюсь, Вы используете "Прерывания с классами"?

Я внимательно читал. И обратное утверждение верно.


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


Да. Хотя на практике случаи бывают и обратные.


См выше.


Что такое "прерывания с классами"?

Извините меня за тупость, но я что-то не понимаю.
Есть класс. Часть его функций используется не в прерываниях, часть в прерываниях. Я это применяю и проблем никогда не имею.
А что такое "прерывания с классами" я не могу понять (может что-то новенькое).

Может имелся в виду вызов методов класса из прерываний?

Лично у меня очень часто, иногда - даже виртуальные ...

Примерно это и имелось в виду.

А на каком проце вы вызываете виртуальные методы классов из прерывания ?

Видимо джиттер в Ваших задачах несущественен ?