А кто говорит что макросы в С++ вообще не нужны? Что я пропустил? Условная компиляция там везде, это и есть основное назначение макросов в С++.


Где? Когда? Я опять что-то пропустил?


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

У вас не просили примеры применения макросов, от вас просили удачных примеров на С, а вы дали ссылка на С++ библиотеку. То, что вам писать больше не хочется это заметно, ибо писать нечего
я не думаю, что все. Пока вы один тут клоуном выступаете
Не надо, я знаю, где ядра лежат
Мы вроде про С++ говорили, а не про макросы?
Все ядро Linux написано в ООП стиле. А то, что не на С++ объясняется исключительно идеосинкрозией Торвальдса на С++
Пардон, я не понял, что вы хотели увидеть код. Я так думал, что вы вылезли сюда исключительно полить помоями С++ и всех его приверженцев.
Нафига оно мне? Я и так boost использую. И то, что возможности препроцессора С не полностью покрываются возможностями С++ я тоже знаю, но ведь речь шла не об этом.

К сожалению, я не смогу привести пример вашего куска кода на С++, т.к. по этому куску совершенно непонятно, что он должен был делать. Но чисто внешне, это должно быть чем то таким:
И так же чисто внешне, этот кусок должен быть сделан немного по другому

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

Это вы о себе ? Заметьте мое терпение закончилось по отношению к вам в самом конце. И не боюсь я ваших бананов

Нет, о вас. Я не пытаюсь тут (и где либо еще) рассуждать о вещах, в которых ничего не понимаю, и не даю советов о том, чего не понимаю другим
Это модераторам решать

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

Приношу свои извинения за то, что заставил Вас написать столь длинный пример.
Поверьте, я не со зла.
Я только хотел сказать, что под общепринятым понятием может скрываться хренова туча разнородных объектов.
Добавлю только, что трансформатор - тоже электрическая машина.
А внешних свойств с остальными вращающимися машинами у него практически нет.
Хотя его тоже можно включить и выключить.
И плавно переходим к кактусам.
Сравниваем мой и Ваш.
Я бы сделал в базовом классе вращающихся машин в первую очередь виртуальные функции, позволяющие осуществить управление по моменту и по скорости.
Если бы у нас дополнительно стояла задача серво управления, то еще добавил бы виртуальных функций для точного перемещения.
Что касается "стоячих" электрических машин трансформаторов и асинхронников с заторможенным фазным ротором, то здесь вообще для меня не ясно, что делать. Поскольку назначение этих девайсов совершенно иное, чем у вращающихся машин.
И в результате наши классы получились бы полностью разными.
Потому как построены на разных подходах при достаточно общей постановке задачи.
А других постановок задач в нашем беспокойном и яростном мире ожидать не приходится.

А вот здесь Вы неправы.
Помимо мира "чистых" программистов существует такой же огромный мир программистов промавтоматики.
А там код весь код именно такой - неструктурированный, где все связи между объектами изначально были только в головах механика и технолога, которые рисовали циклограммы технологического процесса. Потом к этому делу приложились программисты, которые и понятия не имеют о реальных механизмах машины и процессах, происходящих в ней.
И ничего, тысячи людей зарабатывают тем, что сопровождают такие проекты. И даже модифицируют их, когда этого требует производство. Быстро и качественно. Иначе лишат сладкого.
Там тоже есть свои кактусы. И свои методы. И специально обученные люди.
И чтобы было понятно - поясню. Речь идет о нескольких миллионах строк кода.

А с каких это пор модель перестала быть самостоятельным объектом?
На самом деле у Вас есть два объекта - сам реальный объект и его виртуальная модель.
И хорошо, если Вы не ошиблись, когда только начинали проектировать базовый класс.
Или вдруг не поменялись свойства нижнего объекта таким образом, что Вам придется перелопачивать практически все.
Иначе наварите таких макарон, что спагетти покажутся царским лакомством....

И естественно не разбираетесь в нем.



Вы с ним лично знакомы ? хотя странно что вы не сказали в своем стиле - он С++ не знает



А о чем ? лично я говорил именно об этом - препроцессор С намного удобней и мощней встроенных средств С++.

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

Для вас типичная - для меня нетипичная и даже бесполезная в какой-то мере кросплатформенность должна быть. В linux например богомипсы для точных задержек вычисляются при инициализации ядра и на основании их вычисляются точные програмные задержки.



Покажите, если хотите - я не против кажется в avr-libc на препроцессоре задержки сделаны.

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


Оно не прячется, а убирается с глаз долой, т.к. в месте использования совершенно не нужно и только мешает. Представьте себе, что вам по вашему подходу сделали автомобиль, чтобы управлять которым вам приходится не только руль крутить и педали нажимать, но и регулировать давление в безнопроводе, подкручивать в зависимости от оборотов двигателя угол опережения зажигания, устанавливать концентрацию бензина в смеси (побогаче делать или победнее) и ещё десяток регулировок, которыми в современной машине управляет бортовая электроника автоматически.

Удобно будет этим пользоваться? Как часто будете ошибаться? С какой скоростью будете ехать? Как часто в аварии попадать? Даже если не пользоваться этими регулировками постоянно, а оставить их в каком-то оптимальном для большинства режимов работы положении, то просто наличие их на панели управления будет мешать и иногда всё равно какая-нибудь не та кнопка будет нечаянно нажиматься. Зато никакого страусизма - всё лежит на виду.

Кстати, ваши любимые ПЛК - ярчайший пример подхода, который вы критикуете. Именно ПЛК и возникли как реализация идеи: спрятать все нюансы и сложности поглубже внутрь, наружу оставить только простой интерфейс, чтобы этим можно было легко пользоваться без риска наделать ошибок в реализации. При этом ещё остаётся возможность изменять реализацию без всякого риска порушить систему из-за несовместимости. Например, можно полностью переделать внутренности, заменить на плате главный микроконтроллер (скажем, с меги128 на какой-нить кортекс), повысить быстродействие, улучшить другие свойства, включая цену, и всё это без риска и проблем - отделение интерфейса от реализации в полный рост. Та самая инкапсуляция и абстракция.



Конечно. Я ведь в прошлый раз так и написал, что нужно очень чётко знать предметную область. Приведённый пример был, исходя из одного подхода. Если у вас другой, то и реализация тоже будет другой. Но общность подхода это не меняет - есть вполне чётко выделенный этап проектирования, который поддержан средствами языка, и это есть хорошо. Нужно только научиться этим пользоваться.



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


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

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

Ой сделайте мне такие точные задержки, чтоб до такта, и кросплатформанно чтоб на AVR, MSP430, STM8 и на всём с Cortex M3 ядром. Очень хочу! Шутка.


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

Всего 6 строчек кода. И кстати, кросплатформенно.
Использовать просто:

Причем N может быть не только целым литералом, это может быть любое целочисленное константное выражение.
А на счет avr-libc, то там задержки сделаны в виде обычных функций с ассемблерными вставками:

Они к сожалению не дают точности до такта, издержки на установление цикла не детерминированы и могут составлять от 1 и до примерно 10 тактов в зависимости от контекста использования. Ну да ладно, что мы привязались к этим задержкам, суть не в них, а в кодогенерации. Жду контрпримера...

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

rep_example.c





rep.sh



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


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

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

Когда сильно припекает - можно и на АСМ-е.
Но это бывает крайне редко. Практически никогда.
А мне приходилось в юности и на 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
Вот что сгенерировал препроцессор. Причем код генерируется платформо-зависимый.





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

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

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

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