[xvr 12]

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

Речь шла о том, что не надо приплетать кодогенерацию там, где она не нужна. Для 1000 штук добавится еще 7 строк. Тщатьельнее надо смотреть то, что вам пишут.

То что вы написали говнокод на С++ влоб переписав кусок кода на С совершенно не разобравшись что он делает,

Абзац. Т.е. я должен был телепатически догадаться, что ваш макрос без начала и концы выдран из ядра Linux'а и сделать вам конфетку?

Про 'говнокод на С++' умолчим - он делает ровно то, что делает ваш макрос. И делает это гораздо лучше

при этом не поняли что это из ядра Linux, __setup - это стандартный макрос ядра и он в свою очередь тоже разворачивается в код, говорит что вы некомпетентны.

Это говорит о том, что вы троль.

 

Вот во что сгенерировал препроцессор. Причем код генерируется платформо-зависимый.

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

 

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

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

 

[sasamy 0]

Т.е. я должен был телепатически догадаться, что ваш макрос без начала и концы выдран из ядра Linux'а и сделать вам конфетку?

 

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

 

Речь шла о том, что не надо приплетать кодогенерацию там, где она не нужна. Для 1000 штук добавится еще 7 строк. Тщатьельнее надо смотреть то, что вам пишут.

 

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

 

Покажите, пожалуйста, как с помощью препроцессора повторить некий кусок кода N раз, при условии, что N заранее не известно и передаётся откуда-нибудь из вне в виде целочисленного литерала.

 

ы ?

 

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

 

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

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

[dxp 65]

Ну Вы же далеко не сноб.

Зачем же принижать квалификацию профессионалов в той области, с которой Вы сталкиваетесь крайне редко?

То, что Вы изложили - дилетантизм, простите за резкость.

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

 

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

[xvr 12]

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

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

 

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

 

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

 

[sasamy 0]

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

 

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

[syv 0]

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

Вы знаете, где это можно сделать безболезненно.

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

 

 

Ну да, конечно, то то я смотрю, у нас на заводе повсюду ПЛК одних и тех же солидных фирм, а вот программы для них пишут все подряд, включая тех же недавних студентов.

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

Дык, на С и С++ пишут тоже все подряд. И схемы разрабатывают. И Саяно-Шушенскую ГЭС эксплуатируют. Давеча вон Фобос-Грунт...

Что же касается кода, о котором я говорил, приходите - покажу.

Писали немцы - уважаемые и опытные люди.

Если сможете сделать лучше, даже денег дадут.

Только одно НО. На верхнем уровне порядка 60 тыс тэгов.

Число датчиков, как дискретных, так и аналоговых - порядка 100 тысяч.

Плюс к этому, Ваше оборудование должно быть сертифицировано во всех инстанциях по всем необходимым критериям безопасности и качества.

В том числе и Вы, как программист.

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

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

 

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

Изменено 25 декабря, 2011 пользователем Прохожий

[xvr 12]

Если говорить о крупных проектах типа Qt или какой-нибуть EDA (тут на форуме кажется есть ребята которые участвуют в разработке ) - я даже встревать не стал бы :)

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

 

но речь вообще-то тут о микроконтоллерах.

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

 

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

Второй подводный камень - это сам ООП (как не странно). Частенько у программистов есть стойкое убеждение, что если С++ это ООП язык, то все вокруг должно быть в объектах, наследовании, виртуальных функциях и т.д. и т.п. Тут надо вовремя остановится - С++ позволяет писать в обычном процедурном стиле, а что более важно, он позволяет не писать в ООП стиле там, где это не нужно. :1111493779:

 

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

 

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

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

 

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

 

[syv 0]

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

Второй подводный камень - это сам ООП (как не странно). Частенько у программистов есть стойкое убеждение, что если С++ это ООП язык, то все вокруг должно быть в объектах, наследовании, виртуальных функциях и т.д. и т.п. Тут надо вовремя остановится - С++ позволяет писать в обычном процедурном стиле, а что более важно, он позволяет не писать в ООП стиле там, где это не нужно. :1111493779:

 

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

В мемориз, однозначно!

Все правильно.

Каждой задаче - своя методология ее решения.

Нет применению ООП без нужды! :)

 

[sonycman 1]

Я тоже пишу, так сказать, под плюсами, но практически не использую ООП. :)

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

Мелочи, но приятные, зачем себя ограничивать рамками "простого" Си?

 

Дык, на С и С++ пишут тоже все подряд. И схемы разрабатывают. И Саяно-Шушенскую ГЭС эксплуатируют. Давеча вон Фобос-Грунт...

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

Там ведь не только программирование, но ещё и схемотехника, разводка печатных плат и т.п.

[dxp 65]

В мемориз, однозначно!

Все правильно.

Каждой задаче - своя методология ее решения.

Нет применению ООП без нужды! :)

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

 

Я тоже пишу, так сказать, под плюсами, но практически не использую ООП. :)

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

Мелочи, но приятные, зачем себя ограничивать рамками "простого" Си?

+1!

 

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

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

[xvr 12]

И это касается не только МК, но и языка вообще. И не только С++,

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

 

[dxp 65]

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

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

[syv 0]

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

Там ведь не только программирование, но ещё и схемотехника, разводка печатных плат и т.п.

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

 

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

Тогда я бы пошел еще дальше.

Надо разбираться в теории того, что ты делаешь.

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

Но это же недопустимо по-любому.

Я даже на РС так не делаю. А уж на МК...

[neiver 0]

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

Именно такого решения я от вас и ждал. Можно было еще сослаться на BOOST_PP_REPEAT и иже с ним. Там можно до 255 "итераций" и до 3 уровней вложенности. Ну да не важно.

А теперь попробуйте пожалуйста сделать максимально объективный сравнительный анализ этих двух техник, скажем, по таким параметрам:

- функциональность;

- области применимости;

- ограничения;

- удобство диагностики ошибок кодирования;

- удобство чтения исходного текста;

- удобство отладки;

- стоимость внесения изменений;

- порог вхождения для использования.

 

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

[dxp 65]

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

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

 

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

Но это же недопустимо по-любому.

Я даже на РС так не делаю. А уж на МК...

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