На самом деле ровно наоборот: если хорошо знаешь С++, то использовать С нет смысла.


Написана редкостная чушь. От первого слова до финальной точки. Всё вывернуто ровно наизнанку. Видать аффтар ещё тот "знаток" плюсов.


Правда? Давайте проверим. Покажите дубль на С для следующих вещей:

Пример номер раз. Перегрузка имён функций.


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

Предъявите аналог на С?

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

Аналог на С, плиз?

Ну, и до кучи, чтобы не приводить банальности про параметризованные типы, - стандартная библиотека шаблонов. Если надо защищённый массив с быстрой индексацией, использую std::vector<>, если нужен список, то std::list<>, если очередь FIFO, то std::queue<>, если ассоциативный массив, то std::map<> и т.д. Причём операции все унифицированы - например, если хочу добавить объект в контейнер, то делаю container_name.push_back(object_name), и т.п. Общие операции с контейнерами унифицированы, поэтому не нужно досконально изучать интерфейс каждого контейнера. Мегамогучая штука.

Как там это на С делается?

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

То, что вы их не знаете, не значит, что их нет. У С++ есть ABI, и name mangling там тоже описан ( http://sourcery.mentor.com/public/cxx-abi/ )

Родился этот ABI как ABI для С++ на Itanium, в настоящее время получил статус стандарта (но для каждой конкретной платформы есть платформо-зависимые дополнения к этому ABI)

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



Абсолютно бесполезная фича. Кстати какая ф-ция будет вызвана при send(0) и что еще интересней если один из вариантов при этом будет принимать в качестве аргумента указатель ?

Предлагаю свернуть тему. А то НГ на носу. И страницы множатся в данном топике

(круглый)
ЗЫ
С Новым Годом усех!
Поменьше глюков!
Побольше интересных задач!

А можно вопрос уважаемому sasamy, а вы С++ вообще то знаете? Писали на нем что нибудь объемное?
Судя по вашим аргументам - нет. Пока они все в духе 'Пастернака не читал, но осуждаю'

Вот, из классика :

0 - это число, следовательно будет вызвана вторая функция.

Вас не просили судить о полезности данной "фичи". Вас просили привести аналог.

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

Вспоминается «прав был парторг — омерзительное зрелище».

Сидел и пробовал вспомнить — в чём же С++ уступает С при том, что он есть надмножеством С.

Единственное, что вспомнил, так это то, что '0' в С++ имеет тип char, а не int. В силу чего широкие символьные константы в духе 'DCBA' (сколько влезет в int на данной архитектуре, столько и можно писать) в С++ использовать нельзя, а в С — можно.
Но это настолько редко используемая возможность С, что о ней мало кто будет тужить.

Еесть ещё нюансы вроде (если я правильно понял) разницы в обработке
но то скорее изменение поведения, чем функционала.

Приведите таки пример того, где С++ уступает, а?
Не опровержение приведенных dxp примеров расширения функционала (да и то в духе «я не понимаю, зачем это нужно, поэтому это не расширение»), а именно Ваш пример «уступания».

p.s. А вообще — все до сих пор приведенные аргументы против С++ звучали ну совершенно так же, как аргументы против С 15 лет назад в RU.EMBEDDED.
Даже «ну конечно, вы потратили время на изучение, как вы теперь признаете бесполезность» звучало в той или иной форме.
И тогда же кто-то хорошо сказал (или процитировал) приблизительно такое:
При написании больших программ на ассемблере рано или поздно приходится делать некие соглашения о вызовах, распределении регистров, ... Чтобы не делать это вручную, придумали языки высокого уровня, включая С.
При написании больших программ на С рано или поздно начинаются массивы указателей в структурах, использование структур-«потомков» с добавленными в конце полями и т.п. Чтобы не делать это вручную...

А дальше — когда «большой» инструмент уже есть, почему бы не использовать его в малом, если он это «малое» не рвёт на части?
Даже когда мне нужно просверлить пару дырочек в дереве — я же беру электродрель, а не ручную (хотя у меня она есть и иногда, когда это _действительно_ нужно, я беру её) и тем более не буравчик (вот его у меня уже нет, хотя, пожалуй, немного посидев придумаю и то, где он лучше любой дрели). Для пары дырочек в стене я беру перфоратор, а не шлямбур и молоток (они тоже есть :-) ).
Видел, как для снятия небольшой фаски на рейке человек включал шлифмашинку (одну из нескольких, уже закреплённую в верстаке за ручку), а не брал кусочек наждачки, как это сделал бы я. Просто у него этот инструмент есть и он им владеет.
И я почему-то это понял, а не начал трындеть про отсутствие в нём необходимости, ну по крайней мере, «для таких маленьких реечек».

Это был Василевский.

u

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

1) На ассемблере+фортране в своё время было написано столько («практически все ОС написаны на ассемблере», на С только одно вон то), что с Вашими аргументами С нужно было убить сразу.

2) Сначала покажите хотя бы один пример, где С++ во многих случаях уступает ему (С) при этом.. «А то языком чесать...». Вы замахнулись на «объективную» оценку, тогда как малая распространённость С++ в МК, на мой взгляд, имеет в основе скорее субъективный фактор. Вот и докажите конкретным примером «уступания», что это таки объективные причины имеет.

Точно!
У меня всегда была плохая активная память на имена :-)

Объемное - нет и не собираюсь.
http://sasamy.narod.ru/l4fiasco_at91.patch.gz



Тут ключевое слово - было, на С и С++ пишут сейчас.



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

Было время, когда в тогдашнее «сейчас» писали на асме и фортране, а С только появился. Тогда было «на асме, фортране и С пишут сейчас». И тогда было «большинство ОС написаны на асме, прикладного софта — на асме и фортране». С уже существовал. Вот тогда его и надо было Вашими аргументами убить.
15 лет назад в эмбеддерских кругах любители ассемблера (в основном — просто незнатели С) наскакивали на С точно так же, как и сейчас Вы на С++. При том, что с точки зрения инструментария ситуация с С в ембеддед была приблизительно такая же, как сейчас с С++ — для большинства архитектур есть.
По поводу одного из аргументов (про несогласие потративших время с тем, что они потратили его зря) я уже говорил, добавив этот
могу только процитировать «и то, и другое я видел не раз — кого ты хотел удивитть?» (в смысле точно такой же аргумент, только без символов ++ и против С, а не за него, — я уже слышал).

Я прошу один, в котором язык С++ уступает. «он слишком сложен» — не катит. Хотя бы потому, что он уже применялся против С, а не за него. И потому, что многие пользующиеся С сейчас — так его толком и не знают (надо-то тоже «не год, и не два»).
А если ограничиться частью С++, то тоже не так и сложно. У меня же кое-что получается :-)

sasamy,
вот у меня в соседней ветке конкретный вопрос

сам давно (очень) делал на плюсах, сейяас просто C, поэтому задал там вопрос

мой вопрос здесь, т.к. Вы можете подсказать решение и определиться мне - так или эдак

Чего вы привязались к этому C++ ? Я естественно не авторитет в выборе языка и высказываю свое мнение, но если интересно - например не новичек в C/C++ и действительно авторитетный человек вот что говорит:

http://www.minix3.ru/articles/Tanenbaum_interview_en.html


Язык программирования Cyclone

Это мы привязались? Прозвучало как «пошла ты нафиг со своим утюгом» из анекдота.

«мнения» бывают разные. Одно дело «мне язык не нравится, какой-то он перенавороченный» — это оценочное суждение и, вопрос вкусовой.
Но
это уже конкретное обвинение. Потрудитесь обосновать. Не переводя стрелки на Cyclone или, скажем, D, который мне импонирует.

Он говорит, что С++ не был выбран потому, что тогда, в 1987, он еще не слишком широко использовался (от меня: да и был он тогда ещё без многих современных возможностей, хотя многое из ручной работы уже автоматизировал). И что это у него была больше дань традиции, чем идеологии. И что если он когда-то будет куда-то переходить, то это будет С-клон. Т.е. конкртеное решение конкретного человека в конкретных условиях. И ни слова не сказал о том, что ему не нравится С++ чем-то конкретным. «It is more legacy than ideology»

Теперь передвинем этот текст на пол-периода в прошлое, другие люди и другой проект. И получим что-то в духе

— Почему как язык разработки был выбран Фортран? Собираетесь ли вы переходить на другой язык, например, С?
— Мы начинали в 1975. С ещё мало был тогда распространён. Если мы когда-то перейдем, то, возможно, на ADA

Было бы это аргументом против С в 1985 году?

А если я теперь против Cyclone применю ваш аргумент?
«Приведите мне примеры ОС, для микроконтроллеров и малых микропроцессоров, написанные на С-клоне. А вот на С++ больше написано»
Вы сможете защитить С-клон?

С++ хоть и давно существует, но в embedded-области еще новичок. Как бы «только-что появился», так как процессоры, применяемые в этой области, только стали подтягиваться к достаточному уровню.

Ситуация очень похожа на положение С в embedded 15-20 лет назад. К тому моменту С уже давно существовал и прочно сидел в области «больших» процессоров. Но для «мелочи» частично не пролазил по объёмам ОЗУ/ПЗУ, частично — по (не)привычке, инерции и «неосвоенности». И когда уже разобравшиеся с ним за него агитировали — против С звучало всё то же, что тут прозвучало против С++. И до крайностей в духе
— Это вы понтуетесь тем, что разобрались, так как кроме как для понтов это не годится. А нам некогда понтоваться, нам работать надо.

И звучало, даже с линками на зачаточные компиляторы, такое:
— вот если бы Модула, или хотя бы Паскаль нормальный, вот это да...

Так и где сейчас в нашей области модула с паскалем? Насколько много осталось ассемблера? А где С?
Вот доживём, посмотрим на С-клона в сравнении с С++.
Если микро-дот-нет не задавит обоих :-)

p.s. Когда почти 15 лет назад в упомянутой RU.EMBEDDED dxp уже начинал говорить о С++ — я тоже слушал недоверчиво :-)

Под "привязались" я имел ввиду что вы уцепились за С++ как за панацею и явно ожидаете что в ближнем будущем все будут писать на С++ как сейчас на С.



Скажем макросы - мощнейший инструмент кодогенерации в С и головная боль в С++



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

Потрудитесь развернуть свою мысль. В чем именно головная боль?

Потрудитесь книжки почитать
http://www.programmer-lib.ru/cstandart_page.php?id=9

Макросы в голом Си настолько-же опасны как и в С++, но в последнем есть возможность их много реже использовать:
- типизированные константы;
- inline функции;
- шаблонные функции;
- шаблоны классов.
Эти возможности успешно заменяют макросы и превосходят их в 99% случаев.
Но в 1% макросы нужны и в С++, поэтому они в нем есть.

Вот эта часть цитаты

автор - я.

По ходу, автор ссылки сам текст по ней не читал, ибо там чётко и конкретно сказано:

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

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

А за сайтик http://www.programmer-lib.ru - спасибо!

Эти возможности вообще нихрена не могут в кодогенерации по сравнению с макросами





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

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

Это вряд ли. Скорее это зависит соотношения "сложность задач/доступные ресурсы (время/трудоёмкость). Попробуйте, например, GUI написать на С и С++, разницу поймёте сразу.


Тут уместно другое сравнение. Вот в С структуры уместно использовать? Ну, чтобы вместо использования пачки связанных по контексту задачи переменных упаковать их в структуру. Упрощает работу с данными - согласитесь, что работать с таким агрегатным объектом много удобнее - вместо нескольких мелких сущностей получаем одну более крупную. Когда подобных объектов в программе набирается с полдюжины, то структуры вообще начинают рулить (на любом языке, кстати - вон в SystemVerilog есть поддержка структур, так они очень сильно облегчают работу по сравнению с классическим Verilog'ом).

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

Напрашивается логичный вопрос: так почему бы не сделать специально некоторые функции ассоциированными со своим типом структур, а часть данных структур сделать доступными только для кода этих функций? При этом и передача указателя на структуру при вызове своих функций делается неявно, и обращение к данным внутри функции производится с неявным разыменовыванием (для улучшения читабельности). Вот так и приходим к концепции класса. Это самое первое приближение, которое часто называют "С с классами" (эту идеологию реализовывал первый компилятор Страуструпа).

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


Вы слишком общо задали условия. Уточните, что должны делать оные "электрические машины", какие общие и частные свойства иметь, как применяться?

Замечательный пример. Показывает, что вы абсолютно не разбираетесь в том, что огульно охаиваете на протяжении уже нескольких страниц этой темы.
Весь этот ужас с макросом CMDLINE_DEVICE_CHOOSE замечательно ложится в тривиальный класс С++ (либо шаблонный, либо с парой виртуальных функций - как понравится)

Спасибо. Опять никакой конкретики привести не можете. Печально. "Слив засчитан".

Чем конкретно этот макрос, будучи использован в С++, доставит "головную боль" и почему этой головной боли не будет с этим же макросом, но в C-программе? Только не надо отсылать к литературе. Это ваш конкретный пример и будьте добры, отвечайте конкретно.

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



да вы вообще похоже не догоняете - у меня код автоматически генерируется а вам с вашими виртуальными ф-ми его вручную набивать надо будет для всех вариантов.
CMDLINE_DEVICE_CHOOSE(ssp1, mmc, spi1)
CMDLINE_DEVICE_CHOOSE(ssp2, nand_mfc, spi2)

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

А теперь подумай хорошенько - стоит ли применять паттерны проектирования в ООП там где это ну совсем нафик не нужно.

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

Выбор использовать ее или нет каждый делает сам для себя...

Вам - не нужно. А вменяемые люди применяют
Да ну???
До некоторой степени можно изменить.
Это точно, пока вы несете пургу и ни одного удачного примера не привели
Давайте, продемонстрируйте.
То, что вы не знаете С++ мы уже поняли, зачем же об этом продолжать так надрывно кричать?
Да уж, макросы на пол-страницы - это 'ясно и кратко'

http://www.boost.org/

Это вы к чему? Если вы не в курсе, то boost - это С++ библиотека, а не С, как вы видимо по неведению думаете

Там один клоун пример просил использования макросов - но мне самому что-то не хочется больше писать.



Об это даже в заголовке написано по ссылке - не думайте что все кругом совсем дебилы, по себе не судите. Я мог бы вам дать ссылки на исходники ядра Linux где макросы очень эффективно используются - вызововы syscall, микроассемблер для mips и проче но вы же ответите в своем стиле - я это напишу красиво - один класс с парой виртуальных ф-ций при этом не приводя ни строчки своего кода, поэтому я вам дал ссылку на библиотку С++ - можете начать отсюда
http://www.boost.org/doc/libs/1_48_0/libs/.../doc/index.html

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

Это понятно. И при правильной эксплуатации вполне логично.

Имеет и еще какое. Но об этом ниже.

Вот здесь мы и расходимся.
У меня в этом мире нет ни одного объекта, совпадающего с другим, кроме искусственных, созданных программно.
А это всего лишь часть задач, предлагаемых к решению.
И здесь, ПМСМ, кроется некое противоречие.
Любители ООП ломают задачу под себя.
При этом они абстрагируются от архитектуры вычислителя и от от реального объекта, упрощая его своей моделью в виде класса.
При этом создается некая искусственная среда, зачастую включающая в себя ОС там, где это не является необходимостью.
А вот на этой благодатной почве и расцветают все кактусы.
Поскольку Ваша искусственная среда естественным образом не совпадает с моей.
И я, желая использовать Ваш код, вынужден разбираться в Вашем восприятии реальных объектов.
А это для меня практически не осуществимо.
Есть иная концепция.
Когда программист приспосабливает вычислитель к реальным объектам без искусственной среды.
При этом считается, что каждый объект уникален.

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

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



Дык задал уже все вопросы в прошлый раз. Для проектирования надо чётко представлять себе предметную область. А из одного термина "электрические машины" лично мне не понятно, что имеется в виду. Электродвигатели? Генераторы? Или что ещё? Какие свойства представляют интерес для моделирования? Какие операции применимы к этим машинам (запустить, остановить и т.д.)? Какие типы машин (коллекторные, синхронные, асинхронные...), какие операции применимы к каждому из типов. Например, если речь идёт об электрической машине вообще, то там вижу только пару действий: включить и выключить. Если рассмотреть конкретно двигатели, то у тут появляется ещё, например, функция управления скоростью вращения, моментом.

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


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

Если программа предназначена не для мелкого МК, а для РС, то группы удобно организовывать на основе STL.

Если же всё это писать на уровне переменных и функций, то это будет гора неструктурированного кода, где все связи между объектами (переменными и функциями) будут жить только в голове у программиста (вот где раздолье для кактусов ). А код, который организует управление этими объектами будет очень похож на то, что в зарубежной литературе называют "spaghetti code". Развивать такой проект - требует изрядно сил и внимания на удержание в фокусе всех этих мелких и не очень объектов и нюансов их взаимодействия, а сопровождение такого кода ужасно.


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

Какое заблуждение. Взгляните на исходники какой-нибуть ОС
http://prex.sourceforge.net/src/S/252.html

Все четко и структурировано. На чистом С. Каркас ОС пишется вообще безотносительно - какие устройства есть на целевой платформе.

Если не ошибаюсь (давненько уже не смотрел чего нового в буст включили), boost::preprocessor это одна едиственная библиотека в бусте полностью написанная на базе макросов. Остальные основаны на число плюсовых фишках. Так что вы лишь подтверждаете чужие аргументы - 99% возможностей макросов покрываются новыми возможностями С++ (1% как раз - preprocessor). В обратную же сторону увы это не работает, попробуйте boost::spirit на макросы перевести

PS а за вами все еще пример где С++ уступает С.

Ищите по-лучше - там много где макросы используются.



Одного мало ? Кстати - если макросы совсем не нужны в С++ - на кой хрен в C++11 включили поддержку variadic macro из стандарта C99 ?
В общем кому нужен С++ - используйте на здоровье - мне он не нужен, может только иногда

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


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


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

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

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

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

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

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

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

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

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

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

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



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



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

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

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



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

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


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

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

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



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



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


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

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

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


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

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

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

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