Виртуальные конструкторы

[Лёха]

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

В случае с деструкторами:
class A
{
public:
   A(){    cout << "A()\n";           };
   ~A(){  cout << "~A()\n";   };
};

class B : public A
{
public:
   B(){     cout << "B()\n";      };
   ~B(){   cout << "~B()\n";   };
};


int main(void)
{
   A * a = new B();
   delete a;
}

результат
 A()
 B()
 ~A()

результат если юзать virtual ~A()
 A()
 B()
 ~B()
 ~A()

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

В случае с конструкторами (если бы можно было так):
результат бы был
 A()
 ~A()

и/или конструкция типа ((В*)а)->someMember не допускалась бы

результат если юзать виртуальный конструктор (virtual A())
 A()
 B()
 ~B()
 ~A()


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

[Алексей++]

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

неверное утверждение, компилятор понятия не имеет, на что указывает a. Вернее имеет - он указывает на экземпляр класса A, просто этот класс имеет таблицу виртуальных функций, которые будут вызваны из класса B, так как именно адрес такого экземпляра был присвоен указателю a

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

видимо, в этом нет смысла, так как можно не знать, для чего вызывать ДЕСТРУКТОР, но ты всегда знаешь, экземпляр КАКОГО класа создаёшь - на стеке ли или через new. Всегда тип указан.
В общем - для начала придумай примеры использования виртуального конструктора

[McZim]

1. Нет никакого смысла в виртуальных конструкторах.
2. оформляй свой код тегами [ code ] [ /code ]

[Dimka]

Я просто пытаюсь понять почему конструктор не может быть виртуальным.

Потому что конструктор создаёт объект, а в C++-образных языках имя конструктора совпадает с именем класса. Моменты создания и инициализации объекта в таких языках совпадают. Поскольку до вызова конструктора объекта ещё нет, то вызов какого-либо конструктора приводит к созданию объекта именно того класса, в котором определён конструктор.

Код: (C++)

...
class X {};
class Y: public X {};
// создали объект класса X и вызвали конструктор по умолчанию подкласса Y,
// иначе автоматически вызовется конструктор не того класса.
X x = Y();
...

Так же обстоит дело в нетипизированных языках.

Код: (Javascript)

...
// Конструктор объектов типа X.
function X() {
}

/*
 * Переменная не имеет типа, тип X имеет лишь значение перемеменной - созданный при помощи
 * конструктора объект.
 */
var x = new X();
...

А вот в том же Object Pascal, где конструктор - не более чем разновидность рядовой процедуры, дело обстоит иначе. В этом языке синтаксически различается момент создания объекта определённого типа (выделение памяти под него) и момент вызова конструктора как процедуры инициализации созданного объекта начальными значениями. Поэтому виртуальные конструкторы в Object Pascal смысл имеют.

Код: (Text) Object Pascal

...
type
  TX = class
     ...
  end;
  TY = class(TX)
     ...
  end;
var
   PX: ^TX; { объявление указателя типа TX  }
   Y: TY; { объявление переменной типа TY и создание объекта типа TY до начала выполнения кода }
begin
   PX := @Y;
   PX^.Сreate; { вызов конструктора объекта для инициализации начальными значениями }
...

Хотя обычно пользуются выражениями типа:

Код: (Text) Object Pascal

...
Y := TY.Create; { явное указание класса конструктора }
...

1. Нет никакого смысла в виртуальных конструкторах.

Ты "в корне не прав" (c) Шаблон проектирования "фабричный метод" имеет второе название "виртуальный конструктор". Виртуальный конструктор инкапсулирует механизм создания конкретной разновидности объекта какого-либо класса, когда нам нужно абстрагироваться от этого механизма и связанного с ним разнообразния конкретных разновидностей (подклассов).

Код: (C++)

class A {};
enum Selector { SB, SC };
class B: public A {};
class C: public A {};

// Виртуальный конструктор
A *СreateA(Selector selector) {
   switch(selector) {
   case SB:
      return new B();
   case SC:
      return new C();
   default:
      return NULL;
   }
}

[McZim]

Узнав о виртуальных деструкторах, естественно спросить: "Могут ли
      конструкторы то же быть виртуальными?" Если ответить коротко - нет.
      Можно дать более длинный ответ: "Нет, но можно легко получить
      требуемый эффект".
      Конструктор не может быть виртуальным, поскольку для правильного
      построения объекта он должен знать его истинный тип. Более того,
      конструктор - не совсем обычная функция. Он может взаимодействовать
      с функциями управления памятью, что невозможно для обычных
      функций. От обычных функций-членов он отличается еще тем, что
      не вызывается для существующих объектов. Следовательно нельзя получить
      указатель на конструктор.
      Но эти ограничения можно обойти, если определить функцию,
      содержащую вызов конструктора и возвращающую построенный объект.
      Это удачно, поскольку нередко бывает нужно создать новый объект,
      не зная его истинного типа. Например, при трансляции иногда
      возникает необходимость сделать копию дерева, представляющего
      разбираемое выражение. В дереве могут быть узлы выражений разных
      видов. Допустим, что узлы, которые содержат повторяющиеся в выражении
      операции, нужно копировать только один раз. Тогда нам потребуется
      виртуальная функция размножения для узла выражения.
      Как правило "виртуальные конструкторы" являются стандартными
      конструкторами без параметров или конструкторами копирования

(c) Бьерн Страустурп.

[McZim]

dimka, я имел ввиду что нет смысла их деражать как стандартные функции. По крайней мере для меня.

[Лёха]

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

      Вот и строил бы конструктор НЕ правильно объект, не будучи виртуальным ... или строил бы не знаючи его истиный тип )

[Dimka]

или строил бы не знаючи его истиный тип )

Если бы, да кабы... В C++ это не так по объяснённым выше причинам, поэтому и обсуждать тут нечего.

[Лёха]

интересно девки пляшут

[McZim]

... или строил бы не знаючи его истиный тип )

так нельзя!

можно и нужно так

Код:

class expr {
      // ...
      public:
      expr(); // стандартный конструктор
      virtual expr* new_expr() { return new expr(); } //не стандартный конструктор
      };

      Виртуальная функция new_expr() просто возвращает стандартно
      инициализированный объект типа expr, размещенный в свободной памяти.

[Вад]

Зайдём с другой стороны

Код:

class A 
{
public:
    A(){}
}

class B 
: public A
{
public:
    B();
}

class C 
: public A
{
public:
    C();
}

и как прикажешь компилятору понимать, что создавать в конструкции

Код:

A var;
A* pVar = new A();

если у тебя конструктор "виртуальный"? A, B, или, может, C? Будет создаваться A. И точка. Ибо компилятор телепатическими способностями не наделён

[sss]

Блин, тема нонсенс для типизированных языков.

[Алексей++]

и как прикажешь компилятору понимать, что создавать в конструкции
Код:

A var;
A* pVar = new A();

не, пример неубедительный Будет создаваться A , даже если "конструктор виртуальный"

[Dimka]

Блин, тема нонсенс для типизированных языков.

Почему это? Для типизированного Object Pascal совсем не "нонсенс", но "нонсенс" для нетипизированного JavaScript.

Будет создаваться A.

Будет создаваться A , даже если "конструктор виртуальный"

В метафизическом смысле B и C - это тоже A. Поэтому, хотя вы и правы, но это ничего не объясняет А как тут сказать коротко, но ёмко, я ещё не придумал.

[Finch]

Лёха, Компилятор С++ долго не думает. Если есть двойственность построения участка кода, он просто отсылает "привет" в консоль. Чтобы программист сам определился, чего он хочет. При этом этот участок пропускается и объектный файл не строится. По названным dimka причинам, громоздить виртуальные конструкторы в С++ не имеет смысла. При написании кода, ты явно знаеш, какой именно класс будет использоваться, и соответственно его создаеш.
В С++ есть недочеты и сложности. Но это не один из них.

[Джон]

"Ну я на вас просто удивляюсь" (с)

Все согласны, что тема не имеет смысла, но продолжаете обсуждать. Блин, мне бы столько времени.

[sss]

dimka, что это за виртуальный конструктор в Object Pascal? Он виртуален только тем, что может указывать цепь конструкторов?

Код:

  type A = class
    constructor LoadFrom( filename: String); virtual;
  end;

  type B = class ( A)
    constructor LoadFrom( filename: String); virtual;
  end;

  class A
  {
     A( char* filename);
  }

  class B : A
  {
     B( char* filename) : A( filename) {};  // <= Виртуальный как в ObjectPascal ???
  }

Какая вообще виртуальность в JavaScript? Может быть не виртуальность, а использование VARIANT?

[zubr]

Хмм... В ObjectPascal виртуальный конструктор также бессмыслен. Насколько я помню теорию, таблица виртуальных методов в ObjectPascal создается в конструкторе, поэтому бессмысленно делать конструктор виртуальным. Кстати код:

Код: (Object Pascal)

...
type
  TX = class
     ...
  end;
  TY = class(TX)
     ...
  end;
var
   PX: ^TX; { объявление указателя типа TX  }
   Y: TY; { объявление переменной типа TY и создание объекта типа TY до начала выполнения кода }
begin
   PX := @Y;
   PX^.Сreate; { вызов конструктора объекта для инициализации начальными значениями }
...

не прокатит, будет аксесс виолейшн, так как объект Y не инициализирован. Тогда надо будет вызывать конструктор Y:

Код:

PX := @Y;
Y:=TY.Create;// или Y:=TX.Create;
PX^.Сreate;

Но тогда пропадает смысл виртуального конструктора.

[sss]

zubr, в CBuilder ( не уверен за VC) в конструкторе вообще нельзя вызывать виртуальные методы

Код:

  class A
  {
     A() { func();};
    virtual void func() { printf( "A::func");};
  }

  class B : A
  {
     B():A(){ };
    virtual void func() { printf( "B::func");};
  }

  void main()
  {
     B b;
  } 

Напечатает A::func. Отсюда можно сделать вывод, что перезапись таблицы на очередном уровне полиморфизма производится перед вызовом конструктора текущего в иерархии потомка.
Возможно, и скорее всего, слово virtual для конструкторов в ObjectPascal указывает компилятору, что конструктор должен быть вызван после полного заполнения VTM на всех уровнях иерархии.

[Dimka]

что это за виртуальный конструктор в Object Pascal? Он виртуален только тем, что может указывать цепь конструкторов?

Нет.

не прокатит, будет аксесс виолейшн, так как объект Y не инициализирован.

Вполне возможно, мне не на чем проверить.

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

Тем не менее, они есть.

Здесь приводится пример использования виртуальных конструкторов через метакласс в Object Pascal.
http://www.rsdn.ru/article/Delphi/delphiabs.xml
Здесь конкретный класс передаётся как экземпляр метакласса и определяется не во время компиляции, а во время исполнения, и вызов конструктора объекта есть вызов виртуального метода у экземпляра метакласса, коим этот конструктор и является. Моё объяснение выше про разделение времени создания и инициализации объекта было неправильным.

На самом деле, если бы в Object Pascal существовал бы более внятный механизм reflections, то писать "virtual" у конструктора не пришлось бы. Здесь же получается, что метаклассы упорядочены в такую же иерархию, как и их классы - только в этом смысле оправдана виртуальность конструктора.

Какая вообще виртуальность в JavaScript?

Выражение "виртуальный метод" имеет смысл лишь в ряде языков, например, в C++. Но наличие таких методов означает включение полиморфизма поведения объекта во время исполнения. В таких языках, как JavaScript, полиморфизм поведения объектов существует всегда и не отключается, поэтому выражение "виртуальный метод" для таких языков большого смысла не имеет. Но, поскольку мы тут общаемся на территории C++-ников, то не вижу ничего плохого в том, чтобы, для большей им понятности, говорить про "виртуальные методы" в том числе и в JavaScript, полагая, что в JavaScript все методы всегда "виртуальны".

И вообще я про "виртуальность" в JavaScript не говорил, я говорил о том, что "виртуальные конструкторы" в JavaScript не могут существовать на уровне синтаксиса этого языка, поскольку моменты создания и инициализации объекта неразделимы.

[Dimka]

в CBuilder ( не уверен за VC) в конструкторе вообще нельзя вызывать виртуальные методы

Насколько я понимаю, применительно к C++ из конструктора вызов виртуальных методов бессмысленен, поскольку конструктор предка выполняется ещё до выполнения конструктора потомка, и в момент работы конструктора предка виртуальные методы потомка просто ещё не определены. Хотя, быть может, это и не так - иначе будут проблемы с абстрактными методами. Но если это не так, то будут проблемы при работе самих виртуальных методов, поскольку они относятся к коду потомка, а объект как объект класса потомка ещё не определён - атрибуты потомка ещё не инициализированы.

[sss]

dimka, так зачем тогда слово virtual в ObjectPascal для constructor? Зачем было вообще в тему ANSI С++ замешивать ObjectPascal, который до компиляции выполняет над иерархиями классов дополнительную, работу  "являющуюся деталью реализации, скрытой от программиста"?

Квадратура круга forever..

[Лёха]

McZim привел хороший пример

Код:

class expr {
      // ...
      public:
      expr(); // стандартный конструктор
      virtual expr* new_expr() { return new expr(); } //не стандартный конструктор
      };

       Сдесь на этапе компиляции не известно объект какого типа будет создаваться. Возможно я хотел что бы именно виртуальный конструктор заменял примеры подобного рода.
Товарищи ... кинте ссыллок, кто сколько сможет ) на статьи по поводу виртуальных функций, VTBL, хочеццо  подробнее узнать про тайну третьей планеты )

[Алексей++]

Сдесь на этапе компиляции не известно объект какого типа будет создаваться

expr и будет создаваться )

[Dimka]

Зачем было вообще в тему ANSI С++ замешивать ObjectPascal, который до компиляции выполняет над иерархиями классов дополнительную, работу  "являющуюся деталью реализации, скрытой от программиста"?

Для общего развития. Автор темы заявил, что пытается понять, почему конструктор не может быть виртуальным. И ему тут объясняют, почему не может именно в C++ - для этого нужен Object Pascal .

И о какой же "скрытой от программиста" реализации идёт речь, если программист явно программирует эту "дополнительную работу над иерархиями классов"?

[sss]

Так это же цитата из статьи http://www.rsdn.ru/article/Delphi/delphiabs.xml 

[Dimka]

sss, и что? Статья - не откровение. Не надо литературные приёмы автора буквально принимать на веру. А вот в виртуальные конструкторы верить не нужно - нужно лишь проверить в Delphi или Free Pascal

[RXL]

Сдесь на этапе компиляции не известно объект какого типа будет создаваться

expr и будет создаваться )

Метод виртуальный - в классе-потомке может быть создан другой объект. Правильнее сказать, что вызывающая метод программа не может знать, указатель на объект какого типа вернется (но точно известно, что или expr, или его потомки).

[sss]

dimka, так что же все таки обозначает virtual constructor в ObjectPascal? Интересно. Я как раз не только не верю в виртуальные конструкторы, но и вообще все время пытаюсь доказать об несуществующем термине. Я так понимаю: в ObjectPascal вызов виртуального конструктора вначале выделяет память под объект класса, заполняет всю связанную с классом информацию (RTTI, VTM), а затем просто вызывает метод, обрамленный в определении класса как virtual constructor.

[Dimka]

Я как раз не только не верю в виртуальные конструкторы, но и вообще все время пытаюсь доказать об несуществующем термине.

Вот доказывать несуществование термина, когда термин употребляется в Object Pascal и в шаблонах проектирования - занятие бессмысленное. Нужно разобраться в том, какой смысл вкладывают авторы в этот термин.

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

Это уже несколько выходит за рамки раздела о C++ и подходит для раздела о Delphi, но всё же:

Я так понимаю: в ObjectPascal вызов виртуального конструктора вначале выделяет память под объект класса, заполняет всю связанную с классом информацию (RTTI, VTM), а затем просто вызывает метод, обрамленный в определении класса как virtual constructor.

Ты понимаешь, что такое метакласс? Для чего появились метаклассы сперва в Smalltalk, а потом расползлись по другим языкам?

[McZim]

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

[zubr]

sss, дело в том, что в Delphi (в отличие от C++) в конструкторе класса-наследника конструктор родительского класса автоматически не вызывается, его можно вызывать (а можно не вызывать, правда последствия могут быть разными) с помощью ключевого слова inherited. То есть конструктор родительского класса вызывается как обычный метод, отсюда - почему бы ему не быть виртуальным?

[sss]

Ты понимаешь, что такое метакласс? Для чего появились метаклассы сперва в Smalltalk, а потом расползлись по другим языкам?

Дак объясни наконец что такое матакласс. Никогда не пользовался. Два раза спрашивал - что значит virtual constructor?

zubr, ни фига подобного... Или фига подобного? Может именно когда virtual constructor такое поведение?

[zubr]

zubr, ни фига подобного... Или фига подобного? Может именно когда virtual constructor такое поведение?

Код:

TA = class
  private
  public
    constructor Create;
  end;

  TB = class(TA)
  public
    constructor Create;
  end;


constructor TA.Create;
begin
 MessageBox(0, 'A', '', MB_OK);
end;

constructor TB.Create;
begin
 inherited Create;
 MessageBox(0, 'B', '', MB_OK);
end;


procedure TForm1.Button1Click(Sender: TObject);
var
  b:TB;
begin
 b:=TB.Create;
end;

При нажатии на Button1 выскакивает сначала A затем B. Если конструктор TB  сделать без inherited то только В. Все тоже самое если объявить:

Код:

TA = class
  private
  public
    constructor Create; virtual;
  end;

  TB = class(TA)
  public
    constructor Create; override;
  end;

[sss]

А как инициализированы члены класса? Зарезервированным словом default? А конструкторы классов членов вызываются?

Все сдаюсь... Надоело говорить про Delphi в теме об ANSI C++. Только не знаю, что признать то? Суверенитет ObjectPascal???

[zubr]

А как инициализированы члены класса? Зарезервированным словом default? А конструкторы классов членов вызываются?

Если не вызовешь конструктор родителя, то никак...

[Dimka]

Дак объясни наконец что такое матакласс. Никогда не пользовался.

Как известно, в типизированных языках объекты называют другими словами экземплярами классов. Метакласс - это класс классов, по отношению к которому уже классы являются экземплярами метакласса. Так сказать, класс второго порядка.

Например, в Java есть класс Class, который, как и всякий класс, является потомком класса Object, но класс Class есть такой класс, экземплярами которого являются все прочие классы (в том числе и Object, и даже сам класс Class) - т.е. класс Class фактически является метаклассом, хотя формально он тоже класс (тип данных) в языке.

Тоже самое в языках .NET: есть класс Type, экземпляры которого описывают другие классы (и могут описывать самого себя) - т.е. класс Type фактически является метаклассом, хотя формально является классом. Объекты типа Type играют важную роль в механизме reflections, при использовании которого код программы можно обрабатывать (другим кодом) как данные.

Для чего это нужно? Для того, чтобы была возможность передать информацию о типе во время исполнения как данные. В этом случае класс рассматривается не как синтаксическая конструкция времени программирования и компиляции, а как данные (экземпляр метакласса) времени исполнения со всеми нужными свойствами (в частности, ссылкой на конструктор, возможно, коллекциями ссылок на методы, свойства и т.д., перечнем реализуемых интерфейсов, ссылкой на класс-предок и т.д. - зависит от конкретного языка программирования).

Пример из .NET, аналогичный примеру из Delphi, будет таким:

Код: (Text)

using System;
using System.Reflection;

namespace Program
{
    class Program
    {
        class A
        {
            public A()
            {
                Console.WriteLine("A");
            }
        }

        class B: A
        {
            public B()
            {
                Console.WriteLine("B");
            }
        }

        static A CreateA(Type type)
        {
            // Извлекаем из описания класса информацию о его конструкторе.
            // Выбираем из всех конструкторов по их сигнатурам конструктор без параметров -
            // конструктор по умолчанию.
            Type[] constructorArgumentsTypes = new Type[0];
            ConstructorInfo constructor = type.GetConstructor(constructorArgumentsTypes);
               
            // Вызываем конструктор по умолчанию неизвестного класса и получаем объект этого
            // неизвестного класса.
            object[] constructorArguments = new object[0];
            object instance = constructor.Invoke(constructorArguments);

            // Пытаемся привести объект неизвестного класса к классу A, если неудачно, то возвращаем null.
            return instance as A;
        }

        static void Main(string[] args)
        {
            A a;

            a = CreateA(typeof(A));
            Console.ReadLine();

            a = CreateA(typeof(B));
            Console.ReadLine();
        }
    }
}

В результате получаем:

Код: (Text) Вывод программы

A

A
B

Если отказаться от приведения к A, то таким образом можно создать любой объект любого типа, но "виртуальности" конструкторов в явном виде здесь нет, в отличие от Object Pascal.

В Object Pascal конструктор нужно объявлять "виртуальным" по всей видимости лишь для того, чтобы указатель на него попал в таблицу виртуальных методов, а эта таблица используется как данные в экземпляре метакласса.

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

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

"Оба" - это ты оптимист. Всё ещё только начинается

[Алексей++]

а я оптимист, базару нету ))

[Лёха]

Сдесь на этапе компиляции не известно объект какого типа будет создаваться

expr и будет создаваться )

Ты слишком придераешся к моим словам ... ну это ладно ... 
Возможно я отступаю от темы, но всётаки кинте ссылок на тему виртуальных функций, возможно это даст мне ответы на кое какие вопросы, Спасибо.

[McZim]

Лёха, наздоровье.

http://lib.ru/CPPHB/cpptut.txt_with-big-pictures.html

[lapulya]

Finch'у +1, просто супер, коротко и четко... и добавить нечего.

Лёха,

Сдесь на этапе компиляции не известно объект какого типа будет создаваться

expr и будет создаваться )

Совершенно верно пишет пушистый, тут точно известно, что будет создаваться.

RXL,

Сдесь на этапе компиляции не известно объект какого типа будет создаваться

expr и будет создаваться )

Метод виртуальный - в классе-потомке может быть создан другой объект. Правильнее сказать, что вызывающая метод программа не может знать, указатель на объект какого типа вернется (но точно известно, что или expr, или его потомки).

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

[RXL]

lapulya, опять у нас недопонимание... Ответь, пожалуйста, развернуто.

[Dimka]

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

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

Другое дело, что для создания экземпляра конкретного класса нужно иметь конкретную же фабрику, поэтому тот пример вопрос про создание произвольного объекта не решает сам по себе, а лишь позволяет вынести выбор конкретного класса создаваемого экземпляра в другую часть системы, которая на основании каких-либо данных выберет, какую конкретную фабрику создать.

Или, другими словами, фабрика (как шаблон проектирования) позволяет разделить во времени момент (и в пространстве кода место) выбора типа создаваемых объектов и момент (и место в коде) создания самих объектов.

[Лёха]

http://lib.ru/CPPHB/cpptut.txt_with-big-pictures.html

это ведь второе издание Страуструпа, у мну оно уже есть
там не много инфы по поводу vtbl

[lapulya]

RXL, Сорри, я был не внимателен (с чего то придумал себе, что функция из конструктора вызывается)... все верно. И точно димка подметил, что это как правило (но далеко не всегда и на эту тебу есть и шаблон проектирования, хотя я им никогда не пользовался) выносится из класса в фабрику.