[xvr 12]

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

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

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

 

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

Потрудитесь книжки почитать

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

 

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

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

 

[sasamy 0]

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

 

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

 

либо с парой виртуальных функций

 

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

CMDLINE_DEVICE_CHOOSE(ssp1, mmc, spi1)

CMDLINE_DEVICE_CHOOSE(ssp2, nand_mfc, spi2)

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

[neiver 0]

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

CMDLINE_DEVICE_CHOOSE(ssp1, mmc, spi1)

CMDLINE_DEVICE_CHOOSE(ssp2, nand_mfc, spi2)

Если вы не знаете как это сделать красиво, просто и надежно - так и скажите. Это не значит что этого нельзя сделать вообще.

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

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

[sasamy 0]

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

 

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

[neiver 0]

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

Это зависит от критериев "ну совсем нафик не нужности". А это штука уж очень субъективная.

А если судить более-менее объективно, то имеем следущее:

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

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

- гибка и расширяема;

- не несет в себе каких либо нежелательных расходов;

- без нее можно, впринципе, обойтись с некоторой потерей безопасности и удобочитаемости.

- ее нужно знать.

 

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

[xvr 12]

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

Вам - не нужно. А вменяемые люди применяют :rolleyes:

в шаблонах вы дальше типов не уедете,

Да ну???

синтаксис вы не измените

До некоторой степени можно изменить.

и то что этот пример может и не совсем удачный ничего не меняет

Это точно, пока вы несете пургу и ни одного удачного примера не привели

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

Давайте, продемонстрируйте.

как ваш "тривиальный" класс превратится в месиво

То, что вы не знаете С++ мы уже поняли, зачем же об этом продолжать так надрывно кричать? :smile3046:

а у меня все будет как прежде ясно и кратко.

Да уж, макросы на пол-страницы - это 'ясно и кратко' :laughing:

 

[sasamy 0]

Это точно, пока вы несете пургу и ни одного удачного примера не привели

Давайте, продемонстрируйте.

 

http://www.boost.org/

[xvr 12]

http://www.boost.org/

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

 

[sasamy 0]

Это вы к чему?

 

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

 

Если вы не в курсе, то boost - это С++ библиотека, а не С

 

Об это даже в заголовке написано по ссылке - не думайте что все кругом совсем дебилы, по себе не судите. Я мог бы вам дать ссылки на исходники ядра Linux где макросы очень эффективно используются - вызововы syscall, микроассемблер для mips и проче но вы же ответите в своем стиле - я это напишу красиво - один класс с парой виртуальных ф-ций при этом не приводя ни строчки своего кода, поэтому я вам дал ссылку на библиотку С++ - можете начать отсюда

http://www.boost.org/doc/libs/1_48_0/libs/.../doc/index.html

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

[syv 0]

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

Ну я, конечно, не большой поклонник С++, но не настолько.

И вообще, есть целый класс задач и условий труда программиста, когда без ООП - никуда.

Мы это уже обсуждали, и тогда Вы меня убедили.

Тут уместно другое сравнение. Вот в С структуры уместно использовать?

...

Для работы со структурами используются функции...

...

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

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

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

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

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

Вот здесь мы и расходимся.

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

А это всего лишь часть задач, предлагаемых к решению.

И здесь, ПМСМ, кроется некое противоречие.

Любители ООП ломают задачу под себя.

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

При этом создается некая искусственная среда, зачастую включающая в себя ОС там, где это не является необходимостью.

А вот на этой благодатной почве и расцветают все кактусы.

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

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

А это для меня практически не осуществимо.

Есть иная концепция.

Когда программист приспосабливает вычислитель к реальным объектам без искусственной среды.

При этом считается, что каждый объект уникален.

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

Встречный вопрос.

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

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

Иначе это дело разрастется в систему классов, подобную той, что нужна для GUI.

[dxp 67]

Вот здесь мы и расходимся.

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

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

 

 

Встречный вопрос.

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

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

 

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

 

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 0]

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

 

Какое заблуждение. Взгляните на исходники какой-нибуть ОС

http://prex.sourceforge.net/src/S/252.html

 

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

[Flexz 0]

...можете начать отсюда

http://www.boost.org/doc/libs/1_48_0/libs/.../doc/index.html

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

 

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

[sasamy 0]

Остальные основаны на число плюсовых фишках.

 

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

 

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

 

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

В общем кому нужен С++ - используйте на здоровье - мне он не нужен, может только иногда :)

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