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

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

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

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



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

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

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

Сообщение отредактировал neiver - Dec 23 2011, 10:48

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

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

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

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

http://www.boost.org/

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

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



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

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

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

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

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

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

Встречный вопрос.
Сколько потребуется Ваших вопросов, чтобы Вы смогли приступить к созданию класса?
Лично я считаю, что для управления реальными объектом, искусственный промежуточный программный объект не нужен.
Иначе это дело разрастется в систему классов, подобную той, что нужна для 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 ?
В общем кому нужен С++ - используйте на здоровье - мне он не нужен, может только иногда

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