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

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

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

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



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



ы ?



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

Сообщение отредактировал sasamy - Dec 25 2011, 13:03

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

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

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

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

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

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

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



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

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

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

Сообщение отредактировал Прохожий - Dec 25 2011, 14:52

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

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

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

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

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

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

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

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


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

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


+1!


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

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

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

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


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

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

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

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


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