Вопрос по С++ Опции

[_Артём_]

Как бы правильно отработать такую ситуацию на С++:
Есть плата, на которую может устанавливаться два-три близких по системе команд GSM-модема (большинство нужных команд полностью идентичны).
Думаю делать так:
Создать класс содержащий все нужные функции (различающиеся команды объявить как виртуальные), от него создать нужное количество наследников с переопределёнными функциями и .
Тип модема может задаваьтся конфигурацией (байт в еепром) или определятся запросом версии AT-командой (предпочтительней).
А вот как дальше делать?
Как лучше объявить в программе переменную-наследника?
Компилятор IAR AVR.

[Danis]

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

ИМХО, тут можно конечно сделать, но из за 2-x, 3-x подобных устройств использовать С++ со своими возможностями ООП (виртуальные функции и полиморфизм) Вам больше навредит, чем поможет. Сильно не рационально. С++ надо использовать только там, где это действительно необходимо и приемлемо, а не просто ради того чтоб использовать. Вот если бы подобных устройств было десятки, еще можно говорить….

[_Артём_]

ИМХО, тут можно конечно сделать, но из за 2-x, 3-x подобных устройств использовать С++ со своими возможностями ООП (виртуальные функции и полиморфизм) Вам больше навредит, чем поможет. Сильно не рационально. С++ надо использовать только там, где это действительно необходимо и приемлемо, а не просто ради того чтоб использовать. Вот если бы подобных устройств было десятки, еще можно говорить….

В смысле?
Что значит "десятки устройств"?
Десятки типов устройств?
Или экземпляров?

Типов модулей может быть 2-3-..5..10(это точно перебор, да и 5 - перебор: 2-3, а дальше - много(слишком))
А модулей - сотни(чем больше тем лучше) каждого типа...

У как по-Вашему лучше сделать?

С++ надо использовать только там, где это действительно необходимо и приемлемо, а не просто ради того чтоб использовать

честный ответ - как глоток свежего воздуха...©
А где ж его использовать?(С++, в смысле)...?

[kolobok0]

..А где ж его использовать?(С++, в смысле)...?

ну уж точно не в МК покрайней мере пока не стоит в полной мере. а вот ООА необходимо юзать всегда. даже когда вы пишите на азме. при этом сама механизация того или иного функционала - уже вторично.

(круглый)

[dxp]

ну уж точно не в МК покрайней мере пока не стоит в полной мере.

Поясните, пожалуйста, какие именно аспекты С++ делают его нерекомендуемым для использования с МК?

[sasamy]

Поясните, пожалуйста, какие именно аспекты С++ делают его нерекомендуемым для использования с МК?

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

[dxp]

Самый главный аспект - на порядки более сложный язык по сравнению с С

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

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

Голословное заявление. Кому не даёт реальных ++? Мне даёт. И знаю немало людей, кому тоже даёт.

с++ на МК - это наглядный пример "ООП ради самой ООП".

И опять вопрос (его почему-то приходится всегда задавать оппонентам): а причём тут ООП? Я знаю массу программ на С++, где ООП и не пахнет. А где ООП катит, так оно отлично ложится и даже на самые мелкие МК.

В общем, такая дискуссия пуста, т.к. безпредметна. Надо конкретные аргументы приводить. А в таком ключи можно и на С наехать, дескать, нафиг не нужен, асм форева (проходили 10 лет назад).

[sasamy]

Сложный - да, но как бы эти порядки определить?

Это общеизвестный факт и ничего тут не требуется определять.

Кому не даёт реальных ++? Мне даёт.

Вас уже спрашивал колобок о реальных плюсах, вы ему так и не сказали ничего кроме абстрактных "облегчение как проектирования софта, так и написания кода" - только я тоже самое могу сказать со своей стороны про С и это разговор ниочем - спор правши и левши какой рукой удобней ложку держать. Применительно к данной теме - зачем тут виртуальные ф-ции когда можно сделать простой switch/case ?

И опять вопрос (его почему-то приходится всегда задавать оппонентам): а причём тут ООП?

Не - это уже феерично - расхваливать преимущества C++ над С и при этом не использовать ни метапрограммирование ни ООП

[demiurg_spb]

Я скажу может крамольную вещь и даже кому-то будет обидно, но ничего - переживете
1. Невозможно действительно грамотно писать на АСМ не зная в достаточной степени процедурно-ориентированного языка программирования
2. Невозможно действительно грамотно писать на Си не зная в достаточной степени С++.

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

[sasamy]

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

Специально для вас и прочих теоретиков Не дайте Астронавтам Архитектуры вас запугать

[XVR]

Специально для вас и прочих теоретиков Не дайте Астронавтам Архитектуры вас запугать

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

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

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

А то будет, как у MS:

История программных революций от Microsoft, вкратце: Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они!

Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.

Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через браузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).

Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции «System File Protection», исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java - её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.

Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.

К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс- релизов. Главное, что нужно очень четко понимать - .NET исключает DLL Hell.

В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.

Автор - Ron Burk из WDJ.

[sasamy]

Не использовать С++ имеет смысл в одном случае - если ты его не знаешь

Если ты хорошо знаешь С использовать С++ нет вообще никакого смысла.

http://yosefk.com/c++fqa/picture.html#fqa-6.5

One thing is always true: where you can use C++, you can use C. In particular, if someone gave you C++ interfaces, a thin layer of wrappers will hide them. Using C instead of C++ has several practical benefits: faster development cycle, reduced complexity, better support by tools such as debuggers, higher portability and interoperability. When C++ is an option, C is probably a better option.

По сути С++ дублирует функционал С и во многих случаях уступает ему при этом.

[Сергей Борщ]

Если ты хорошо знаешь С использовать С++ нет вообще никакого смысла.

Не используйте, разрешаем. Если ты хорошо знаешь ассемблер, использовать С нет вообще никакого смысла.

[sasamy]

Если ты хорошо знаешь ассемблер, использовать С нет вообще никакого смысла.

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

[Сергей Борщ]

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

Мне они не нужны - я его использую. Хотелось бы как раз от вас услышать аргументы, разъсняющие, в чем же я так "заблуждаюсь". Кстати, аргумент в виде сообщений №38 и №41 вы игнорируете намеренно? Толстовато троллите, ох толстовато.

[sasamy]

Мне они не нужны - я его использую. Хотелось бы как раз от вас услышать аргументы, разъсняющие, в чем же я так "заблуждаюсь".

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

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

...
send(Slon);
...
send(S);

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

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

Сообщение отредактировал sasamy - Dec 21 2011, 11:43

[XVR]

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

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

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

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

[sasamy]

Писали на нем что нибудь объемное?

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

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

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

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

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

[ReAl]

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

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

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

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

Во многих случаях - это я хватанул конечно

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

[sasamy]

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

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

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

Why is it C chosen as the language of development? Is transition to C++ or other object-oriented languages possible?

We started in C in 1987. C++ was not very widely used then. It is more legacy than ideology. If we transitioned, it would probably be to cyclone.

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

Сообщение отредактировал sasamy - Dec 22 2011, 08:34

[ReAl]

Чего вы привязались к этому C++ ?

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

и высказываю свое мнение

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

По сути С++ дублирует функционал С и во многих случаях уступает ему при этом.

это уже конкретное обвинение. Потрудитесь обосновать. Не переводя стрелки на Cyclone или, скажем, D, который мне импонирует.

не новичек в C/C++ и действительно авторитетный человек вот что говорит:
http://www.minix3.ru/articles/Tanenbaum_interview_en.html

Why is it C chosen as the language of development? Is transition to C++ or other object-oriented languages possible?

We started in C in 1987. C++ was not very widely used then. It is more legacy than ideology. If we transitioned, it would probably be to cyclone.

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

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

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

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

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

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

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

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

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

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

[sasamy]

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

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

Потрудитесь обосновать.

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

Он говорит...И ни слова не сказал о том, что ему не нравится С++ чем-то конкретным. «It is more legacy than ideology»

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

[Сергей Борщ]

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

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

[sasamy]

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

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

[dxp]

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

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

Макрос — самый неприятный инструмент С и C++, оборотень, скрывающийся под личиной функции, кот, гуляющий сам по себе и не обращающий никакого внимания на границы ваших областей видимости. Берегитесь его!
<...>
Мне не нравится большинство видов препроцессоров и макросов. Одна из целей C++ — сделать препроцессор C излишним (§4.4, §18), поскольку я считаю его большой ошибкой.

Макросы почти никогда не являются необходимыми в C++. Используйте const (§5.4) или enum (§4.8) для определения явных констант [см. рекомендацию 15], inline (§7.1.1) для того, чтобы избежать накладных расходов на вызов функции [но см. рекомендацию 8], template (глава 13) для определения семейств функций и типов [см. рекомендации с 64 по 67], и namespace (§8.2) для того, чтобы избежать конфликтов имен

Первое правило по применению макросов гласит: не используйте их до тех пор, пока у вас не будет другого выхода. Практически любой макрос свидетельствует о несовершенстве языка программирования, программы или программиста.

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

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

[Прохожий]

....

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

[dxp]

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

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

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

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

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

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

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

Чтобы не быть голословным, попрошу уважаемое сообщество создать класс "машины электрические".
А там посмотрим - у кого что выйдет...

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

[Прохожий]

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

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

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

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

Как видно, ничего сложного тут нет, всё получается логично и по здравому смыслу, к кактусам в голове программиста отношения не имеет.

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

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

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

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

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

[dxp]

Вот здесь мы и расходимся.
У меня в этом мире нет ни одного объекта, совпадающего с другим, кроме искусственных, созданных программно.

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

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

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

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

CODE

class TElectricalMachine  // абстрактный базовый класс, не может иметь объектов
{
public:
    virtual void turn_on() = 0;  // чистая виртуальная функция, задаёт интерфейс
    virtual void turn_off() = 0;
};

class TMotor : public TElectricalMachine
{
public:
    TMotor() { ...  }
    ...   // другие конструкторы, если нужны

    virtual void trun_on();
    virtual void trun_off();
    virtual void set_rotary_speed(int x);

protected:
    int RotarySpeed;
  
};

class TCommutatorMotor : public TMotor
{
    TCommutatorMotor() { ...  }
    ...   // другие конструкторы, если нужны

    virtual void trun_on() { ... } // конкретная реализация включения
    virtual void trun_off() { ... } // конкретная реализация выключения
    virtual void set_rotary_speed(int x) { ... } // конкретная реализация управления скоростью

private:
     ... // частные свойства коллекторного двигателя
};

class TBrushlessMotor : public TMotor { .... };  // всё по аналогии
class TAsychronuosMotor : public TMotor { .... };  // всё по аналогии
...

// использование
TCommutatorMotor Motor1;
TCommutatorMotor Motor2;
...
TBrushlessMotor Motor5;
...
TAsychronuosMotor Motor11;
...
// и т.д.

TElectricalMachine *Machines[] =
{
    &Motor1,
    &Motor2,
    ...
    &Motor5,
    ...
    &Motor11,
};
...

for(int i = 0; i < sizeof(Machines)/sizeof(Machines[0]); ++i)
{
    Machines[i]->turn_on();  // включить все машины, каждая включается по-своему
}

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

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

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

Лично я считаю, что для управления реальными объектом, искусственный промежуточный программный объект не нужен.

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

[sasamy]

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

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

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