Зачем нужны виртуальные функции если есть перегрузка?

@SkYMaaN · Регистрация: 05.04.2019

Студворк — интернет-сервис помощи студентам

Есть следующий код:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#include <iostream>
using std::cout;
using std::endl;
class Gun
{
public:
    virtual void shoot()
    {
        cout << "Выстрел!" << endl;
    }
};
class SubmachineGun : public Gun
{
public:
    void shoot() override
    {
        cout << "Выстрел! Выстрел! Выстрел! Выстрел!" << endl;
    }
};
 
int main()
{
    setlocale(LC_ALL, "");
    Gun obj; obj.shoot();
    SubmachineGun obj1; obj1.shoot();
}

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class Gun
{
public:
    void shoot()
    {
        cout << "Выстрел!" << endl;
    }
};
class SubmachineGun
{
public:
    void shoot()
    {
        cout << "Выстрел! Выстрел! Выстрел! Выстрел!" << endl;
    }
};

Или даже перед таким кодом:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class Gun
{
public:
    void shoot()
    {
        cout << "Выстрел!" << endl;
    }
};
class SubmachineGun
{
public:
    void shoot(int count)
    {
        for (size_t i = 0; i < count; i++)
        {
            cout << " Выстрел!";
        }
    }
};

Прошу не бить меня палками, просто пытаюсь понять.

@oleg-m1973 · 16.09.2020, 12:05

Сообщение от JeyCi

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

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

@JeyCi · 16.09.2020, 12:08

вобщем над зависимостями - ещё подумать...

@oleg-m1973 · 16.09.2020, 12:09

Сообщение от JeyCi

вобщем над зависимостями - ещё подумать...

Это называется иерархия, а не зависимости

@JeyCi · 16.09.2020, 12:10

но конкретно по примеру - это просто его рацион - переобозвать класс Cachalot на CashalotMenu

@oleg-m1973 · 16.09.2020, 12:11

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

@JeyCi · 16.09.2020, 12:12

Сообщение от oleg-m1973

Это называется иерархия, а не зависимости

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

Добавлено через 29 секунд

Сообщение от oleg-m1973

Ошибки проектирования - самые дорогие ошибки.

IGPIGP · 16.09.2020, 12:22

Не по теме:

Сообщение от JeyCi

Спасибо

всё верно поняли. Надо мне было два разных наследника создать типа:

C++
1
2
3
4
5
6
7
BaseClass_obj *baseClass_obj_ptr ;
ChildClass childClass1_ob1 ;
ChildClass childClass2_ob2 ;
baseClass_obj_ptr = &childClass_ob1 ;
baseClass_obj_ptr ->virtual_method_of_concrete_child();
baseClass_obj_ptr = &childClass_ob2 ;
baseClass_obj_ptr ->virtual_method_of_concrete_child();

что и мыслилось, но писал без компиляции и был невнимателен. Каюсь)

@JeyCi · 16.09.2020, 12:47

Сообщение от JeyCi

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

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

Добавлено через 4 минуты

Сообщение от oleg-m1973

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

всё - поняла/вспомнила !! - стэк быстрый, но очень маленький - поэтому переходят на использование кучи...
попробую это "делать с умом":
1. располагать в куче не всё скопом (не всё MenuForCachalot, а только Food1 или Food2, когда что надо), что надо, например, на завтрак и т.д.!
2. И Удалять вовремя
- полагаю "с умом" - именно это имеет ввиду...
- спасибо!

@oleg-m1973 · 16.09.2020, 12:52

Сообщение от JeyCi

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

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

Сообщение от JeyCi

всё - поняла/вспомнила !! - стэк быстрый, но очень маленький - поэтому переходят на использование кучи...

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

IGPIGP · 16.09.2020, 13:08

Сообщение от JeyCi

всё - поняла/вспомнила !! - стэк быстрый, но очень маленький - поэтому переходят на использование кучи...
попробую это "делать с умом":

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

@JeyCi · 16.09.2020, 13:21

Не по теме:

Сообщение от oleg-m1973

но как-то здравый смысл не стоит отключать.

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

@JeyCi · 17.09.2020, 18:40

Сообщение от oleg-m1973

Без виртуальных методов функция WriteLog должна быть шаблонной,

это так что ли?

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#include <iostream>
 
class A
{
    public:
        std::ostream &Format(std::ostream &out) const { return out << "A !!!!";}
};
 
class B : public A
{
    public:
        std::ostream &Format(std::ostream &out) const { return out << "B !!!!";}
};
 
template <typename T> 
void WriteLog(T &obj)
{
    obj.Format(std::cout) << std::endl;
}
 
 
int main()
{
    A a;
    B b;
    WriteLog(a);
    WriteLog(b);
}

но const, наверно, всё-таки убрать?..
всё равно непонятно, зачем ещё и шаблон, если в каждом классе прописывать свой std::ostream& надо?..
(вообще, конечно, этот std::ostream& чаще встречается, как friend, но friend'ы не наследуются)... т.е. шаблон делают, чтобы для каждого не делать своего friend'а?..

Добавлено через 3 минуты
неужели есть какой-то тайный смысл в замене virtual на использование templates?.. бывает ли это резонно? и в каких случаях?.. как-то сильно задумалась над вашей мыслью...

@oleg-m1973 · 17.09.2020, 18:45

Сообщение от JeyCi

это так что ли?

Именно

Добавлено через 1 минуту
void WriteLog(T &&obj)

Добавлено через 47 секунд

Сообщение от JeyCi

но const, наверно, всё-таки убрать?..

В случае с шаблонами можно убрать. Но лучше оставить

Добавлено через 1 минуту

Сообщение от JeyCi

всё равно непонятно, зачем ещё и шаблон, если в каждом классе прописывать свой std::ostream& надо?..

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

Добавлено через 1 минуту

Сообщение от JeyCi

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

Шаблоны - это compile-time. Виртуальные методы - это runtime + накладные расходы

@JeyCi · 17.09.2020, 19:24

Сообщение от oleg-m1973

Шаблоны - это compile-time. Виртуальные методы - это runtime + накладные расходы

вот это уже радует в шаблонах! спасибо!

Добавлено через 23 минуты

Сообщение от oleg-m1973

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

честно говоря ostream& Format(ostream& out) {/*do_format*/} ещё не напишу...
но с friend'ами как-то так, наверно, - у каждого свой:

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#include <iostream>
 
class A
{
    public:
    friend std::ostream& operator<<(std::ostream& out, A) {
        // output something
        return out << "A !!!!\n";
    } 
};
 
class B : public A
{
    public:
        //std::ostream &Format(std::ostream &out) const { return out << "B !!!!";}
    friend std::ostream& operator<<(std::ostream& out, B) {
        // output something
        return out << "B !!!!\n";
    }
};
 
int main()
{
A a;
   B b;
   std::cout<<a;
   std::cout<<b;
}

IGPIGP · 17.09.2020, 19:25

Сообщение от oleg-m1973

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

oleg-m1973, вопрос в комфорте. Но попробовать всегда можно. Радости от такого мало, - вы правы:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
#include <iostream>
using namespace std;
 
struct WildCvaziVirtual
{
    using Dynamic_linked_fun=int (*)(int,int);
    WildCvaziVirtual(int a_=0, int b_=0, Dynamic_linked_fun dynamic_linked_fun_=nullptr)
    :a(a_)
    ,b(b_)
    ,dynamic_linked_fun(dynamic_linked_fun_)
    {
 
    }
 
 
    void noVirtualPolymorph()const
    {
 
            if(dynamic_linked_fun)cout<<dynamic_linked_fun(a,b);
            else cout<<"\nsum "<<(a+b);
            cout<<endl;
 
    }
    int a,b;
    const Dynamic_linked_fun &dynamic_linked_fun;
 
};
int mult(int a, int b){cout<<"\nmult " ; return a*b;}
int diff(int a, int b){cout<<"\ndiff " ;return a-b;}
 
void executor(const WildCvaziVirtual &dontcare_what)
{
    cout<<"\nexecutor"<<endl;
    dontcare_what.noVirtualPolymorph();
}
 
 
int main()
{
WildCvaziVirtual sum_obj(2,3), mult_obj(2,3, mult), diff_obj(2,3,diff);
 
executor(sum_obj);
executor(mult_obj);
executor(diff_obj);
 
return 0;
}

@oleg-m1973 · 17.09.2020, 19:27

Сообщение от JeyCi

честно говоря ostream& Format(ostream& out) {/*do_format*/} ещё не напишу...
но с friend'ами как-то так, наверно, - у каждого свой:

Это не то. Не зацикливайся на том, что конкретно делает функция. Речь шла совсем не об этом.

IGPIGP · 17.09.2020, 19:33

Или даже так

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
#include <iostream>
using namespace std;
 
struct WildCvaziVirtual
{
    using Dynamic_linked_fun=int (*)(int,int);
    WildCvaziVirtual(int a_=0, int b_=0, Dynamic_linked_fun dynamic_linked_fun_=nullptr)
    :a(a_)
    ,b(b_)
    ,dynamic_linked_fun(dynamic_linked_fun_)
    {
 
    }
 
 
    void noVirtualPolymorph()const
    {
 
            if(dynamic_linked_fun)cout<<dynamic_linked_fun(a,b);
            else cout<<"\nsum "<<(a+b);
            cout<<endl;
 
    }
 
    void noVirtualPolymorph(int a_, int b_)const
    {
 
            if(dynamic_linked_fun)cout<<dynamic_linked_fun(a_,b_);
            else cout<<"\nsum "<<(a_+b_);
            cout<<endl;
 
    }
    int a,b;
    const Dynamic_linked_fun &dynamic_linked_fun;
 
};
int mult(int a, int b){cout<<"\nmult " ; return a*b;}
int diff(int a, int b){cout<<"\ndiff " ;return a-b;}
 
void executor(const WildCvaziVirtual &dontcare_what)
{
    cout<<"\nexecutor"<<endl;
    dontcare_what.noVirtualPolymorph();
}
 
void executor(const WildCvaziVirtual &dontcare_what, int a, int b)
{
    cout<<"\nexecutor_params"<<endl;
    dontcare_what.noVirtualPolymorph(a,b);
}
 
int main()
{
WildCvaziVirtual sum_obj(2,3), mult_obj(2,3, mult), diff_obj(2,3,diff);
 
executor(sum_obj);
executor(mult_obj);
executor(diff_obj);
 
executor(sum_obj,  12,34);
executor(mult_obj, 12,34);
executor(diff_obj, 12,34);
 
return 0;
}

@oleg-m1973 · 17.09.2020, 19:34

Сообщение от IGPIGP

oleg-m1973, вопрос в комфорте. Но попробовать всегда можно. Радости от такого мало, - вы правы:

Ну да. Здесь используется указатель на функцию. Это та же самая виртуальная функция, только сбоку

IGPIGP · 17.09.2020, 19:38

Сообщение от oleg-m1973

Ну да. Здесь используется указатель на функцию. Это та же самая виртуальная функция, только сбоку

Это механизм виртуального наследования если его освежевать, кастрировать и обидеть грубым словом.
Наследование + полиморфизм, позволяют строить иерархические по данным и логике, RAII управляемые, легко выражаемые структуры.

Виртуально-феерические.

Но если решается шаблонами, то от виртуальности нужно бежать, обычно.

@JeyCi · 17.09.2020, 19:58

Сообщение от oleg-m1973

Речь шла совсем не об этом.

ну так (под спойлером) слишком просто как-то...

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#include <iostream>
#include <sstream> 
 
class A
{
    public:
        std::ostream &Format(std::ostream &out) const { return out << "A !!!!";}
        
};
 
class B : public A
{
    public:
        std::ostream &Format(std::ostream &out) const { return out << "B !!!!";}
};
 
int main()
{
    A a;
    B b;
    a.Format(std::cout)<< std::endl;
    b.Format(std::cout)<< std::endl;
}

вообще, я, конечно, не экстрасенс... но над тем, что будет наследоваться, что нет и как - ещё поработать надо... думаю, вы ведёте к 1-му вопросу ТСа - и ответ будет такой же, как в начале ветки -- просто синтаксис stream'а немного завёрнутый

... завтра посмотрю _ уже, наверно, слепая...

Новые блоги и статьи Все статьи Все блоги /
28. КОнкретное развертывание плана номер 1 из поста номер 27 anaschu 22.06.2026 Можно ли из модели получить конкретные строительные требования? Честно — напрямую из текущей модели такие ответы не получить. Но цепочка логики есть, и она не такая длинная. Где разрыв . . .	27. Планы на разработку функциональных требований к строительству внутри модели пищеблока (или не только его?) anaschu 22.06.2026 Что уже реализовано и даёт конфликты «бесплатно» Самый простой конфликт уже работает — конфликт за ресурс-работника. Заданий больше, чем доступных поваров → очередь в queue1. Это прямое отражение. . .	26. мед мат модель.Какие типы конфликтов функциональных требований можно рассчитать через ДЕС-моделирование (СМО) в AnyLogic? anaschu 22.06.2026 Что ДЕС/ СМО умеет считать напрямую: Конфликты за ресурсы (очереди, узкие места). Несколько типов агентов (повара, учителя, рабочие, пациенты) претендуют на один ресурс (лифт, вход, коридор,. . .	25 модель здравосохранения и функциональных требований к пищеблоку: конфликты функциональных требований. anaschu 22.06.2026 Есть ли данные о том, какие функциональные/ эксплуатационные требования или их сочетания труднее всего учитывать при проектировании зданий? Да, такие данные есть, и они хорошо описаны и в российской,. . .
Remote Connection Manager DevAlt 21.06.2026 Написал для себя небольшую прилагу: https:/ / github. com/ altbodhi/ ReConMan По итогу пришел к мысли, что DU не дружат с существующими технологиями. От сериализации до отображения в реляционную. . .	Администрация Хабра удаляет новые энрегоэфективные алгоритмы, которые не западной школы кода, и вовсе никак не сгенерировавны. Hrethgir 20.06.2026 Делается это, как замечено, при правках - при объявлении концептуальных отличий в алгоримах. Делается это, по линейке событий - после дополнения публикации основными отличиями от основных западных. . .	Процесс ориентированная диалектика (не новость - просто системное обновление, философия). Hrethgir 20.06.2026 Однажды один участник в своём блоге, на этом форуме, сделал запись "О языках замолвите слово". Понимая, что язык - важная вещь, я решил хорошо подумать, прежде чем сказать, и сказал то, что вы видите. . .	Контроль уникальности строк в табличной части документа Maks 18.06.2026 Алгоритм из решения ниже разработан на примере нетипового документа "ПланированиеСпецтехники" с табличной частью "НаличиеОборудования", разработанного в КА2. Задача: контроль уникальности строк в. . .

@JeyCi 264 / 153 / 33 Регистрация: 29.06.2019 Сообщений: 1,549
	16.09.2020, 12:08
	вобщем над зависимостями - ещё подумать... 0

@JeyCi 264 / 153 / 33 Регистрация: 29.06.2019 Сообщений: 1,549
	16.09.2020, 12:10
	но конкретно по примеру - это просто его рацион - переобозвать класс Cachalot на CashalotMenu 0

@oleg-m1973 6772 / 4565 / 1844 Регистрация: 07.05.2019 Сообщений: 13,726
	16.09.2020, 12:11
	Над ней всегда надо думать. И над зависимостями тоже. Ошибки проектирования - самые дорогие ошибки. 1