Работа с виртуальными функциями

@sto.r.m · Регистрация: 20.04.2009

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

Доброго времени суток, форумчани! Помогите мне, пожалуйста, с задачей, у меня просто нет этой темы, а сдать нужно обязательно

Напишите, пожалуйста, хотя бы классы в общих чертах, как использовать виртуальную функцию?

Вот моё задание:
Создать абстрактный базовый класс с виртуальной функцией - площадь поверхности. Создать производные классы: параллелепипед, тетраэдр, шар со своими функциями площади поверхности. Для проверки определить массив ссылок на абстрактный класс, которым присваиваются адреса различных объектов.
Площадь поверхности параллелепипеда: S=6*x*y. Площадь поверхности шара: S=4*pi*r*r. Площадь поверхности тетраэдра: S=a*a*sqrt(3).

Заранее очень-очень-…-очень благодарю!!!

@CyBOSSeR · 14.01.2010, 15:42

Genius Ignat, я читал эту книгу, дважды.
Это не книга по ООП. Не стоит основываться на нее, когда ты говоришь про полиморфизм, инкапсуляцию и т.п.

@zim22 · 14.01.2010, 15:43

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

Я тебе показал конкретный пример, а так же объяснил, почему тебе это ВООБЩЕ ничего не даст

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
struct Base {
  void fcn() { }
};
 
struct Derived : Base {
  virtual void fcn() { }    // имеет значение :)
};
 
struct TheMostDerived : Derived {
  void fcn() { }
};
 
int main()
{
  Base *ptr = new Derived;
  ptr->fcn(); // Base::fcn
 
  Derived *dp = new TheMostDerived;
  dp->fcn(); // TheMostDerived::fcn
 
  return 0;
}

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

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

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

@CyBOSSeR · 14.01.2010, 15:47

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

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

zim22, Evg говорил тебе немного о другом. Факт наличия слова virtual в объявлении методов производных классов не дает никакой информации для читателя. Т.к. без исследования иерархии классов непонятно, в каком базовом классе появился данный виртуальный метод.

@Ignat · 14.01.2010, 15:52

Чувствую спор закончится, тогда:
Когда будет рассказано что такое конструктор, когда он вызывается, как он вызывается,
кого он вызывает, как деструктор, вызывает другой деструктор, потом начнутся разговоры,
про динамическое определение типа, потом про vtbl.
Глядишь так и книга по C++ появится

Добавлено через 3 минуты
zim22 Evg: Давайте общими усилиями книгу напишем.

@CyBOSSeR · 14.01.2010, 15:53

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

@zim22 · 14.01.2010, 15:55

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

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

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

Сообщение от Genius Ignat

Чувствую спор закончится, тогда:
Когда будет рассказано что такое конструктор

похоже что все в этой теме кроме тебя это всё уже и так знают.

@CyBOSSeR · 14.01.2010, 15:59

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

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

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

@Ignat · 14.01.2010, 16:09

zim22: зачем так не хорошо.

Добавлено через 7 минут
Все наши споры вводят: sto.r.m в заблуждение у него и так темы про виртуальые функции нет.
А Я, CyBOSSeR, zim22 и Evg о чём-то спорим, в книгах же нет споров,
поэтому я выключаюсь из дискуссии.

@zim22 · 14.01.2010, 16:13

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

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

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

Evg · 14.01.2010, 16:15

zim22, в посте #3 я так же оптисался по поводу слова "virtual" для примера из ПОСТАВЛЕННОЙ ЗААЧИ. Т.е. у тебя есть базовый класс "фигура" с абстрактным виртуальным методом "площадь", от него наследуем класс "фигура шар", в котором переопределяем метод "площадь" (которая действительно для шара). Здесь я написал, что метод "фигура_шар::площадь" НЕ должен быть виртуальным, т.к. если мы пойдём наследовать дальше типа "фигура шар зелёный", то метод "площадь" меняться не делжен, ибо площать - это свойство шара, но НЕ свойство дальнейших модификаций шара по цепочке наследования

Genius Ignat, с тобой спорить бесполезно (я бы даже сказал, не интересно). Ты совершенно не пытаешься вникнуть в то, о чём тебе гокорят и всё время как-то асбтрактно ссылаешь на какие-то книги и посылаешь всех читать. Абсолютно никакой конкретики. Взять хотябы фразу из 20-го поста, сказанную с умным видом "от указателя ни чего не зависит" - я так и не понял, о чём ты говоришь. Зато понял то, что ты мой пост либо читал через строку, либо не осилил, а потому и отбрыкнулся короткой невнятной фразой

@CyBOSSeR · 14.01.2010, 16:16

zim22, я понял твою мысль и зачем все это нужно. Как говориться "На вкус и цвет товарищей нет" (это я о стиле).

Evg · 14.01.2010, 16:18

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

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

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

@zim22 · 14.01.2010, 16:24

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

десь я написал, что метод "фигура_шар::площадь" НЕ должен быть виртуальным

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

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

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

То, о чём ты говоришь - это и есть "программирование в классах"

я поверю тебе на слово. я ещё не слишком силён в проектировании объектно-ориентированных систем.

@CyBOSSeR · 14.01.2010, 16:49

zim22, если я понял Evg'а правильно то он ведет речь о следующем.

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
// Базовый класс Фигура
class Shape 
{
  public:
    virtual ~Shape()
    {}
    
    // Подклассы должны переопределять следующие методы
    virtual void  Draw        () = 0;  // Вывод на экран
    virtual CRect GetBoundRect() = 0;  // Получение ограничивающего прямоугольника
}
 
// Базовый класс Окружность (выводит незакрашенную окружность)
class Circle : public Shape
{
  // Подклассы должны переопределять следующий метод
  virtual void Draw();  // Вывод на экран
  
  // Подклассы НЕ должны переопределять следующий метод
  CRect GetBoundRect();  // Получение ограничивающего прямоугольника
}
 
// Базовый класс Красная окружность(выводит окружность закрашенную красным цветом)
class RedCircle : public Circle
{
  void  Draw        ();  // Вывод на экран
  CRect GetBoundRect();  // Получение ограничивающего прямоугольника
}

Наличие слова virtual в объявлении метода Draw класса Circle говорит о том, что подклассы должны переопределять данный метод, т.к. разные типы окружностей наверняка будут выводится по-разному.
Отсутствие же слова virtual в объявлении метода GetBoundRect класса Circle, говорит о том, что подклассы не должны переопределять данный метод, т.к. разные типы окружностей наверняка будут вычислять ограничивающий прямоугольник абсолютно одинаково (данная функциональность уже реализована в базовом классе).
Evg, ты это имел ввиду?

Evg · 14.01.2010, 16:58

zim22, так сейчас по большому счёту так оно и есть. Заводится асбтрактный класс "Фигура", в котором делается неопределёный виртуальный метод "площадь". Прямые наследники класса "фигура" ("фигура шар", "фигура куб", ...) определяют этот метод. Но они должны его делать НЕ виртуальным, чтобы дальшейшее переопределение было невозможно

> И если мы хотим работать единообразно(полиморфизм) с объектами этих классов через указатель на базовый класс - то методы должны быть виртуальными.

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

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

> я поверю тебе на слово. я ещё не слишком силён в проектировании объектно-ориентированных систем

Просто это упоминалось скорее как пример для темы Отличие С от С++

Добавлено через 1 минуту
> Evg ты это имел ввиду?

Ага, только описал на более плохом примере (чтобы хоть как-то коррелировать с поставленной задачей в первом посте)

@Ignat · 14.01.2010, 17:43

Если тема актуальна: А как же RTTI?

Evg · 14.01.2010, 17:47

Сообщение от Genius Ignat

Если тема актуальна: А как же RTTI?

Ты вроде бы выключился из дискуссии, а мне всегда казалось, что "мужик сказал - мужик сделал". Как бы то ни было при такой постановке вопроса ответ: "обычно зелёный, но временами бывает и 138"

@Ignat · 14.01.2010, 17:48

А я не участвую, я проверяю актуальность темы

@CheshireCat · 14.01.2010, 18:29

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

Заводится асбтрактный класс "Фигура", в котором делается неопределёный виртуальный метод "площадь". Прямые наследники класса "фигура" ("фигура шар", "фигура куб", ...) определяют этот метод. Но они должны его делать НЕ виртуальным, чтобы дальшейшее переопределение было невозможно

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

@zim22 · 14.01.2010, 18:36

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

Заводится асбтрактный класс "Фигура", в котором делается неопределёный виртуальный метод "площадь".

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

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

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
struct Shape {
  virtual int area() = 0;
};
 
struct Circle : Shape {
  int area() { return 100; }
};
 
struct RedCircle : Circle {
  int area() { return 200; }
};
 
int main()
{
  Shape *ptr = new RedCircle;
  ptr->area(); // вызовется RedCircle::area
}

Новые блоги и статьи Все статьи Все блоги /
Оттенки серого Argus19 18.03.2026 Оттенки серого Нашёл в интернете 3 прекрасных модуля: Модуль класса открытия диалога открытия/ сохранения файла на Win32 API; Модуль класса быстрого перекодирования цветного изображения в оттенки. . .	SDL3 для Desktop (MinGW): Рисуем цветные прямоугольники с помощью рисовальщика SDL3 на Си и C++ 8Observer8 17.03.2026 Содержание блога Финальные проекты на Си и на C++: finish-rectangles-sdl3-c. zip finish-rectangles-sdl3-cpp. zip	Символические и жёсткие ссылки в Linux. algri14 15.03.2026 Существует два типа ссылок — символические и жёсткие. Ссылка в Linux — это запись в каталоге, которая может указывать либо на inode «файла-ИСТОЧНИКА», тогда это будет «жёсткая ссылка» (hard link),. . .	[Owen Logic] Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ФедосеевПавел 14.03.2026 Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ВВЕДЕНИЕ Выполняя задание на управление насосной группой заполнения резервуара,. . .
делаю науч статью по влиянию грибов на сукцессию anaschu 13.03.2026 прикрепляю статью	SDL3 для Desktop (MinGW): Создаём пустое окно с нуля для 2D-графики на SDL3, Си и C++ 8Observer8 10.03.2026 Содержание блога Финальные проекты на Си и на C++: hello-sdl3-c. zip hello-sdl3-cpp. zip Результат:	Установка CMake и MinGW 13.1 для сборки С и C++ приложений из консоли и из Qt Creator в EXE 8Observer8 10.03.2026 Содержание блога MinGW - это коллекция инструментов для сборки приложений в EXE. CMake - это система сборки приложений. Здесь описаны базовые шаги для старта программирования с помощью CMake и. . .	Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .

@sto.r.m 6 / 6 / 0 Регистрация: 20.04.2009 Сообщений: 29

	Работа с виртуальными функциями 13.01.2010, 22:11. Показов 4792. Ответов 44 Метки нет (Все метки) Доброго времени суток, форумчани! Помогите мне, пожалуйста, с задачей, у меня просто нет этой темы, а сдать нужно обязательно Напишите, пожалуйста, хотя бы классы в общих чертах, как использовать виртуальную функцию? Вот моё задание: Создать абстрактный базовый класс с виртуальной функцией - площадь поверхности. Создать производные классы: параллелепипед, тетраэдр, шар со своими функциями площади поверхности. Для проверки определить массив ссылок на абстрактный класс, которым присваиваются адреса различных объектов. Площадь поверхности параллелепипеда: S=6xy. Площадь поверхности шара: S=4pirr. Площадь поверхности тетраэдра: S=aasqrt(3). Заранее очень-очень-…-очень благодарю!!!* 0

@CyBOSSeR 2348 / 1721 / 149 Регистрация: 06.03.2009 Сообщений: 3,675
	14.01.2010, 15:42
	Genius Ignat, я читал эту книгу, дважды. Это не книга по ООП. Не стоит основываться на нее, когда ты говоришь про полиморфизм, инкапсуляцию и т.п. 0

@Ignat 1261 / 799 / 108 Регистрация: 16.09.2009 Сообщений: 2,010
	14.01.2010, 15:52
	Чувствую спор закончится, тогда: Когда будет рассказано что такое конструктор, когда он вызывается, как он вызывается, кого он вызывает, как деструктор, вызывает другой деструктор, потом начнутся разговоры, про динамическое определение типа, потом про vtbl. Глядишь так и книга по C++ появится Добавлено через 3 минуты zim22 Evg: Давайте общими усилиями книгу напишем. 0

@CyBOSSeR 2348 / 1721 / 149 Регистрация: 06.03.2009 Сообщений: 3,675
	14.01.2010, 15:53
	Genius Ignat, просто не стоит приводить в пример книгу, которая не относится к рассматриваемой теме, даже если она тебе очень очень понравилась. 0

@Ignat 1261 / 799 / 108 Регистрация: 16.09.2009 Сообщений: 2,010
	14.01.2010, 16:09
	zim22: зачем так не хорошо. Добавлено через 7 минут Все наши споры вводят: sto.r.m в заблуждение у него и так темы про виртуальые функции нет. А Я, CyBOSSeR, zim22 и Evg о чём-то спорим, в книгах же нет споров, поэтому я выключаюсь из дискуссии. 0

Evg 21281 / 8305 / 637 Регистрация: 30.03.2009 Сообщений: 22,660 Записей в блоге: 30
	14.01.2010, 16:15
	zim22, в посте #3 я так же оптисался по поводу слова "virtual" для примера из ПОСТАВЛЕННОЙ ЗААЧИ. Т.е. у тебя есть базовый класс "фигура" с абстрактным виртуальным методом "площадь", от него наследуем класс "фигура шар", в котором переопределяем метод "площадь" (которая действительно для шара). Здесь я написал, что метод "фигура_шар::площадь" НЕ должен быть виртуальным, т.к. если мы пойдём наследовать дальше типа "фигура шар зелёный", то метод "площадь" меняться не делжен, ибо площать - это свойство шара, но НЕ свойство дальнейших модификаций шара по цепочке наследования Genius Ignat, с тобой спорить бесполезно (я бы даже сказал, не интересно). Ты совершенно не пытаешься вникнуть в то, о чём тебе гокорят и всё время как-то асбтрактно ссылаешь на какие-то книги и посылаешь всех читать. Абсолютно никакой конкретики. Взять хотябы фразу из 20-го поста, сказанную с умным видом "от указателя ни чего не зависит" - я так и не понял, о чём ты говоришь. Зато понял то, что ты мой пост либо читал через строку, либо не осилил, а потому и отбрыкнулся короткой невнятной фразой 0

@CyBOSSeR 2348 / 1721 / 149 Регистрация: 06.03.2009 Сообщений: 3,675
	14.01.2010, 16:16
	zim22, я понял твою мысль и зачем все это нужно. Как говориться "На вкус и цвет товарищей нет" (это я о стиле). 0

Evg 21281 / 8305 / 637 Регистрация: 30.03.2009 Сообщений: 22,660 Записей в блоге: 30
	14.01.2010, 16:58
	zim22, так сейчас по большому счёту так оно и есть. Заводится асбтрактный класс "Фигура", в котором делается неопределёный виртуальный метод "площадь". Прямые наследники класса "фигура" ("фигура шар", "фигура куб", ...) определяют этот метод. Но они должны его делать НЕ виртуальным, чтобы дальшейшее переопределение было невозможно > И если мы хотим работать единообразно(полиморфизм) с объектами этих классов через указатель на базовый класс - то методы должны быть виртуальными. Это свойство сохраняется. При этом если указатель на базовый класс описывает объект "фигура шар синий", то при вызове через указатель функции "площадь" реально дёрнется функция "площадь" из класса "фигура шар". А вот если мы оставим слово "virtual" в классе "шар", то это означает, что какой-нибудь дятел может сделать класс "фигура шар серо-буро-малиновый" и в этом классе создать свою функцию "площадь" (которая ещё и может оказаться неправильной). Концептуально это не правильно, поскольку "площадь" является свойством понятия "конкретная фигура", но не понятия "конкретная фигура конкретного цвета". Поэтому в классах "конкретная фигура" ("фигура шар", "фигура куб") свойство "площадь" должно описываться без слова virtual. Это означает, что класс "фигура шар серо-буро-малиновый" ни при каких условиях не сможет переопределить виртуальную функцию "площадь". При этом допустим у нас имеется некая загадочная фигура, площадь которой зависит от цвета. Тогда в классе "фигура загадочная" функция определяется с словом virtual. Ну или как вариант, если для каждого цвета площадь вычисляется по-разному, то функция "площадь" в классе "фигура загадочная" определяться не должна (чтобы не было возможность создать экземпляр класса "фигура загадочная"), и должна определяться в кажлом из дальнейших классов ("фигура загадочная синяя", "фигура загадочная зелёная" и т.п.) > я поверю тебе на слово. я ещё не слишком силён в проектировании объектно-ориентированных систем Просто это упоминалось скорее как пример для темы Отличие С от С++ Добавлено через 1 минуту > Evg ты это имел ввиду? Ага, только описал на более плохом примере (чтобы хоть как-то коррелировать с поставленной задачей в первом посте) 0

@Ignat 1261 / 799 / 108 Регистрация: 16.09.2009 Сообщений: 2,010
	14.01.2010, 17:43
	Если тема актуальна: А как же RTTI? 0

@Ignat 1261 / 799 / 108 Регистрация: 16.09.2009 Сообщений: 2,010
	14.01.2010, 17:48
	А я не участвую, я проверяю актуальность темы 0