Препроцессор С Тьюринг-неполный и только средствами препроцессора циклы и прочее задача нетривиальная (если вообще разрешимая). Но вот какая штука - UNIX написана программистами для программистов и тут это сделать элементарно.

rep_example.c





rep.sh



То что сгенерировалось в rep.h


..........
полностью думаю все 100 строк нет смысла писать

Когда сильно припекает - можно и на АСМ-е.
Но это бывает крайне редко. Практически никогда.
А мне приходилось в юности и на PDP-11 в кодах...
Но я никогда не провел бы прямой аналогии:
код->Асм->С->С++.
Пмсм, это выглядит вот так:
код
|
Асм->С
|
С++.

У меня нет автомобиля. Управлять я им не умею. Но аналогия понятна.
И отражает она лишь исключительно Ваш жизненный и профессиональный опыт.
Хоть мне и трудно - продолжу про автомобиль.
Автоматическая коробка передач. По Вашей методологии на всех автомобилях должна быть только такая.
Но это далеко не так. Даже на пафосных дорогих автомобилях есть оба варианта.
Почему?

Для начала - вовсе не критикую.
Подход как подход. Годится для большого количества программистов
В определенных ситуациях незаменим.
Сам пользуюсь на верхнем уровне при изготовлении HMI.
Но у него есть свои недостатки.
И не везде он годится.
Возвращаясь к Вашему примеру про ПЛК.
Все, что Вы описали - естественный процесс.
А то, что Вы делаете руками - искусство.
И повторить реальность - не выйдет.

Соглашусь - инструментами надо владеть.
Но и плодить лишние псевдосущности в виде не всегда нужных классов тоже не имеет смысла.

Беда в том, что я плотно знаком со всеми подходами.
Техническая сложность программирования ПЛК несоизмеримо Выше, чем МК.
Особенно, когда код состоит из сотен тысяч строк на один ПЛК.
А таких ПЛК в системе далеко не один.
И все это связано сетью.
Плюс к этому - верхний уровень и HMI глобального и локального уровня.

Ну Вы же далеко не сноб.
Зачем же принижать квалификацию профессионалов в той области, с которой Вы сталкиваетесь крайне редко?
То, что Вы изложили - дилетантизм, простите за резкость.
Я не буду ничего объяснять в этой ветке, поскольку она не о ПЛК.
Если кому интересно - могу изложить отдельно.

Это отдельная тема.
Только скажу одно - спроектировать ПЛК может любой выпускник ВУЗ-а. Для этого ничего не надо, кроме небольшого набора знаний, которые у него есть.
А вот сделать проект средней по сложности линии - вряд ли.
И это не голословное утверждение. Это многократно проверено на практике.

Угу, вместо 3 строк на С++ отдельный хидер и скрипт-генератор (для С). Да здравствует С и Unix!

Кстати, ваш пример с 10 nop'ами можно даже в С сделать компактно и без генератора:


Я не утверждаю, что в С++ препроцессор не нужен (я и сам его часто использую), я утверждаю, что в С++ очень часто (но не всегда!) без него можно обойтись.

PS. Что касается Линуса Торвальдса, то лично я с ним не знаком, но я знаком с его высказыванием на тему С++ (см например тут). Так же есть проект по написанию драйверов на С++ ( MOOL). Я не уверен, что Линус знает С++ в тонкостях, но если вам очень хочется это узнать, я могу у него спросить.

Что касается моих познаний в Linux'е, то я думаю, что загружаемый драйвер (в С и С++ версиях), который я написал, дает некоторую уверенность, что я немного в кернеле разбираюсь Очень древняя его С версия лежит тут

PPS. Зарекался я вам что либо писать, но не удержался ...

Да - согласен.



Кстати для особо одаренных - 1000 штук вы тоже будете вручную набивать ? речь помоему о кодогенерации.



То что вы написали говнокод на С++ влоб переписав кусок кода на С совершенно не разобравшись что он делает, при этом не поняли что это из ядра Linux, __setup - это стандартный макрос ядра и он в свою очередь тоже разворачивается в код, говорит что вы скорей всего знакомы поверхностно.
http://lxr.free-electrons.com/source/inclu...nux/init.h#L245
Вот что сгенерировал препроцессор. Причем код генерируется платформо-зависимый.





Не хотел ругать вас но вы сами таки напросились

Ну да, конечно, то то я смотрю, у нас на заводе повсюду ПЛК одних и тех же солидных фирм, а вот программы для них пишут все подряд, включая тех же недавних студентов.
А качество кода Вы оцениваете по его количеству, похоже - стопицот мильёнов строк - это крутизна, доступная только мегапрограммистам ПЛК?

Впрочем, есть и родной, разработанный на заводе ПЛК, который здорово уступает по надёжности импортным. Наверняка студентами разработан

Речь шла о том, что не надо приплетать кодогенерацию там, где она не нужна. Для 1000 штук добавится еще 7 строк. Тщатьельнее надо смотреть то, что вам пишут.
Абзац. Т.е. я должен был телепатически догадаться, что ваш макрос без начала и концы выдран из ядра Linux'а и сделать вам конфетку?
Про 'говнокод на С++' умолчим - он делает ровно то, что делает ваш макрос. И делает это гораздо лучше
Это говорит о том, что вы троль.

Т.е. вы считаете, что этот платформо-зависимый ужас лучше пары классов С++ ?

Да уж, напросился Диагноз: sasamy - троль необразованный

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



А вы сами внимательно прочитали ??



ы ?



Перешли на личности - доводы закончились

И в мыслях не было кого-либо принижать. Эти люди - профессионалы в своей области, никто не умаляет их знаний, опыта, квалификации и способностей. Но они специалисты в своих предметных прикладных областях, которые не программирование, поэтому логично, что в вопросах программирования у них подготовка уступает профессиональным программистам (в том числе embedded программистам). В этом нет ничего странного, постыдного и унизительного. Не понимаю, почему вы усмотрели тут наезд с моей стороны.

Насчёт ординарной способности любого выпускника ВУЗа спроектировать ПЛК комментировать не буду, дабы не провоцировать безплодную дискуссию и офтоп.

Доводы закончились уже давно По поводу 'необразованного троля' - беру свои слова обратно. Я посмотрел сообщения sasamy - весьма и весьма образованный специалист. Особенно в Linux (и ARM).

Но вот к сожалению, когда дело касается чего то вне пределов компетенции sasamy, тут образованность целиком заменяется упертостью, игнорированием чужих доводов и умелой подменой предмета спора в процессе спора. Т.е. просыпается классический тролль. Увы увы

Вы же сами сказали, что не писали на С++ ничего крупного, откуда же такая уверенность в превосходстве С (и макросов), если у вас по определению не может быть опыта в том, с чем вы пытаетесь сравнивать С ?

Если говорить о крупных проектах типа Qt или какой-нибуть EDA (тут на форуме кажется есть ребята которые участвуют в разработке ) - я даже встревать не стал бы С++ зарулит С и никакие макросы не спасут наверно если вы об этом, но речь вообще-то тут о микроконтоллерах. Только крупные проекты все больше на других языках начинают делать нежели на С++ - более безопасных и при этом простых.

Вы знаете, где это можно сделать безболезненно.
Я готов доказать Вам на реальных фактах, что Вы не совсем правы.



Дык, на С и С++ пишут тоже все подряд. И схемы разрабатывают. И Саяно-Шушенскую ГЭС эксплуатируют. Давеча вон Фобос-Грунт...
Что же касается кода, о котором я говорил, приходите - покажу.
Писали немцы - уважаемые и опытные люди.
Если сможете сделать лучше, даже денег дадут.
Только одно НО. На верхнем уровне порядка 60 тыс тэгов.
Число датчиков, как дискретных, так и аналоговых - порядка 100 тысяч.
Плюс к этому, Ваше оборудование должно быть сертифицировано во всех инстанциях по всем необходимым критериям безопасности и качества.
В том числе и Вы, как программист.

Я ПЛК не разрабатываю. Я их эксплуатирую. Поэтому, Вам виднее...

И вообще, здесь речь не о ПЛК...

О! Золотые слова.

Да, тут есть нюансы. И я тоже не стану категорически говорить, что для МК С или С++ лучше (а то и must have).

В принципе С++ обладает большими выразительными силами (назовем это так), чем С. И для МК они так же применимы. Но он так же содержит огромный подводный камень (я бы даже сказал - скалу). Он обладает неограниченными возможностями выражать сложные конструкции простыми действиями. Ну например, сгенерить несколько неочевидных действий в самом простом выражении, типа a=b+c; В результате простая и короткая (по внешнему виду) программа может превратится в монстра
Второй подводный камень - это сам ООП (как не странно). Частенько у программистов есть стойкое убеждение, что если С++ это ООП язык, то все вокруг должно быть в объектах, наследовании, виртуальных функциях и т.д. и т.п. Тут надо вовремя остановится - С++ позволяет писать в обычном процедурном стиле, а что более важно, он позволяет не писать в ООП стиле там, где это не нужно.

Так что, если вы собрались писать для МК на С++, то или вы должны быть экспертом в этом языке (что бы не наломать дров), либо быть в постоянном контакте с такими экспертами, что бы они не дали вам наломать дров.

В общем да, хотя сложность С++ сильно преувеличенна. Пары больших программ (тысяч в несколько строк) вполне достаточно, что бы как то освоится с С++

PS. Хочу уточнить, что под местоимением вы в вышеизложенном тексте, а не имею в виду лично sasamy, без обид.

В мемориз, однозначно!
Все правильно.
Каждой задаче - своя методология ее решения.
Нет применению ООП без нужды!

Я тоже пишу, так сказать, под плюсами, но практически не использую ООП.
Просто очень удобно работать с классами, перегруженными функциями\операторами, пользоваться всякими плюшками вроде агрументов по умолчанию и т.п.
Мелочи, но приятные, зачем себя ограничивать рамками "простого" Си?


Вот-вот, и у студента, которому взбредёт в голову с нуля создать такую сложную железку, как ПЛК, результат будет такой же...
Там ведь не только программирование, но ещё и схемотехника, разводка печатных плат и т.п.

Так именно об этом и речь!


+1!


Я бы уточнил: необходимо разбираться в используемых средствах языка. Например, если человек не разбирается (чувствует себя неуверенно) в шаблонах, то лучше их ему [пока] не использовать (там хватает заслуживающих внимания средств и без них). И это касается не только МК, но и языка вообще. И не только С++, но и других языков тоже (на том же С с адресной арифметикой можно ого-го дровишек наломать). Если что угодно делать без достаточного понимания, то успеха не достичь. Это универсальное правило. И это не причина шельмовать инструментарий.

Конечно, но на МК это проявляется особенно остро. Если на РС слепить программу на С++ со всеми контейнерами stl, привлечь парочку паттернов (потяжелее), и еще чего нибудь, то на РС программа станет на пару [десятков] мегабайт больше, при запуске съест на пару [сотен] мегабайт больше, и будет работать на 50% медленнее. С современными характеристиками РС этого никто не заметит. А вот для МК это будет фатально - программа тупо не влезет ни в какой камень

Зато МК быстро таким образом приучает к дисциплине мышления и кодирования, мотивирует работать "компилятор" в голове у программиста и учит чётко представлять, как реализуются абстракции и концепции ЯВУ в железе, и во что выльется та или иная языковая конструкция. А РСшный программер, которому целевая платформа "прощает" некачественную работу, имеет шансы так не узнать, какой говнокод он генерит. Первый путь мне больше по душе.

А Вы в курсе, что по очень правдоподобной легенде, нынешние популярные вычислители AVR и ARM созданы именно студентами.


Тогда я бы пошел еще дальше.
Надо разбираться в теории того, что ты делаешь.
Даже здесь в качестве примера приводилась задержка в виде цикла замкнутого на себя.
Но это же недопустимо по-любому.
Я даже на РС так не делаю. А уж на МК...

Именно такого решения я от вас и ждал. Можно было еще сослаться на BOOST_PP_REPEAT и иже с ним. Там можно до 255 "итераций" и до 3 уровней вложенности. Ну да не важно.
А теперь попробуйте пожалуйста сделать максимально объективный сравнительный анализ этих двух техник, скажем, по таким параметрам:
- функциональность;
- области применимости;
- ограничения;
- удобство диагностики ошибок кодирования;
- удобство чтения исходного текста;
- удобство отладки;
- стоимость внесения изменений;
- порог вхождения для использования.

Выводы за вами.

Да, AVR кривоват, этого не отнять.


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

Мне лично импонирует другой подход, которого придерживается Никлаус Вирт - «Делай просто, насколько возможно, но не проще этого»

Вот только критерии возможной простоты вещь не формализованная и каждый их видит по своему. Для одного простота это "дамп потока сознания", а для другого это четкая архитектура с прозрачным разделением на модули инкапсуляцией и максимальным повторным использованием кода.
Простота - это понятие более философское, чем инженерное.

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

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

Какую простоту Вы предпочитаете?
Некоторые пункты взаимоисключающие. Сложно бывает найти компромисс в этой "простоте"
Лично я обычно приношу первые два пункта в жертву остальным, поскольку они есть малая часть жизненного цикла ПО.
Казалось-бы какое всё это имеет отношение к С++?

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

Типичный тролль. Неудобные вопросы проигнорированы, зато раздал ценные указания.
Такой опрос уже был, воспользуйтесь поиском.

ПНХ



Пожалуйста - отвечаю: по всем пунктам однозначно С



Не мне это нужно было.

Я что-то не пойму, не прикрытое хамство, а теперь уже и завуалированный мат - это теперь норма на этом форуме?
Теперь каждое неграмотное быдло может грубить уважаемым участникам форума?
Где модераторы?

ПНХ - Пожалуйста Не Хамите.



Есть вопрос по scmRTOS (как известно она написана на C++):
допустим есть микроконтроллер с MMU, хочется использовать аппаратную защиту памяти процессов, возможно ли это сделать быстро без серьезных изменений кода этой ОС ?
это касается этих пунктов

Так мы же сами эту норму и создаем. Никто не может смериться с тем, что у каждого есть свои личные пристрастия, привычки и устои. Каждому нужно доказать, что он прав, и другим необходимо поступать также. Зачем ломать чужие убеждение в такой форме? Я имею в виду в форме "пустого трепа" (прошу прощения за это выражение)? Делиться опытом нужно, но когда этот опыт усваиваться тем, с кем делишься. Если чаша переполнилась, зачем туда наливать воду? Не все готовы поменять свои взгляды. Пусть. Пройдет время и они их изменят, либо изменят те, кто пытался изменить (еще раз прошу прощения). У каждого своя правда
Давайте научимся уважать друг друга, и уважать мнение и методологию работы другого. Я понимаю, что если бы у нас был общий проект, тогда да - необходимо более менее работать одинаковыми способами. Но тут - каждый сам по себе, у каждого свои нормы.

Прошу меня извинить уже за мой "треп"...

Спасибо!

Какие бы ни были пристрастия или устои, вести себя в обществе нужно вежливо, было бы это общение лицом к лицу, или же на форуме.
Большинство так и поступает, слава богу, и этот форум не исключение.

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

Чего так слабо - желтые штаны - два раза Ку.