Arduino.ru

а, дуино тут при чём?

Неправильно понимаете. В ардуино используется полный (от слова "совсем полный") язык С++. Всё, что в нём есть, всё есть и "в ардуино".

Не надо меня пугать. Вроде есть и работает.

class Cl_basic {
  public:
    virtual void setup() = 0;
    virtual void loop() = 0;
};
class Cl_led:  public Cl_basic {
    bool led;
    byte pin;
    uint32_t past;
  public:
    Cl_led(byte _pin): pin(_pin) {}
    virtual void setup() {
      pinMode(pin, OUTPUT);
      past = millis();
      digitalWrite(pin, led = 0);
    }
    virtual void loop() {
      if (millis() - past >= 300) {
        past = millis();
        digitalWrite(pin, led = !led);
      }
    }
};
//------------Компоновка-----------------
Cl_led *LED = new Cl_led(/*нога*/13);
Cl_basic *BASIC = (Cl_basic*)LED;

//-------------main()-------------------
void setup() {
  BASIC->setup();

}

void loop() {
  BASIC->loop();
}

Да, виноват, неверно выразился... У меня же шаблонные функции. Шаблонная функция не может быть виртуальной. Нужен именно механизм полиморфного вызова шаблонных функций.

Простите что влезаю... но мне почему-то кажется, что вы что-то неправильно делаете, коли вам на Ардуино с ее количесвом памяти понадобились шаблонные функции.

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

class Cl_basic {
  public:
    virtual void setup() = 0;
    virtual void loop() = 0;
};

template <class T> class Cl_led:  public Cl_basic {
    bool led;
    byte pin;
    uint32_t past;
  public:
    T obj;
    Cl_led(byte _pin, T _obj): pin(_pin), obj(_obj) {}
    virtual void setup() {
      pinMode(pin, OUTPUT);
      past = millis();
      digitalWrite(pin, led = 0);
    }
    virtual void loop() {
      if (millis() - past >= 300) {
        past = millis();
        digitalWrite(pin, led = !led);
      }
    }
};
//------------Компоновка-----------------
Cl_led<int> LED(/*нога*/13, 5);
Cl_basic *BASIC = (Cl_basic*)&LED;

//-------------main()-------------------
void setup() {
  BASIC->setup();

}

void loop() {
  BASIC->loop();
}

Вообще-то ООП эффективно и на Ардуино. Но другое дело, что люди использующие ООП , привыкли не экономить память. Это как мажора заставить жить как обычный человек, все равно спустит все в первый же день.

qwone, красиво - а смысл? _obj нигде не используется

qwone, это понятно. нужно что-то типа

class T0{
  public:
  template<typename...Args>
  void foo(Args...args){/*ничего не делаем*/;}
}
class T1:public T0{
  public:
  void foo(int& a){/*делаем раз*/;}
}t1;
class T2:public T0{
  public:
  void foo(int i, vloat b){/*делаем два*/;}
}t2;
void setup() {
  T0* t01=&t1;
  T0* t02=&t2;
  t01->foo(99);//делаем раз
  t01->foo(0, .3);//ничего не делаем
  t02->foo(99);//ничего не делаем
  t02->foo(0, .3);//делаем два
}

void loop() {}

Не только память. Иногда результаты работы ООП оказываются, так сказать, зафиксированными в хардкоре. Например EMF файлы в винде. Программы разных производителей используют для создания EMF одну и ту же библиотеку GDI от MS. Но внутри файла сразу видно, где люди бездумно использовали ООП, а где думали головой. Размер файла с одной и той же картинкой может отличаться на порядок. Они даже на принтере печатаются с разной скоростью :)

В среде Ардуино  две эти строки надо писать одной строкой
template<typename...Args>
void foo(Args...args){/*ничего не делаем*/;}

template<typename...Args> void foo(Args...args){/*ничего не делаем*/;}

Вот така х..я малята.

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

  Это так преамбула. Даже Си++ уже исчерпало себя. Пришла эра Графических Интерфейсов. А без ООП создание их геморойная задача. Вот только ООП мало кто понимает. Я тоже . Да и что такое ООП именно в коде не описывается. 

   Так что если хотите что то путное сделать на Ардуине, нужно применять ООП. Даже если какжется что без него проще.

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

Примерчик из векторной графики, из опыта - так для развлечения.

Скажем, класс "буква", метод "напечатать букву"

1. выбрать канвас
2. инициализировать перо (толщину, цвет)
3. инициализировать фонт
4. переместить перо в точку х.у
5  нарисовать букву (!!!)
6. деинициализировать перо и фонт

... а теперь класс "строка", метод "напечатать строку" - думаю, уже все догадались...

For "каждая буква" do напечатать_букву...

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

class T0{
  public:
  template<typename...Args>
  void foo(Args...args){/*ничего не делаем*/;}
}
class T1:public T0{
  public:
  void foo(int& a){/*делаем раз*/;}
}t1;
class T2:public T0{
  public:
  void foo(int i, vloat b){/*делаем два*/;}
}t2;
void setup() {
  T0* t01=&t1;
  T0* t02=&t2;
  t01->foo(99);//делаем раз
  t01->foo(0, .3);//ничего не делаем
  t02->foo(99);//ничего не делаем
  t02->foo(0, .3);//делаем два
}

void loop() {}

Шаблоны я языке Си не могут быть виртуальными https://goo.gl/2dwsCj

Так и есть. Я делал разбор вектора на языке без ООП - все равно фактически пришлось создавать обьекты в виде структур, из них связанные списки... (цепочки), потом связанные списки цепочек :)  - иначе жуть.

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

Забавно, что Микрософт даже запатентовал "метод оптимизации метафайлов" - заключающийся в удалении из кода тысяч ненужных инструкций повторной инициализации одинаковых обьектов :)

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

Ну, Вы только в начале пути. Поговорим через полгода - не раньше.

Итак, для каждого типа-наследника RunnableInterface генерируется собственная реализация Run_T, указатель на которую сохраняется в m_pfnRun_T. Тут всё просто и понятно. Если мы переходим к шаблонному описанию параметров siRun и, соответственно, Run_T, то одного указателя m_pfnRun_T нам уже явно недостаточно, т.к. для каждого отнаследованного класса будет уже несколько перегрузок Run_T, на все из которых нам нужны указатели. И эти указатели нам надо:

1. Получить.

2. Сохранить в какой-то структуре данных (какой?)

3. Исходя из параметров шаблона

template<typename R, typename...Args>
R siRun(Args...args)

реализовать выбор нужного указателя из контейнера (как?)
 

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

Кроме того, "как сделать" - неконкретный вопрос. Вот, мне нужна программа для управления буровой вышкой. Ответьте-ка мне "как сделать?"

И ещё, если Вы думаете. что когда я писал

Там, выше http://arduino.ru/forum/programmirovanie/polimorfizm-v-arduino#comment-2... я давал пример кода, к которому стремлюсь. Видимо, он потонул во флуде и вы его не заметили.

Сейчас это реализуется вот таким вот примерно костылем:

enum mytypeid{
  typeT0,
  typeT1,
  typeT2
};
class T0{
  public:
  mytypeid t_id;
  T0():t_id(typeT0){}
  T0(mytypeid id):t_id(id){}
  template<typename...Args>
  void foo(Args...args){Serial.println("calling T0");}
};
class T1:public T0{
  public:
  T1():T0(typeT1){}
  void foo(int a){Serial.println("calling T1");}
}t1;
class T2:public T0{
  public:
  T2():T0(typeT2){}
  void foo(int i, float b){Serial.println("calling T2");}
}t2;
void setup() {
  Serial.begin(9600);
  T0* arr[] = {&t1, &t2};
  const int elems = sizeof(arr)/sizeof(*arr);
  for(int i = 0; i < elems; i++)
    if(arr[i]->t_id==typeT1)
      (static_cast<T1*>(arr[i]))->foo(99);
    else
      arr[i]->foo(99);
  for(int i = 0; i < elems; i++)
    if(arr[i]->t_id==typeT2)
      (static_cast<T2*>(arr[i]))->foo(0, .3);
    else
      arr[i]->foo(0, .3);
}

void loop() {}

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

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

Почтайте более позднюю приписку в моём предудущем посте

В общем, почитал Уилсона и Александреску, покурил интернеты, побился головой о стену и пришел к выводу, что без rtti задача не решается. Ну, то есть, не решается иначе как через switch-case... Жаль.

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

Что было. Головой о стену - это несколько тупиковых попыток получить информацию о типе объекта в рантайме. Но не вышел каменный цветок...

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

ПС. К полиморфизму это разумеется не относится. 

Кто-то или что-то мешает сделать функцию с неопределённым набором параметров? Неужели ОН уже и это запретил?

он тихо жрёт попкорн и акуевает.

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

Так попробуйте, делов-то. нормально он передаётся.

так тот код вобще мало чем интересен, у вас if (arr[i]->t_id==typeT1)  и т.д. прям в цикле висит, что совсем не по ООПшному  - инкапсуляция нарушена, только обект должен знать свои обрабатываемые  id событий (кстати в общем случае не одно id, например нажатие и отпускание кнопки - два разных события, но интересны могут быть одному обработчику) А при больше двух событиях  такой подход, как в #24 дает нежеланный вами свич.

Должно быть типа 

for(int i = 0; i < elems; i++)

Простой и элегантный - динамически распределяем структуру под параметры каждого события, передаем указатель на неё в foo как void* а внутри приводим как выше писал и освобождаем память после обработки события. Только не считайте что фрагментация кучи - только мелкие накладные расходы. Но вопрос таки пустяковый, т.к. много вариантов решения имеет. И все годные, хотя и с недостатками.