SashaMercury
1.
2.
3.
4.
5.
6.
7.
8.
9.
class X
{
int x;
public:
virtual void copy(X* p)
{
x = p->x;
}
};
Какой результат на ваш взгляд было бы логично ожидать в строчках 1, 2, и, самое главное, почему? (вопрос не о том, как сейчас будет происходить обработка данного кода). При этом, было бы интересно узнать о ваших мыслях не в контексте того, что сейчас есть в С++, а в контексте того, что у вас есть C with Сlasses и вы планируете интегрировать к данному языку механизм виртуальных функций.
По классике это должен был бы быть
1.
virtual X& operator =(const X& p);
И как раз в тему о multiple dispatching
Дело в том, что семантика присваивания полиморфна по отношению к двум видам объектов:
что присваивается
чему присваивается
Возможны тут 4 случая
Тип источникаТип приёмникаСемантика операцииBaseBaseНормальное присваивание объекта класса BaseBaseDerivedНедопустимая операция, так как часть членов класса Derived не будет присвоенаDerivedBaseУсечение Derived до Base, опасная, но допустимая в С++ операция, поскольку часть данных теряетсяDerivedDerivedНормальное присваивание объекта класса Derived
Именно поэтому operator=
как бы не наследуется и не переопределяется.
Поэтому я бы рассматривал этот конкретный пример совершенно отдельно от обсуждения виртуальных функций, которые достаточно просты по
своей семантике.
автор2. Как часто вы используете виртуальные функции в своих программах и как лично вы относитесь к данному механизму?
Ну, как часто, так часто, как надо. Это зависит от задачи. В общем, полиморфизм на типе объекта используется везде, где используются иерархии классов и операции над этими классами.
С точки зрения семантики виртуальных функций в С++, она, безусловно, контринтуитивна, потому что естественным для программиста было бы, если бы все методы были автоматом виртуальными. Появление в С++ необходимости явно требовать
оформления вызова виртуальной функции как косвенного вызова через таблицу виртуальных методов безусловно связана
с необходимостью обеспечить управление быстродействием результирующей программы, получаемой из исходного кода.
И хотя в общем стоимость виртуального вызова не так уж и сильно больше стоимости вызова обычного (оба на самом деле
достаточно высоки, потому что надо формировать аргументы и переключать стек), во времена появления С++, наверное,
разработчики боялись всего-всего, и я полагаю, что Страустрап просто остерёгся делать все поголовно функции виртуальными.
В более современных языках, которые являются наследниками С++, -- Java и C# -- виртуальные вызовы делаются автоматически
везде.
Кстати, не многие помнят, что слово virtual в английском языке означает "действительный", и именно поэтому это слово используется
в этом случае.
автор3. Считаете ли вы ослабление правил замещения для типа возвращаемого значения и для аргументов правильным решением? Интересно, если бы комитет не принял предложения об этом, каким образом были бы решены возможные проблемы(пример из теории компиляторов, метод clone в базовом и производных классах). Лично мне кажется, что это привело бы к изменениям в системе типов языка, что в конечном счете могло положительно сказаться на ней.
Я не очень понял, о чём ты тут ... Я бы думал, что кардинальное решение этой проблемы -- множественная диспетчеризация.
Другой вариант решения, очень простой -- это использовать вместо
1.
void X::copy(const X*src)
функцию
Тут семантика меняется, не смотря на то, что в принципе функция делает то же самое, и всё становится сильно легче, потому что полиморфизм идёт только по первому и единственному аргументу.
