[syv 0]

Вы про шаблон Nops? Очень простое, эффективное, красивое и безопасное решение. Не понимаю, что вы там смогли усмотреть плохого. Компилятор на этапе компиляции рекурсивно разворачивает цикл, генерируя столько нопов подряд, сколько указано.

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

 

[neiver 0]

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

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

[syv 0]

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

А зачем?

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

 

[neiver 0]

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

[syv 0]

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

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

Или отменили MK с аппаратным параллельным портом?

 

[khlenar 5]

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

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

[dxp 64]

А зачем?

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

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

 

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

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

 

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

[sasamy 0]

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

 

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

Изменено 26 декабря, 2011 пользователем sasamy

[Flexz 0]

Вот же заносит вас :)

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

[dxp 64]

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

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

 

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

 

#define C                   (0x0001)
#define Z                   (0x0002)
#define N                   (0x0004)
#define V                   (0x0100)

 

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

[sasamy 0]

А по мне так - фтопку их. Для этого у меня есть Python.

 

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

 

[dxp 64]

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

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

[sasamy 0]

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

 

Смотря что вы называете "птичьим языком" - принцип регулярных выражений един для всех языков, включая 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 до сих пор пишут на С (это по вашему крупный или мелкий проект)

 

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

Изменено 27 декабря, 2011 пользователем sasamy

[xvr 12]

Кстати. То, что sed,awk и perl очень полезные и могучие языки, ни коим образом не прибавляет им понятности :)

Злые языки утверждают, что название awk произошло от awkward (неуклюжий), а perl расшифровывается как Pathologically Eclectic Rubbish Lister (это кстати определение от Larry Wall - автора Perl'а)

так что механизма шаблонов С++ для _крупных_ проектов многим явно недостаточно.

Разумеется. В С++ из шаблонов уже выжали столько, сколько Bjarne Stroustrup'у и в кошмарном сне не виделось :)

 

[dxp 64]

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

 

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

 

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