Виртуальное наследование
От: Kudinov Alexander Россия http://www.devdoc.ru
Дата: 04.09.07 05:01
Оценка: 1 (1)
Добрый день!

Я опубликовал черновой вариант статьи на http://www.devdoc.ru/index.php/content/view/virtual_inheritance.htm про виртуальное наследование. В ней дан обзор множественному наследованию в целом, а также разобраны внутренности работы виртуального наследования.

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

--
Кудинов Алексндр,
www.devdoc.ru — Статьи по программированию
--
Александр.

http://www.devdoc.ru. – новые статьи по программированию каждую неделю.
Re: Виртуальное наследование
От: MasterZiv СССР  
Дата: 04.09.07 09:50
Оценка: +1
Kudinov Alexander пишет:

В первом случае – мы будем использовать только одну из копий объекта A. Вторая
копия у нас просто «повиснет» и программа в целом может работать неверно, т.к.
класс B ничего не знает о том, что его предок не используется. Т.е. вторая копия
подобъекта A никак не будет использоваться, но будет занимать память. Во втором
варианте – просто выполняется дублирование операций, и как следствие возникает
необходимость поддерживать синхронность обоих подобъектов типа A. Это плохой
стиль и рассадник всевозможных ошибок.


Эти рассуждения вне контекста конкретной иерархии классов и ее функциональности
бессмысленны. Тем не менее выводы довольно категоричны и однозначты.

А в остальном вроде как и ничего...
Posted via RSDN NNTP Server 2.1 beta
Re: Виртуальное наследование
От: Аноним  
Дата: 06.09.07 17:00
Оценка: +1
Здравствуйте, Kudinov Alexander

Кстати про виртуальное наследование:
давно интересуют примеры его использования в реальных программах.
Пока единственное, что я видел — это пример из STL:
template <class Elem, class Tr = char_traits<Elem> >
   class basic_istream
      : virtual public basic_ios<Elem, Tr>

Так же на форуме приводился пример со счётчиком экземпляров класса.
Честно говоря, создаётся впечатление, что это очень сомнительная фича C++...
Re[2]: Виртуальное наследование
От: Programador  
Дата: 06.09.07 20:36
Оценка: -1
Здравствуйте, Аноним, Вы писали:
А>Так же на форуме приводился пример со счётчиком экземпляров класса.
А>Честно говоря, создаётся впечатление, что это очень сомнительная фича C++...
Если есть множественное наследование, то должно быть и виртуальное. А зачем нужно множественное? да затем что и простое.
Кстати и без простого можно и обойтись
struct B
{ int x,y;
};
struct D
{ B B;
  int z;
};
Re[3]: Виртуальное наследование
От: McSeem2 США http://www.antigrain.com
Дата: 07.09.07 00:43
Оценка: 6 (1) +4
Здравствуйте, Programador, Вы писали:

P>Если есть множественное наследование, то должно быть и виртуальное. А зачем нужно множественное? да затем что и простое.

P>Кстати и без простого можно и обойтись
P>
P>struct B
P>{ int x,y;
P>};
P>struct D
P>{ B B;
P>  int z;
P>};
P>


Без наследования можно обойтись. И даже нужно, полностью сохраняя при этом идею полиморфизма. Но не в C++, Java, C# и тому подобных. Сама идея наследования как расширения функциональности является глубоко порочной и противоречит сущности нашего мира. Особенный LOL вызывают попытки порождения производных классов от std::string, std::vector<MyType> и тому подобных. Наследование должно быть только специализацией функциональности и ничем более. Короче, нет виртуальных функций в базовом классе? — наследование запрещено. Вот так должно быть IMSO. Но тогда это уже и не наследование получается, а некая динамическая специализация. А тот беспредел, что сейчас имеется, в конечном итоге приводит к обилию нелепых конструкций, типа ((my_string*)&std_str)->my_compare_with(b);
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[4]: Виртуальное наследование
От: Erop Россия  
Дата: 07.09.07 06:33
Оценка: -2
Здравствуйте, McSeem2, Вы писали:

MS>Сама идея наследования как расширения функциональности является глубоко порочной и противоречит сущности нашего мира.

А как же ООП иерархии?
Скажем такая:
предмет мебели
 предмет мебели, на котором сидят
  кресло


MS>Но тогда это уже и не наследование получается, а некая динамическая специализация. А тот беспредел, что сейчас имеется, в конечном итоге приводит к обилию нелепых конструкций, типа ((my_string*)&std_str)->my_compare_with(b);

А может лучше научиться нормально программировать? Хотя я согласен, что в функциональном языке наследование смотрится чужеродно. Ну так ведь C++ он же мультипарадигменный, или как там это зовут нынче?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: Виртуальное наследование
От: McSeem2 США http://www.antigrain.com
Дата: 07.09.07 16:46
Оценка: 1 (1)
Здравствуйте, Erop, Вы писали:

E>А как же ООП иерархии?

E>Скажем такая:
E>
E>предмет мебели
E> предмет мебели, на котором сидят
E>  кресло
E>


Ясно же было сказано — если нет необходимости в использовании витруальных функций, то нет и ни малейшего смысла в этой иерархии.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[6]: Виртуальное наследование
От: Erop Россия  
Дата: 07.09.07 18:12
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Ясно же было сказано — если нет необходимости в использовании витруальных функций, то нет и ни малейшего смысла в этой иерархии.


Да? А почему? Почему я не могу, например, иметь список предметов мебели в комнате, особенно если у каждого из них прописан тип, в виде аттрибута?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[2]: Виртуальное наследование
От: Roman Odaisky Украина  
Дата: 08.09.07 09:27
Оценка: 5 (2)
Здравствуйте, Аноним, Вы писали:

А>Кстати про виртуальное наследование:

А>давно интересуют примеры его использования в реальных программах.

Есть вот такой баян, запрещающий наследование от определенного класса:
class Final;

class FinalHelper
{
friend class Final;
private:
    FinalHelper() { }
};

class Final: public SomeInterface, virtual private FinalHelper
{
    . . .
};

class Error: public Final // не-не
{
    . . .
};

Здесь конструктор FinalHelper должен будет быть вызван из конструктора Error (если бы наследование было невиртуальным, этот конструктор вызывался бы из конструктора Final), а Error не имеет к нему доступа, потому что он private.
До последнего не верил в пирамиду Лебедева.
Re[4]: Виртуальное наследование
От: Evgeniy13 Россия  
Дата: 08.09.07 12:09
Оценка: 4 (1) -1
Здравствуйте, McSeem2, Вы писали:

MS>Без наследования можно обойтись. И даже нужно, полностью сохраняя при этом идею полиморфизма. Но не в C++, Java, C# и тому подобных. Сама идея наследования как расширения функциональности является глубоко порочной и противоречит сущности нашего мира. Особенный LOL вызывают попытки порождения производных классов от std::string, std::vector<MyType> и тому подобных. Наследование должно быть только специализацией функциональности и ничем более. Короче, нет виртуальных функций в базовом классе? — наследование запрещено. Вот так должно быть IMSO. Но тогда это уже и не наследование получается, а некая динамическая специализация. А тот беспредел, что сейчас имеется, в конечном итоге приводит к обилию нелепых конструкций, типа ((my_string*)&std_str)->my_compare_with(b);


Полностью согласен.
Хотя есть все-таки несколько исключений из этого правила:
— Наследование вместо агрегации (не нужно лишний раз обращаться к переменной). Но в этом случае очевидно должно быть защищенное наследование.
— Наследование как наследования реализации (опять-таки должно быть защищенное наследование)
— Наследование при всяких С++ "штучках" (например при реализации стратегий или статического полиморфизма)
Не все в этом мире можно выразить с помощью нулей и единиц...
Re[4]: Виртуальное наследование
От: Programador  
Дата: 08.09.07 17:42
Оценка: -1 :)
Здравствуйте, McSeem2, Вы писали:

MS> Сама идея наследования как расширения функциональности является глубоко порочной и противоречит сущности нашего мира.

В окружающем мире нет сущностей, В нем нет мебели, есть конкретные стулья, кресла. В некотором месте программы можно таскать мышкой нечто имеющее x y z и w h l и это вобщем удобно иначе программы вообще невозможно былобы писать. Креслу не обязательно менять чтото в паралелепипеде, а паралелепипеду знать что на нем можно сидеть

MS>Короче, нет виртуальных функций в базовом классе? — наследование запрещено. Вот так должно быть IMSO.

Это удобная схема в которую многое укладывается. Но к сожалению не все. У нас помимо мебели есть оружие, инвентору, точка в пространстве окуда появляются черти и т.д. и некоторые опрерации для этих предметов общие, например — подвергнуть заклинанию, произвести цикл обновления, записать, отрисовать. Но при этом сущности настолько разные, что неразумно их включать в одну иерархию. Иначе это получится некий универсальный суперпредок.
Re[7]: Виртуальное наследование
От: McSeem2 США http://www.antigrain.com
Дата: 08.09.07 19:23
Оценка: 6 (1)
Здравствуйте, Erop, Вы писали:

E>Да? А почему? Почему я не могу, например, иметь список предметов мебели в комнате, особенно если у каждого из них прописан тип, в виде аттрибута?


Ну, "если у каждого из них прописан тип, в виде аттрибута", зачем тогда иерархии? Плоская таблица (в терминологии RDBMS) решает задачу инвентаризации. А зачем еще надо "иметь список предметов мебели в комнате", кроме как для инвентаризации?
Для моделирования размещения? Тогда тем более никаких иерархий не надо. Точнее сказать, иерархия должна быть строго одноуровневая, с виртуальным методом Draw() и ему подобными.

Короче, при решении задач, все эти "иерархии", привнесенные из физического мира являются надуманными и никакого смысла не несут. Главная задача наследования — обеспечить полиморфное поведение. Это имеет смысл. Наследование как расширение функциональности — не имеет ни малейшего смысла.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[3]: Виртуальное наследование
От: Минипух Украина  
Дата: 08.09.07 20:16
Оценка: -1
Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, Аноним, Вы писали:


А>>Кстати про виртуальное наследование:

А>>давно интересуют примеры его использования в реальных программах.

RO>Здесь конструктор FinalHelper должен будет быть вызван из конструктора Error (если бы наследование было невиртуальным, этот конструктор вызывался бы из конструктора Final), а Error не имеет к нему доступа, потому что он private.


Какой-то искусственный пример. Одна фича языка используется для реализации другой фичи языка.
Re: Виртуальное наследование
От: commando Россия  
Дата: 08.09.07 20:24
Оценка:
Небольшой оффтопик: посмотрел другую Вашу статью http://www.devdoc.ru/index.php/content/view/virtual_base.htm.

Вопрос: почему в иллюстрации к примеру №2 у объекта A отсутствует указатель на таблицу виртуальных функций?
Re[8]: Виртуальное наследование
От: Ruweb  
Дата: 09.09.07 09:54
Оценка: 2 (1)
Здравствуйте, McSeem2, Вы писали:

MS>Наследование как расширение функциональности — не имеет ни малейшего смысла.


Имеет смысл в задачах, где полиморфизм ну не как, не применить.
Re[8]: Виртуальное наследование
От: Erop Россия  
Дата: 09.09.07 11:21
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Ну, "если у каждого из них прописан тип, в виде аттрибута", зачем тогда иерархии? Плоская таблица (в терминологии RDBMS) решает задачу инвентаризации. А зачем еще надо "иметь список предметов мебели в комнате", кроме как для инвентаризации?


Мало ли зачем? Скажем тебя может заинтересовать сколько мест для рассадки гостей есть в комнате, или сколько для раскладывания на ночлег. Соответсвенно нужны разные свойства. Конечно можно сделать мегаобъект "универсальное описание предмета мебели", но тогда для болшинства предметов, большинство аттрибутов будут станными...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: protected vs private
От: Erop Россия  
Дата: 09.09.07 11:24
Оценка: 1 (1)
Здравствуйте, Evgeniy13, Вы писали:

E>- Наследование вместо агрегации (не нужно лишний раз обращаться к переменной). Но в этом случае очевидно должно быть защищенное наследование.

E>- Наследование как наследования реализации (опять-таки должно быть защищенное наследование)

А почему protected, а не private?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: protected vs private
От: Ruweb  
Дата: 09.09.07 12:02
Оценка: :)
Здравствуйте, Erop, Вы писали:

E>А почему protected, а не private?


А какая разнца для юзера protected или private члены? ни к тем, ни к тем он доступа не имеет. Уровни доступа придуманны для того, чтобы запретить юзеру юзать те или иные члены.

А юзать protected вместо private в наследовании выгодней, потому что наследник будет и иметь доступ к базовым, закрытым для юзера членам, т.е. сохраняется гипкость.

Во времени выполнения нет разницы, почемуб не юзать? или я что-то не то говорю?
Re[7]: protected vs private
От: Erop Россия  
Дата: 09.09.07 12:57
Оценка: 6 (1) +1
Здравствуйте, Ruweb, Вы писали:

R>А юзать protected вместо private в наследовании выгодней, потому что наследник будет и иметь доступ к базовым, закрытым для юзера членам, т.е. сохраняется гипкость.


А почему нет нужды защищать свои потроха от своих наследников?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: protected vs private
От: Roman Odaisky Украина  
Дата: 09.09.07 14:01
Оценка:
Здравствуйте, Ruweb, Вы писали:

R>А юзать protected вместо private в наследовании выгодней, потому что наследник будет и иметь доступ к базовым, закрытым для юзера членам, т.е. сохраняется гипкость.


Тогда вообще всегда использовать public выгодней — гибкости больше.

Я пока знаю только одно приличное применение protected, и то оно там не используется: деструкторы std::unary_function, std::iterator и прочих невиртуальных интерфейсов.
До последнего не верил в пирамиду Лебедева.
Re[6]: protected vs private
От: Evgeniy13 Россия  
Дата: 09.09.07 18:46
Оценка: :)
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Evgeniy13, Вы писали:


E>>- Наследование вместо агрегации (не нужно лишний раз обращаться к переменной). Но в этом случае очевидно должно быть защищенное наследование.

E>>- Наследование как наследования реализации (опять-таки должно быть защищенное наследование)

E>А почему protected, а не private?


Не я имел в виду на самом деле любое наследование кроме открытого. Что конкретно (protected или private) зависит от конкретного дизайна.
Не все в этом мире можно выразить с помощью нулей и единиц...
Re[3]: Виртуальное наследование
От: Programador  
Дата: 09.09.07 19:05
Оценка: -1 :)
Здравствуйте, Roman Odaisky, Вы писали:

RO>Есть вот такой баян, запрещающий наследование от определенного класса:

RO>
RO>class Final;

RO>class FinalHelper
RO>{
RO>friend class Final;
RO>private:
RO>    FinalHelper() { }
RO>};

RO>class Final: public SomeInterface, virtual private FinalHelper
RO>{
RO>    . . .
RO>};

RO>class Error: public Final // не-не
RO>{
RO>    . . .
RO>};
RO>

RO>Здесь конструктор FinalHelper должен будет быть вызван из конструктора Error (если бы наследование было невиртуальным, этот конструктор вызывался бы из конструктора Final), а Error не имеет к нему доступа, потому что он private.
Крайне сомнительно что FinalHelper позовется. Во всяком случае онлайн компиляторы http://www.comeaucomputing.com/tryitout/ и http://www.interstron.ru/eng/text.asp?id=3792 сожрали это без вопросов
Re[4]: Виртуальное наследование
От: Erop Россия  
Дата: 09.09.07 20:20
Оценка: 1 (1)
Здравствуйте, Programador, Вы писали:

P>Крайне сомнительно что FinalHelper позовется. Во всяком случае онлайн компиляторы http://www.comeaucomputing.com/tryitout/ и http://www.interstron.ru/eng/text.asp?id=3792 сожрали это без вопросов


Ну типа FinalHelper не будет конструироваться, что ли?
Попробуй создать объект выведенного класса...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: Виртуальное наследование
От: Programador  
Дата: 09.09.07 21:17
Оценка:
Здравствуйте, Erop, Вы писали:

E>Попробуй создать объект выведенного класса...

Попробовал — действительно не создаются обьекты. Но FinalHelper в Error нужен ли? В принципе его могли позвать и из Final.
Чтоб скомпилировать создание обьекта Error нужно и friend class Error; и friend class Final; . Но ведь зовется то только один конструктор
Re[6]: Виртуальное наследование
От: Erop Россия  
Дата: 09.09.07 21:24
Оценка:
Здравствуйте, Programador, Вы писали:

P>Чтоб скомпилировать создание обьекта Error нужно и friend class Error; и friend class Final; . Но ведь зовется то только один конструктор


Конструктор виртуальной базы зовётся из самого выведенного объекта. Если не понятно почему это так, то могу объяснить (глупый ответ "по стандарту" )
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: Виртуальное наследование
От: Programador  
Дата: 09.09.07 21:41
Оценка:
Здравствуйте, Erop, Вы писали:

E>Конструктор виртуальной базы зовётся из самого выведенного объекта. Если не понятно почему это так, то могу объяснить (глупый ответ "по стандарту" )

Оба friend нужны. Но в одном из классов конструктор не нужен. Вопрос или в стандарте сказано проверить сначала на даступность, а потом на нужность? Или они тексты друг у друга воруют

class Final;

class FinalHelper
{
friend class Error;
friend class Final;
private:
    FinalHelper() { }
};

class Final:  virtual private FinalHelper
{
};

class Error: public Final // не-не
{
};
Error ee;
Re[9]: Виртуальное наследование
От: McSeem2 США http://www.antigrain.com
Дата: 09.09.07 23:58
Оценка:
Здравствуйте, Erop, Вы писали:

E>Мало ли зачем? Скажем тебя может заинтересовать сколько мест для рассадки гостей есть в комнате, или сколько для раскладывания на ночлег. Соответсвенно нужны разные свойства.


Таким образом, ты ведешь речь о сферической лошади в вакууме, никому на практике не нужной.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[10]: Виртуальное наследование
От: Erop Россия  
Дата: 10.09.07 08:22
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Таким образом, ты ведешь речь о сферической лошади в вакууме, никому на практике не нужной.

Таким образом я не хочу описывать реальную сложную задачу, где ООП иерархии имеют смысл. Конечно в мегапродукте "Hellow World" без наследования обычно можно легко обойтись
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Виртуальное наследование
От: Erop Россия  
Дата: 10.09.07 08:26
Оценка:
Здравствуйте, Programador, Вы писали:

P>Оба friend нужны. Но в одном из классов конструктор не нужен. Вопрос или в стандарте сказано проверить сначала на даступность, а потом на нужность? Или они тексты друг у друга воруют


Как-то не понятно что бы обозначало выделенное
По стандарту непосредственно из конструктора самого выведенного класса зовутся конструкторы всех виртуальных баз. Соответсвенно их нужно позвать и для этого нужен доступ.
Или ты имеешь в виду, что конструктор FinalHelper ничего не делает?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Виртуальное наследование
От: Programador  
Дата: 10.09.07 08:59
Оценка:
Здравствуйте, Erop, Вы писали:

E>Как-то не понятно что бы обозначало выделенное

E>По стандарту непосредственно из конструктора самого выведенного класса зовутся конструкторы всех виртуальных баз. Соответсвенно их нужно позвать и для этого нужен доступ.
Но тогда он не зовется из Final , а без friend class Final; не компилируется.
Re[10]: Виртуальное наследование
От: Programador  
Дата: 10.09.07 09:02
Оценка: +1
Здравствуйте, McSeem2, Вы писали:

E>>Мало ли зачем? Скажем тебя может заинтересовать сколько мест для рассадки гостей есть в комнате, или сколько для раскладывания на ночлег. Соответсвенно нужны разные свойства.


MS>Таким образом, ты ведешь речь о сферической лошади в вакууме, никому на практике не нужной.

так это в идеальной задаче нужно чтото одно, а в реальной сегодня одно, завтра другое и то что позавчера не перестает быть нужно
Re[10]: Виртуальное наследование
От: Erop Россия  
Дата: 10.09.07 10:20
Оценка:
Здравствуйте, Programador, Вы писали:

P>Но тогда он не зовется из Final , а без friend class Final; не компилируется.

Ну он должен таки иметь возможность позваться.

Груба говоря, все виртуальные наследники, даже и непрямые, должны действовть так: "Если виртуальная база ещё не создана -- создать"
Ты же не знаешь из какого контекста это всё позовут.

Вот ты запихнёшь это всё в библиотеку, скомпилишь и отдашь, а пользователи захотят и позовут copy-constructor Final от Error...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: Виртуальное наследование
От: Programador  
Дата: 10.09.07 11:23
Оценка:
Здравствуйте, Erop, Вы писали:

E>Груба говоря, все виртуальные наследники, даже и непрямые, должны действовть так: "Если виртуальная база ещё не создана -- создать"

Тоесть "не создана" определяется в рунтайм? — но это уже вопрос скорее топикстартеру
Re[11]: Виртуальное наследование
От: McSeem2 США http://www.antigrain.com
Дата: 10.09.07 13:40
Оценка:
Здравствуйте, Programador, Вы писали:

MS>>Таким образом, ты ведешь речь о сферической лошади в вакууме, никому на практике не нужной.

P>так это в идеальной задаче нужно чтото одно, а в реальной сегодня одно, завтра другое и то что позавчера не перестает быть нужно

Ну вот и ответ на вопрос. Надо обеспечить нормальную полиморфность с виртуальными функциями. А если их нет, то зачем тогда наследование?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[8]: protected vs private
От: Аноним  
Дата: 10.09.07 14:56
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Я пока знаю только одно приличное применение protected, и то оно там не используется: деструкторы std::unary_function, std::iterator и прочих невиртуальных интерфейсов.


я тебе еще одно подскажу. Есть класс для работы с http протоколом и класс для работы с http протоколом, который наследует первый класс. Медод int sk нужен и тому и другому классу, делаем его protected.

Можно делать всё публик, но тогда зачем юзать классы?, юзать структуры!, строчку public писать не нужно будет, и на одну строку будет кода меньше — но это выглядит не профессионально. У меня привычка закрывать от юзера данные, которые ему не нужно знать, а то он в еще в целях экономии памяти запишит, что — нибуть туда, ну или мало ли.

Читать профессиональный код намного приятней.

А protected'ить от самого себя данные — не вижу смысла, я то знаю какой метод для чего предназначен.

И еще мне одна идея пришла в голову, почему не нужно открывать все члены. Наверно есть ide или будут, которые не будут выдавать в списке членов, члены, которые закрыты, когда программист будет вводить оператор расширения области видимости.
Re[9]: protected vs private
От: Аноним  
Дата: 10.09.07 15:14
Оценка:
McSeem2 метод, который заменяется в наследнике, не всегда выгодно делать виртуальной, например когда ты вызываешь метод не через указательна на базовый класс, а через указательно на этот класс
Re[3]: Виртуальное наследование
От: s_viy  
Дата: 11.09.07 11:23
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, Аноним, Вы писали:


А>>Кстати про виртуальное наследование:

А>>давно интересуют примеры его использования в реальных программах.

RO>Есть вот такой баян, запрещающий наследование от определенного класса:

RO>
RO>class Final;

RO>class FinalHelper
RO>{
RO>friend class Final;
RO>private:
RO>    FinalHelper() { }
RO>};

RO>class Final: public SomeInterface, virtual private FinalHelper
RO>{
RO>    . . .
RO>};

RO>class Error: public Final // не-не
RO>{
RO>    . . .
RO>};
RO>

RO>Здесь конструктор FinalHelper должен будет быть вызван из конструктора Error (если бы наследование было невиртуальным, этот конструктор вызывался бы из конструктора Final), а Error не имеет к нему доступа, потому что он private.

Кстати где-то читал, что данную конструкцию нельзя создать на шаблонах, т.к. конструкция
template<typename T> class a{ friend class T;}
не соответствует стандарту. Вот пример который вроде не противоречит стандарту:

template<typename T>
struct type2type{ typedef T type; };

template<typename T>
class final;

template<typename T>
class final_helper
{
  friend class type2type< final<T> >::type;
  friend class type2type< T >::type;
private:
  final_helper(){};
};

template<typename T>
class final: virtual public final_helper< T >{};

class a: final<a>{};
class b: public a{};

void main()
{
  a aa;
  b bb; // error: К сожалению ошибку выдаст только при попытке создать объект, но все же лучше чем ничего
}
Re[12]: Виртуальное наследование
От: Erop Россия  
Дата: 11.09.07 13:11
Оценка:
Здравствуйте, Programador, Вы писали:

P>Тоесть "не создана" определяется в рунтайм? — но это уже вопрос скорее топикстартеру

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

Но в любом случае Каждый из конструкторов может быть вызван из более поздно написанного кода из другой единицы трансляции...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: protected vs private
От: jazzer Россия Skype: enerjazzer
Дата: 11.09.07 16:50
Оценка: 3 (1) +1
Здравствуйте, Аноним, Вы писали:

А>А protected'ить от самого себя данные — не вижу смысла, я то знаю какой метод для чего предназначен.


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

А кодирование в стиле "все паблик" применимо только к проектам типа "сдал и забыл" (курсовая, например).
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[4]: Виртуальное наследование
От: Аноним  
Дата: 12.09.07 16:26
Оценка:
Здравствуйте, s_viy, Вы писали:

>Кстати где-то читал, что данную конструкцию нельзя создать на шаблонах, т.к. конструкция

template<typename T> class a{ friend class T;}
не соответствует стандарту. Вот пример который вроде не противоречит стандарту:

>template<typename T>
>struct type2type{ typedef T type; };

>template<typename T>
>class final;

>template<typename T>
>class final_helper
>{
>  friend class type2type< final<T> >::type;
>  friend class type2type< T >::type;
>private:
>  final_helper(){};
>};

>template<typename T>
>class final: virtual public final_helper< T >{};

>class a: final<a>{};
>class b: public a{};
>void main()
>{
>  a aa;
>  b bb; // error: К сожалению ошибку выдаст только при попытке создать объект, но все же лучше чем ничего
>}
>

VS8 не компилится
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.