И тратит при этом процессорное время на пресловутые nop-ы.

Сделайте, пожалуйста, задержку на 1-15 драгоценных тактов используя их на что-то полезное.

А зачем?
Если такая потребность возникает, то что-то не так с Вашей схемотехникой.

Ну возьмём, скажем, дисплей какой-нибудь на HD44780 или на KS0108 и подключим к какому-нибудь Cortex-у, работающему на 30 МГц. Контроллер ногами махает несколько быстрее, чем дисплею нужно.

А что? I²C индикаторы запрещены к применению?
Или отменили MK с аппаратным параллельным портом?

Да хоть на 700мГц, это не означает, что нужно ждать пока дисплей отработает, нужно в реальном времени работать и ценить каждый такт процессора.

Причём тут схемотехника? Ситуации разные бывают. Применён дешёвый МК без контроллера внешней шины, скорости хватает за глаза, зато дешёвый и с задачей справляется.


Это в теории. А на практике никуда не денетесь при работе с медленной периферией. Даже есть есть аппаратный контроллер внешней шины, то придётся ему wait state'ы настроить, чтобы времянки соблюсти, и при обращении к медленному устройству проц будет все равно ждать, если только обращение не через DMA организовано. DMA тоже есть далеко не везде.

Т.ч. вставка пары-тройки пустых операций иногда бывает нужна. И предложено очень красивое и эффективное решение.

Вот же заносит вас - речь вообще не о препроцессоре С, никакого определяющего значения в выборе языка для меня лично он не имеет, меня попросили привести пример где С++ уступает С. В ассемблерах препроцессор зарулит в этом плане С и С++. В повседневных задачах макросы используются в основном для именованых констант, условной компиляции и отладочных сообщений. Если говорить про UNIX то тут традиционно с препроцессингом нет проблем, достаточно вспомнить про lex, yacc, sed, awk, m4, по сравнению с которыми все темплейты С++ просто детский лепет, но использовать их в повседневных задачах - как из пушки по воробьям.

Сообщение отредактировал sasamy - Dec 26 2011, 06:22

Вот же заносит вас
Пример-то когда будете приводить? Или опять стрелки на макросы кинете, которые в обоих языках идентичны.

Закончил уже с вами дискутировать на тему С++ по понятным причинам, которые внятно изложил XVR, но напоследок отвечу. sed и awk - чтоб вам ими всю жизнь пользоваться. А по мне так - фтопку их. Для этого у меня есть Python. И уж для какой-то незаурядной кодогенерации я поюзаю COG, который в отличие от ваших недоделанных препроцессоров генерирует явный код прямо в сорце, т.е. видно, что скармливается компилятору. При этом и кодогенерирующие конструкции написаны на нормальном ЯП высокого уровня (куда выше, нежели тот же С++), а не на долбанных подстановках. Излишне говорить, что Python по юзабилити и эффективности использования ни в какое сравнение не идёт с вашим списком утилит. Но даже он не заменяет С++ шаблоны.

P.S. Помнится, как-то работая с IAR'овским пакетом (то ли для MSP430, то ли для AVR), завёл внутри функции локальный объект N (или С), после чего конкретно попрыгал вокруг этой простейшей функции, получая маловразумительные сообщения компилятора, которые никак не коррелировали с выражениями, на которые он ссылался. Нашёл, в чём дело. Оказалось, что именитая фирма в заголовках не стесняется лепить макросы:



Что сказать? Пять баллов! Кстати, оно и до сих пор у них так. Вот оно могущество препроцессора. В создании геморроя на пустом месте.

То что не умеете пользоваться sed и awk понятно, а Python и у меня есть.

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

Смотря что вы называете "птичьим языком" - принцип регулярных выражений един для всех языков, включая sed, awk и Pythonb, у awk С-подобный синтиаксис. Никто для "сочинения кода" sed и awk не использует - когда то им на замену был придуман Perl, сегодня наверно целесообразней применять Python - тут на любителя, но sed и awk в повседневном использовании в UNIX-подобных системах они никогда не заменят, факт - find, sed, awk пожалуй самые использумые команды в юниксах.



Хамить вам я и не собирался - ткните пальцем если найдете, я извинюсь если был не прав, если вы о том что не умеете пользоваться sed и awk - извините конечно, вы наверно пользователь Windows и лишены таких инструментов По поводу препроцессинга и шаблонов - шаблоны в С++ мощней препроцессора С хотя бы потому что оптимизируются компилятором (и вообще о том что нужны ли шаблоны в С++ - нужны и вряд ли их там что-то может заменить), в С мне шаблоны не нужны - достаточно препроцессора, и некоторые вещи из того что он умеет на шаблонах не сделать или это будет очень затруднительно. Еще по поводу препроцессинга и метапрограммирования - из того чем последнее время интересовался :
Qt - moc + препроцессор С
L4 - препроцессинг на Perl
так что механизма шаблонов С++ для _крупных_ проектов многим явно недостаточно.
По поводу UI и удобства ООП - посмотрите совремненные тенденции, в том же Qt активно развивается QML - описание интерфейса в декларативном стиле, логика на JavaScript подобном языке - знания С++ для написания GUI вообще не требуется, хотя сама Qt написана на С++.
По поводу системного программирования и С++ - ядро Windows до сих пор пишут на С (это по вашему крупный или мелкий проект)

Все можно выдыхать

Сообщение отредактировал sasamy - Dec 27 2011, 12:57

Кстати. То, что sed,awk и perl очень полезные и могучие языки, ни коим образом не прибавляет им понятности
Злые языки утверждают, что название awk произошло от awkward (неуклюжий), а perl расшифровывается как Pathologically Eclectic Rubbish Lister (это кстати определение от Larry Wall - автора Perl'а)
Разумеется. В С++ из шаблонов уже выжали столько, сколько Bjarne Stroustrup'у и в кошмарном сне не виделось

sed'ом и awk успел попользоваться изрядно, хоть и под вендой. Хорошие штуки, когда надо обрабатывать единичные строки. Как только нужно многострочный текст обработать, начинаются пляски. Как познакомился с Python'ом, так не нарадуюсь до сих пор. Те же регулярные выражения в полный рост, но использование не в пример проще и прозрачнее Для кодогенерации есть хороший инструмент COG (ссылку приводил).

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

Ладно, давно не топик уже.