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

[_Артём_]

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

[neiver]

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

Сообщение отредактировал neiver - Dec 13 2011, 18:39

[_Артём_]

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

Не использовал пока динамическую память, нода смотреть как с этим в IAR AVR.

статический буфер достаточного размера, чтоб вместить самого большого наследника и placement new

Получается по смыслу что-то аналогичное Сишному union-у?

[neiver]

Получается по смыслу что-то аналогичное Сишному union-у?

Нет. Просто статически выделяется буфер в памяти и в нем конструируется (с помощью конструктора) объект нужного типа.

Код

char buffer[MAX_BUFFER_SIZE]; // static array
...
class Base{...};
class D1 :public Base {...};
class D2 :public Base {...};
class D3 :public Base {...};
...

Base *ProduceObject(ObjectType type)
{
   switch(type)
   {
       case Type1: return new (buffer) D1(); // creating an object using palcement new
       case Type2: return new (buffer) D2();
       case Type3: return new (buffer) D3();
   }
}

Да, еще возможно придётся определить оператор new если он еще не определен:

Код

void *operator new(unsigned int size, void* ptr)
{
    return ptr;
}

В этом операторе можно что-то сделать с буфером памяти, обнулить его, например, а можно ничего не делать.

Сообщение отредактировал neiver - Dec 13 2011, 19:38

[_Артём_]

Нет. Просто статически выделяется буфер в памяти и в нем конструируется (с помощью конструктора) объект нужного типа.

Код

char buffer[MAX_BUFFER_SIZE]; // static array
...
class Base{...};
class D1 :public Base {...};
class D2 :public Base {...};
class D3 :public Base {...};
...

Base *ProduceObject(ObjectType type)
{
   switch(type)
   {
       case Type1: return new (buffer) D1(); // creating an object using palcement new
       case Type2: return new (buffer) D2();
       case Type3: return new (buffer) D3();
   }
}

Да, еще возможно придётся определить оператор new если он еще не определен:

Код

void *operator new(unsigned int size, void* ptr)
{
    return ptr;
}

В этом операторе можно что-то сделать с буфером памяти, обнулить его, например, а можно ничего не делать.

Что-то всё равно не так.
Ввёл:

Код

char buffer[1000]; // static array

class Base {
public:
    unsigned int A;
    unsigned int N;
    void SetA(unsigned int a)
    {
        A=a;
    }
};
class D1 :public Base {
public:
    void *operator new(unsigned int size, void* ptr)
    {
    }
    void SetN()
    {
        N=0;
    }
};
class D2 :public Base {
public:
    void SetN()
    {
        N=1;
    }
};
class D3 :public Base {
public:
    void SetN()
    {
        N=2;
    }
};

Base *ProduceObject(unsigned char type)
{
    switch(type)
    {
    case 0: return new (buffer) D1(); // creating an object using palcement new
    case 1: return new (buffer) D2();
    case 2: return new (buffer) D3();
    }
}
int _tmain(int argc, _TCHAR* argv[])
{


    Base *p;
    p=ProduceObject(0);
    p->SetA(10);
}

Компилятор говорит:

error C2660: 'operator new' : function does not take 2 arguments

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

Что-то всё равно не так.

Так вы operator new объявили членом D2, а надо его сделать членом Base. А еще можно buffer и фабрику также спрятать внутрь base, сделав статическим членом и статической функцией соответственно.

[_Артём_]

Так вы operator new объявили членом D2, а надо его сделать членом Base.

Да, не заметил. Спасибо.

А еще можно buffer и фабрику также спрятать внутрь base, сделав статическим членом и статической функцией соответственно.

Попробую.

Проверял в Visual Studio (ничего другого под рукой нет).
Как считаете в IAR AVR так же всё будет работать?

[Danis]

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

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

[neiver]

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

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

[_Артём_]

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

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

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

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

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

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

[kolobok0]

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

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

(круглый)

[dxp]

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

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

[kolobok0]

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

для этого надо сначала понять, какие плюсы Вы видите в его использовании?

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

(круглый)
ЗЫ
Всегда надо идти от задачи. Лично мне не известны такие задачи где требуется си плас плас под МК. За исключением не анжинерных задач - типа попилить бабло. Но это мы не бум рассматривать надеюсь...

[Danis]

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

Разумеется типов, Вы же сами писали: "два-три близких по системе команд GSM-модема".

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

На чистом Си, нет никаких проблем.


Не хочу переводить тему в категорию Си vs C++. Сам пишу софт в основном для ПК, на С++. В микроконтроллере мне С++ понадобился 1 раз, кода писал приложение для TFT панели, писал свой GUI. Тут С++ со своими возможностями ООП ”рулит”.

[ReAl]

Лично мне не известны такие задачи где требуется си плас плас под МК.

Лично мне не известны такие задачи, где требуется что угодно, кроме текстового редактора (набирать вручную HEX-файлы). Этого, в принципе, достаточно. Мнемокод — уже счастье. Ассемблер, да если еще и с макросами — рай земной.

(«нужно человеку буханка хлеба и четверть ведра воды в день, всего остального ему хочется» © забыл чей)

[dxp]

для этого надо сначала понять, какие плюсы Вы видите в его использовании?

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

[Danis]

А ваши рассуждения можно легко распространить и на С - вон есть асм, зачем ещё какие-то Цэ. Кстати, такие холивары (асм vs C) весьма громко гремели лет 10 назад.

Согласен. Но думаю ТС тогда не нужно было вести речь о GSM модемах, а просто задать вопрос по ООП на С++: ”Как лучше объявить в программе переменную-наследника?” Тут все таки, ИМХО для ТС интересно обучение, нежели необходимость применения.
Рекомендую почитать Шилдт Г. C++. Наследование, полиморфизм, инкапсуляция.

[kolobok0]

...текстового редактора...

мы о конечной задачи. не теряйте фокус!!!

(круглый)

..облегчение как проектирования софта, так и написания кода....можно легко распространить и на С - вон есть асм, зачем ещё какие-то Цэ....

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

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

холивар не бум. ну его в баню.

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

(круглый)

[_Артём_]

Но думаю ТС тогда не нужно было вести речь о GSM модемах, а просто задать вопрос по ООП на С++: ”Как лучше объявить в программе переменную-наследника?”

Да, можно было спросить не о модемах, а о применении наследования, полиморфизма, инкапсуляции для IAR AVR. Но говорить о реальном примере как-то проще и понятнее.

Тут все таки, ИМХО для ТС интересно обучение, нежели необходимость применения.

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

Рекомендую почитать Шилдт Г. C++. Наследование, полиморфизм, инкапсуляция.

ИМХО, слишком абстрактно (даже для Windows, не говоря о МК).

проектирование - это ООА.

Это чё?(как расшифровываетсяв смысле?)

Минусов, на мой взгляд, гораздо больше.

Об чём и речь.Какие минусы?

И МК (чиссо мой взгляд) силён не тем, что можно и на нём "как у больших". А немного другим.

Чем?

холивар не бум. ну его в баню.

Это - да. Согласен. И не в баню, а ещё подальше.

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

Как вам удаётся на асм быстреё чем на Си?
Какие задачи?

[dxp]

проектирование - это ООА.

Не знаю, что это такое. Для меня проектирование - это создание "каркаса" программы, определение основных типов, их интерфейсов и взаимодействия. И тут С++ на три головы выше С и на 10 голов выше асма. Благодаря нативной поддержке объектной парадигмы.

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

про азм и си под МК... не знаю, что даже ответить. чисто по мне - просче и быстрее на азме(повторюсь - для МК). но тут кому как...

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

у азма всегда был и останется один большой плюс, на мой взгляд:
Что написал - сам дурак(С)

Это субъективные страхи. Давным давно уже ситуация такова, что 99 целых и 9 в периоде процентов ошибок содержатся в пользовательском коде, я уже и забыл, когда находили более-менее серьёзный баг у компилятора. А если не доверять программным инструментам, то вообще всё надо делать без компа - ведь и САПР печатных плат тоже может в герберах накосячить.

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

У меня немного другой взгляд. Задач много, а времени мало, поэтому тратить его на написание низкоуровневого кода, который едва ли лучше по качеству, чем кодогенерация с ЯВУ, слишком расточительно. Ну, и оформление алгоритмических идей на основе языковых концепций, предоставляемых ЯВУ, лично мне доставляет эстетическое удовольствие. Т.е. совмещаем полезное с приятным.

[Iptash]

С++ я бы сказал совершенно другой, отличный от С язык. Я раза три пытался вникнуть в него, 2,3 страницы чтения и все, мозги просто отказываются понимать(честное слово). Все
же автор больше математик нежели программист и С++ скорее не язык программирования, а язык создания классов, обьектов и т.п.. Все это лишь мое сложившее мнение, не более.

[dxp]

С++ я бы сказал совершенно другой, отличный от С язык. Я раза три пытался вникнуть в него, 2,3 страницы чтения и все, мозги просто отказываются понимать(честное слово). Все
же автор больше математик нежели программист и С++ скорее не язык программирования, а язык создания классов, обьектов и т.п.. Все это лишь мое сложившее мнение, не более.

Тогда С - язык создания процедур. На самом деле вы, конечно, правы - при всём внешнем сходстве между С и С++ это весьма разные языки. Точнее, С++ может "мимикрировать" под С, но смысла в этом немного. Чтобы понять С++ надо начать немного по-другому думать. Перейти от оперирования обилием переменных и функций, работающих с ними, к оперированию законченными объектами - аналогами объектов внешнего мира. Жизнь сразу приобретёт новые краски. Наверное, вам имеет смысл познакомиться с фундаментальной работой тов. Г.Буча "Объектно-ориентированный анализ и проектирование", отличная книжка, хотя она, можно сказать, не столько о само ЯП С++, сколько о подходах. Имхо, маст рид. Книжка легко доступна в интернетах: например тут или тут.

[Iptash]

... Наверное, вам имеет смысл познакомиться с фундаментальной работой тов. Г.Буча "Объектно-ориентированный анализ и проектирование", отличная книжка, хотя она, можно сказать, не столько о само ЯП С++, сколько о подходах. Имхо, маст рид. Книжка легко доступна в интернетах: например тут или тут.

Спасибо, буду читать.

[kolobok0]

...Это чё?(как расшифровываетсяв смысле?).....

я лучше дальше помолчу господа ))

Не знаю, что это такое. Для меня проектирование - это создание "каркаса" программы, определение основных типов, их интерфейсов и взаимодействия....

весело с вами господа! вот ратуете за юзанье ОО инструментария, а об основах элементарных не в курсе.

рекомендую альма матер учения по ОО:

Гради Буч
Объектно-Ориентированный Анализ и Проектирование

объясняю.
термины
ООА = Объектно Ориентированный Анализ
ООП = Объектно Ориентированное Проектирование

(круглый)
ЗЫ
а то как то расуждать-рассуждаете, а элементарных вещей не знаете.
ЗЫ ЗЫ
плюсы данного подхода апсолютно не в типизации и иже. И (о ужас!!!) даже не в си плас плас )) Точнее скажем так - язык записи логики работы - вторичен.

[haker_fox]

весело с вами господа! вот ратуете за юзанье ОО инструментария, а об основах элементарных не в курсе.

ООА = Объектно Ориентированный Анализ

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




Себе купил недавно эту книгу. Хотелось именно автора Си++ почитать. Пока только положительные эмоции)))

[dxp]

я лучше дальше помолчу господа ))

весело с вами господа! вот ратуете за юзанье ОО инструментария, а об основах элементарных не в курсе.

рекомендую альма матер учения по ОО:

Гради Буч
Объектно-Ориентированный Анализ и Проектирование

Правда? Ой, спасибо большое, практически спасли дураков от невежества. Правда, чукча, видимо, не читатель, по крайней мере, не читатель поста №22 (особенно, последних двух предложений) этой темы.

объясняю.
термины
ООА = Объектно Ориентированный Анализ
ООП = Объектно Ориентированное Проектирование

ООА - очень неупотребительная аббревиатура. Я её не встречал со времён, когда ознакомился с трудом Г.Буча, это было порядка 10 лет назад. Поэтому ни разу не странно, что люди не догадались, что там некий автор имел в виду (а телепаты, как всегда, в отпуске). Гораздо более употребительная аббревиатура - ООП, тем более, что и речь шла о проектировании. Кстати, не об ОО проектировании, а вообще. Или для вас С++ == ООП?

ЗЫ
а то как то расуждать-рассуждаете, а элементарных вещей не знаете.
ЗЫ ЗЫ

Да, тут есть у нас участники, которые любят порассуждать абстрактно, сыпать малоупотребительными терминами, но не приводят ни одного конкретного примера, хотя дискуссия с ними и началась именно с просьбы показать эти гадкие, негодные средства С++, которые делают жизнь на МК невыносимой. Это вызывает подозрения, что оные аффтары ничем, кроме устаревших лет 10 назад стереотипов, не обладают (наверное, это очень помогает писать ООА/ООП программы на ассемблере).

плюсы данного подхода апсолютно не в типизации и иже. И (о ужас!!!) даже не в си плас плас )) Точнее скажем так - язык записи логики работы - вторичен.

Вот ещё образчик чего-то такого глубокомысленного, что по доступности граничит с потоком сознания. О конкретике уже и речи нет.

[kolobok0]

..спасибо большое..

пожалуйста!!! Вы спрашивали )) а посты ваши были потом...

ООА - очень неупотребительная аббревиатура...Гораздо более употребительная аббревиатура - ООП, тем более, что и речь шла о проектировании...

вообщето перед тем как что то Проектировать надо Анализировать. Опять открыл(наверное) для вас америку? )) не верю. наверное просто забыли... ну или опять лукавите )) ну да лано. оставим на вашей совести...

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

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

...О конкретике уже и речи нет.

Что конкретного Вы хотите видеть? конкретика - то уже по задаче. Вы хотите меряться пиписьками или задачами? Вы случаем не дохтуртумас или как там?

с уважением
(круглый)
ЗЫ
Прям как дети - ей богу...

..Но это, как минимум, не скромно...Никто не может знать все...Себе купил недавно..

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

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

удачи вам
(круглый)

PS
Если речь уже перешла в слив не о чём - то считайте меня эээээээ плохим человеком.
Я заткнулся... Ведь от этого мои знания не уменьшатся ))) (С)

Сообщение отредактировал kolobok0 - Dec 19 2011, 09:11

[sonycman]

Если речь уже перешла в слив не о чём - то считайте меня эээээээ плохим человеком.
Я заткнулся... Ведь от этого мои знания не уменьшатся ))) (С)

Да всё уже ясно с Вами. Пришли, ляпнули ни о чём, не приведя ни одного конкретного примера, нахамили уважаемым людям и свалили

[sasamy]

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

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

[dxp]

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

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

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

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

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

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

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

[sasamy]

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

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

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

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

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

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

[haker_fox]

Господа, может быть не будем заниматься поддержанием многовекового холивара C vs. C++? :-) Пусть каждый выберет себе язык программирования, или пусть пишет сразу в машинных кодах. Главное, чтобы ему удобно было)

[demiurg_spb]

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

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

[sasamy]

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

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

[demiurg_spb]

При чём здесь это?
Как часто принимаются новые стандарты с++?
Как они повлияли на необходимость смены технологии и как следствие была-ли велика потребность в изучении лишнего-ненужного материала?

[ViKo]

Я не знаю языка C++, хотя и прочитал Г. Шилдта до половины. Без практики знаниями не запасешься. Но знаю точно, что рано или поздно перейду на него. Возможно, к тому времени появится новый язык, возможно, он уже есть. Снова буду догонять. Мир становится сложнее, задачи становятся сложнее, и для решения этих задач нужно применять соответствующие инструменты.

[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.

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

Применительно к данной теме - зачем тут виртуальные ф-ции когда можно сделать простой switch/case ?

А не зае**тесь сначала множить switch/case там, где должен быть вызов виртуальной функции, а потом шерстить весь код, чтобы найти все switch и не забыть в какой-нибудь из них добавить очередной case?

[ViKo]

А не зае**тесь сначала множить switch/case там, где должен быть вызов виртуальной функции...

А я вот сделал несколько массивов указателей на функции, и не зае**лся. Или это не про то речь?

[dxp]

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

Общеизвестный факт конкретно о чём? А я про порядки спрашивал. Сколько порядков и как это определить? Например, насколько сложнее написать С++ класс по сравнению с С структурой? Конкретный вопрос. На сколько порядков?

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

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

Вы хотите конкретики? На какие темы из С++? Про отделение интерфейса от реализации и построение кода по более безопасной модели (классы и инкапуляция и абстракция данных) надо рассказывать? А про возможность быстро, просто и безопасно расширять функциональность объектов путём повторного использования кода (наследование) надо рассказывать? А про параметризованные типы, когда можно, например, получить кольцевой буфер для uint8_t, а можно для float или вообще структур:

ring_buffer<uint8_t, 32> TxBuf;
ring_buffer<float, 10> DataPool;

надо рассказывать? Мне вот думается, что нет, т.к. по вашим постам я знаю, что вы далеко не новичок в нашем деле и должны прекрасно знать эти возможности и их преимущества. Надеюсь, не нужно доказывать, что это простые и полезные средства языка, практически не тянущие оверхеда, весьма кстати при разработке софта в том числе и на МК. ЯП С не даёт ничего похожего. При той же реализации кольцевых буферов, это придётся в каждом случае делать руками со всеми вытекающими (трудозатраты, ошибки), а тут можно хоть структуры метать или типизированные указатели (а не void*).

какой рукой удобней ложку держать. Применительно к данной теме - зачем тут виртуальные ф-ции когда можно сделать простой switch/case ?

Про это мне не известно, это автор темы знает, что ему лучше подходит. Но вообще-то там вопрос был не о способе выбора, а о размещении реализации. Симпатичное, ПМСМ, решение было предложено с буфером и placement new. Кстати, именно вместе со switch.

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

Куда более феерично заявлять, что без метапрограммирования и ООП это уже не С++. Я вам выше привёл основные средства языка, они покрывают 90% потребностей программ для МК и отлично работают.

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

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

А я вот сделал несколько массивов указателей на функции, и не зае**лся. Или это не про то речь?

Речь была о switch/case:

зачем тут виртуальные ф-ции когда можно сделать простой switch/case ?

А вам три вопроса:
1) А как, по-вашему, реализованы виртуальные функции в плюсах?
2) А не зае**тесь ползать по своим массивам добавляя новые/удаляя ненужные функции? Попутно: не боитесь добавить новую функцию не в ту ячейку массива или удалить не ту функцию?
3) Ну и ради чего этот закат солнца вручную, если в плюсах такой же механизм реализуется в виде виртуальных функций автоматически, без лишней писанины и без опасности глупых ошибок/опечаток?

[ViKo]

А вам три вопроса:
1) А как, по-вашему, реализованы виртуальные функции в плюсах?
2) А не зае**тесь ползать по своим массивам добавляя новые/удаляя ненужные функции? Попутно: не боитесь добавить новую функцию не в ту ячейку массива или удалить не ту функцию?
3) Ну и ради чего этот закат солнца вручную, если в плюсах такой же механизм реализуется в виде виртуальных функций автоматически, без лишней писанины и без опасности глупых ошибок/опечаток?

Если это ко мне вопросы, то:
1) Я плюсов не знаю, увы мне!
2) За..трахивало маленько, но у меня был план (макет, шаблон, стиль?), которого придерживался. Все более-менее структурировано. Мимо не промахивался.
3) Я плюсов не знаю, увы мне!
P.S. Намекните, кто-нибудь, что это такое, виртуальные функции?
upd. Сам прочитал.

[haker_fox]

1) А как, по-вашему, реализованы виртуальные функции в плюсах?

А я как раз сегодня про это читал у Страутстрапа Через таблицу указателей...

[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.

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

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

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

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

[Flexz]

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

Может приведете конкретные примеры этих многих случаев? Было бы очень интересно почитать.

[sasamy]

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

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

[haker_fox]

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

Это точка зрения одного человека. Она может быть ошибочной, а может быть правильной. На самом деле он прав! Только правда у каждого своя. Зачем навязывать правду? Делится ее - пожалуйста, навязывать не надо.

Про навязывание, это я не Вам, уважаемый sasamy

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

Вот это да... А это что же тогда? Там есть раздел про Си++.

[Flexz]

Видимо, он имел ввиду единый, общий для разных компиляторов name mangling. Он же не стандартизован и все компиляторы делают его по своему, хотя за последний стандарт языка не знаю.

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

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

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

[dxp]

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

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

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.

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

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

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

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

CODE

void send(char x) { TxBuf.push(x); TxBuf.send(sizeof(x)); }
void send(uint16_t x)
{
    TxBuf.push(x);
    TxBuf.push(x>>8ul);
    TxBuf.send(sizeof(x));
}
...
char S;
uint16_t Slon;
...
send(Slon);
...
send(S);

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

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

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

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

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

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

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

[XVR]

Кстати у C++ нет ни единого ABI ни name mangling,

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

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

[sasamy]

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

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

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

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

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

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

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

[kolobok0]

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

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

[XVR]

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

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

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

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

[haker_fox]

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

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

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

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

[ReAl]

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

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

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

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

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

Код

extern volatile unsigned char some_port;
...
void foo()
{
    ...
    some_port;  // <---- вот этой строки
    ...
}

но то скорее изменение поведения, чем функционала.

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

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

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

[dxp]

И тогда же кто-то хорошо сказал (или процитировал) приблизительно такое:

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

[sasamy]

А дальше — когда «большой» инструмент уже есть

u

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

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

[ReAl]

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

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

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

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

[sasamy]

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

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

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

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

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

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

[ReAl]

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

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

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

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

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

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

[toweroff]

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

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

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

[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

[neiver]

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

[Genadi Zawidowsk...]

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

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

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

автор - я.

[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% именно средствами языка.

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

[ViKo]

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

[sasamy]

Эти возможности успешно заменяют макросы и превосходят их в 99% случаев.

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

Код

#define CMDLINE_DEVICE_CHOOSE(name, dev1, dev2)                 \
        static char *cmdline_device_##name;                     \
        static int cmdline_device_##name##_setup(char *dev)     \
        {                                                       \
                cmdline_device_##name = dev + 1;                \
                return 0;                                       \
        }                                                       \
        __setup(#name, cmdline_device_##name##_setup);          \
        void mx23_init_##name(void)                             \
        {                                                       \
                if (!cmdline_device_##name ||                   \
                        !strcmp(cmdline_device_##name, #dev1))  \
                                mx23_init_##dev1();             \
                else if (!strcmp(cmdline_device_##name, #dev2)) \
                                mx23_init_##dev2();             \
                else                                            \
                        pr_err("Unknown %s assignment '%s'.\n", \
                                #name, cmdline_device_##name);  \
        }

CMDLINE_DEVICE_CHOOSE(ssp1, mmc, spi1)

Т.е. опять всё наоборот: заявлено, что в С макросы - могущество, а в С++ - геморрой

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

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

[Прохожий]

....

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

[dxp]

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

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

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

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

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

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

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

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

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

[XVR]

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

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

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

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

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

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

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

[sasamy]

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

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

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

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

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

[neiver]

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

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

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

[sasamy]

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

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

[neiver]

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

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

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

[XVR]

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

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

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

Да ну???

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

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

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

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

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

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

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

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

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

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

[sasamy]

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

http://www.boost.org/

[XVR]

http://www.boost.org/

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

[sasamy]

Это вы к чему?

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

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

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

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

[Прохожий]

Это вряд ли. Скорее это зависит соотношения "сложность задач/доступные ресурсы (время/трудоёмкость). Попробуйте, например, 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

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

[Flexz]

...можете начать отсюда
http://www.boost.org/doc/libs/1_48_0/libs/.../doc/index.html

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

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

[sasamy]

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

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

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

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

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

[Flexz]

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

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

Одного мало ?

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

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

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

[XVR]

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

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

Об это даже в заголовке написано по ссылке - не думайте что все кругом совсем дебилы,

я не думаю, что все. Пока вы один тут клоуном выступаете

Я мог бы вам дать ссылки на исходники ядра Linux

Не надо, я знаю, где ядра лежат

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

Мы вроде про С++ говорили, а не про макросы?

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

Все ядро Linux написано в ООП стиле. А то, что не на С++ объясняется исключительно идеосинкрозией Торвальдса на С++

при этом не приводя ни строчки своего кода,

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

поэтому я вам дал ссылку на библиотку С++ - можете начать отсюда

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

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

Код

template<class Dev1, class Dev2>
class CmdLineDevChoise {
Dev1 dev1;
Dev2 dev2;
public:
void init()
   {
    char* name=get_cmd_line_device_name();
    if (strcmp(name,dev1.get_name())==0) dev1.init(); else
    if (strcmp(name,dev2.get_name())==0) dev2.init(); else
     abort();
   }
};

// Usage:
CmdLineDevChoise<MmcDev,SPI1Dev> ssp1;

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

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

[sasamy]

проявляя при этом невежество, упертость и хамство

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

[XVR]

Это вы о себе ?

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

И не боюсь я ваших бананов

Это модераторам решать

[Прохожий]

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

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

Дык задал уже все вопросы в прошлый раз. Для...

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

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

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

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

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

[sasamy]

Не надо, я знаю, где ядра лежат

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

А то, что не на С++ объясняется исключительно идеосинкрозией Торвальдса на С++

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

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

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

[neiver]

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

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

[sasamy]

Очень типичная такая задача кодогенерации, надо например, короткую задержку NOP-ами сделать

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

Я вам потом покажу, если захотите, как это делается на препроцессоре и на шаблонах. Будет возможность сравнить.

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

[dxp]

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

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

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

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

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

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

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

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

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

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

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

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

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

[neiver]

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

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

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

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

Код

template<unsigned N> inline void Nops()
{
    asm volatile("nop");
    Nops<N - 1>();
}
template<> inline void Nops<0>(){}

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

Код

Nops<10>();

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

Код

void
_delay_loop_1(uint8_t __count)
{
    __asm__ volatile (
        "1: dec %0" "\n\t"
        "brne 1b"
        : "=r" (__count)
        : "0" (__count)
    );
}

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