Arduino.ru

обяви в родительском классе абстрактные виртуальные функции start() и end(), а реализацию их напиши в override дочерних классах.

Вопщем, много читай. 

делай так

class Work
{
  void prn(char* c){Serial.println(c);}
public:
  virtual void start(void)=0; 
  virtual void end(void)=0; 

protected:  
  virtual void print(char* c){prn(c);}
};

class Teacher : public Work
{
  void start(void){print("Teacher start");} 
  void end(void){print("Teacher end");}  
  
};

class Driver : public Work
{
  void start(void){print("Driver start");} 
  void end(void){print("Driver end");}  
  void print(char* c){Work::print(">>>>>");Work::print(c);Work::print("*****");}  
};


void setup() {
  // put your setup code here, to run once:
 Work* w;
 Teacher T;
 Driver D;
 
 Serial.begin(9600);

 w=&T;
 w->start();

 w=&D;
 w->start();

}

void loop() {
  // put your main code here, to run repeatedly:

}

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

выводит в порт

Спасибо!

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

вызовет критическую ошибку при исполнении или пойдет на пустой цикл?

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

не обязательно абстрактные, главное чтоб виртуальные.

Не думай о виртуальных функциях как о чем то не знакомом тебе! Это все те же указатели на функцию, только красиво, как просил. И св-ва их такие же. Каждый потомок  переопределяет их - всего лишь присваивает свой указатель на свою функцию. Если не переопределял - останется значение от последнего в иерархии присвоившего. Если указатель объявили но он 0 - абстрактный класс, вызов даст ошибку. Так что думай о виртуальных как о указателях на функцию и вопросов не будет. Но с виртуальными нельзя делать все что можно с указателям. Указатели на функцию куда более мощные, а значить и опасные. Потому их и "притупили" и в ООП обернули, чтоб недоумки реже ошибались. 

тоже вопрос по наследованию, раз уж ТС начал

Допустим, я хочу создать свой класс Child, производный от какого-то стороннего класса Base., при этом хочу переопределить в новом классе метод print(). который, к сожалению, в базовом классе не описан как виртуальный.

#include <stdio.h>
class Base {
 public:
     void func1() {print();};
     void print() {printf("base class \n");};
};

class Child: public Base {

public:
     void func3() {print();};
     virtual void print() {printf("child class \n");};
};


int main() {
Child pi;
printf("func3 use print()from ");
pi.func3();
printf("func1 use print()from ");
pi.func1();
}

В итоге имеем ситуацию, что когда метод print() вызывается методами класса Child - вызывается новый метод, а когда вызов происходит из методов класса Base - то и print() вызывается тоже "старый"

как иллюстрация - вышеприведенный код печатает:

func3 use print() from child class 
func1 use print() from base class 

Вопрос - можно ли решить проблему ( чтобы всегда вызывался метод Child::print()) без изменения класса Base?

что пробовал

 попытка переопределить базовый метод при помощи using как приватный:

class Child: public Base {
private:
   using Base::print;

public:
     void func3() {print();};
     virtual void print() {printf("child class \n");};

};

ни на что не влияет.

Попытка вовсе вычистить его с помощью delete не компилируется:

class Child: public Base {

public:
     void func3() {print();};
     virtual void print() {printf("child class \n");};

     void Base::print() = delete;
};

Нельзя.

нет

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

Как говорится: "это не бага, это - фича".

//Как говорится: "это не бага, это - фича".

Даже хуже. Это архитектура. Некоторые разработчики, особо сволочные ;) , еще и имеют наглость писать private. И это в исходниках на моем то компе! Но мы же не дети. Раз исходник найден - то private там или нет уже не важно ))) 

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

Спасибо мужики

эээээ.....

а поговорить?

да о чем тут говорить? :) - я и сам знаю, как это делать правильно - добавить в базовый класс спецификатор virtual для метода print()

Но в моем случае базовый класс - это чужая библиотека, и хотелось бы обойтись без ее модификации. Надеялся - а вдруг есть какой хитрый способ? :)

Тута, кроме virtual есть еще одна хитрость.  Если у тебя в родительском классе есть виртуальная функция, например 

virtual void TSensor::Error(int);

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

void TAnalogSensor::Error(int8_t); 

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

void TAnalogSensor::Error(int); override; 

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

модификация сводится к одному слову virtual, и перемещению этого обьявления в секцию protected (если она была в private).  :) 

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

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

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

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

натолкнулся на интересный "глюк" компилятора (Visual Studio Code), чуть голову не сломал (ответ будет ниже, для тех кто захочет сам понять проблему)
код компилируется без ошибки:

при нажатии '#' происходило переключение на следующий пункт меню (cur_menu становилось равно 1), но тут же сбрасывалось в начало (0)

Решение:

#################################################

В завершении не стоит break

case 0: ;

Почему переменная сбрасывалась???

или вся программа уходила в начало и переменные инициализировались??

sturmber, скорее всего это, как часто бывает, не глюк компилятора, а глюк программиста. Но понять что происходит по куску кода невозможно. Если бы Вы привели полный пример (как можно более короткий, но чтобы проблема оставалась), можно было бы посмотреть и подумать.

Так-то на первый взгляд, всё логично. Если нажата "#", то cur_menu становится 1, а если потом не нажато ничего,  то в строке №ХЗ выполняется --cur_menu и она снова становится нулём. А Вы чего-то другого ожидали?

(Кстати, о "строке №ХЗ" - ЗАДОЛБАЛИ!!! Вставляйте же, наконец код правильно!!!)

неожиданно, что компилятор пропустил без ошибки

думал, это обязательная структура - завершить case .. break

Читать надо больше

Именно!

sturmber - отсутствие break в case - это не баг, а фича, используемая для обьединения веток switch.

я правильно понимаю логику оператора switch..case:
программа сравнивает с первым case, если соответствует, то исполняет его и если доходит до ещё одного case, то опять сравнивает...
если не соответствует, то переходит к следующему case

если приэтом в ходе выполнения доходит до break, то происходит выход из блока switch

1) параметр условия case - могут быть только константы?
2) параметр switch передается переменная и она (условие выборки) в ходе выполнения блока может меняться?

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

1) да, только константы

2) нет, не может, используется то значение, которое было на момент вызова оператора

в следующем кейсе уже ничего не сравнивается, все последующие кейсы выполняются, пока не встретится break

Рецидивист, однако :(((