Здравствуйте, Кодт, Вы писали:

К>Не в первую очередь. Далеко не в первую.
Спорить не буду. Просто я использую виртуальные функции чаще всего именно так. А приминительно к исколючениям, я вообще не использую виртуальные функции. Ловлю (стараюсь ловить) каждое исключение своим обработчиком, так, мне кажется, более информативно получается. А вообще, я просто высказывал свое мнение, основанное на собственном опыте

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

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

L>>>А взять хотя бы механизм виртуальных функций? Он же вообще без указателей теряет смысл!
W>>Вот пример, демонстрируюший работу механизма виртуальных функций без использования указателей:
L>Я не говорил, что виртуальные функции невозможны без указателей. Я говорил, что смысл теряется. Ссылка должна быть инициализирована при создании и это ее главный минус (в контексте работы с виртуальными функциями). Можно, конечно, изварачиваться через функции вида A& getThis(){return *this;}, но тут опять работа со ссылками... (this то же указатель)

L>На сколько я понимаю прелести виртуальных функций, они в первую очередь служать для того, чтобы иметь массивы указателей на однотипные объекты, хотя на самом деле объекты разные, но выведенные из одного базового класса (сам не понял че сказал ). А массив ссылок.. Это как-то грусно звучит.

Ну почему именно массивы. Основное предназначение виртуальных функций — переопределение поведения базового класса.
Я же хотел подчеркнуть, что можно прекрасно использвать этот механизм, не используя указателей.
Например есть некая функция, которая принимает ссылку на базовый класс и вызывает у него виртуальные функции. Можно передать в нее наследника и все будет работать без всяких указателей и без потери смысла.

class Base
{
  ...
  virtual void f() {}
};

class Derived : public Base
{
  ...
  virtual void f() {}
};

void UsefulFunc(Base& base)
{
  ...
  base.f();
  ...
}

...
Derived d;
UsefulFunc(d);
...

и никаких указателей.

Я не против указтелей. Я за точность формулировок.

Здравствуйте, Кодт, Вы писали:

К>Про
К>

К>{
К>  Base& ref = make_derived(); // результат выражения make_derived() - временный объект типа Derived
К>  ...
К>  access_to_base(ref);
К>  ...
К>}// вот здесь заканчивается время жизни того анонимного объекта, доступного через ref
К>

Что самое неприятное — привязка к rvalue работает только при такой записи.
Нет никакого способа инициализировать константную ссылку-член класса rvalue извне так, чтобы соответствующим образом продлилось время жизни — ссылка-то проинициализируется молча, а временный объект тут же и умрет и мы словим access violation или еще чего хуже.

You will always get what you always got
  If you always do  what you always did

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

А>В чем разница между reference & и pointer *?
А>Или же они заменяют друг друга...

Ссылка (reference) является альтернативным именем объекта.
Объявление переменной в качестве ссылки на другую переменную определяет ее алиас.

int i         = 1;
int& iref = i;        // i и iref ссылаются на одно и то же целое

Операций над ссылками не существует. Хотя выражение iref++ (эквивалентное
iref = iref + 1) допустимо, но оно не увеличивает ссылку iref, оператор ++ применяется только к целому значению i.
Как следствие, значение ссылки нельзя изменить после инициализации. Она всегда ссылается на объект, которым инициализирована.
Чтобы получить указатель на объект, именем которого является ссылка iref, мы можем написать

int* p = &iref;

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

int i  = 1;   int& iref = i;   iref++;  int* p = &iref;

можно смоделировать следующим образом:

int i  = 1;     int* const iref = &i;     (*iref)++;   int* p = &(*iref);

При этом надо понимать, что ссылка, в отличие от указателя, не является объектом, над которым можно выполнять операции.