Как класс преобразовать в структуру ?

struct Stack  
{
  private:
     int size;
     int top;
     int* values;
  public:
     Stack(int size = DEFAULT_SIZE);
     virtual ~Stack();
     bool isFull();
     bool isEmpty();
     void push(int);
     int pop();
};


// не? :)

А почему в данном классе единственный виртуальный метод - это деструктор?

> А почему в данном классе единственный виртуальный метод - это деструктор?

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

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

Любопытно было бы их узнать, заодно и узнать, почему в STL-е практически нет виртуальных деструкторов.

> Любопытно было бы их узнать, заодно и узнать, почему в STL-е практически нет виртуальных деструкторов.

Потому что STL - это не ООП ;) Я серьезно. Ни один кретин не будет создавать наследника от STL класса, что-бы потом работать с ним через указатель на базовый класс. Можно предложение сократить до "ни один кретин не будет создавать наследника от STL класса (кроме очень редких исключений, где это оправданно)".

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

Кстати, еще одна из причин, почему в STL-е нет виртуальных деструкторов - не особая дружба между виртуальными функциями (с реализацией) и шаблонами :)

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

термин concrete class ничего не говорит?

// wbr

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

Для чего наследоваться от стека и потом хранить его полиморфно, я не совсем понимаю, ну ладно, память сейчас дешёвая, 4 байта на стек не жалко :)

> Кстати, еще одна из причин, почему в STL-е нет виртуальных деструкторов - не особая дружба между виртуальными функциями (с реализацией) и шаблонами :)

А теперь здесь подробнее, пожалуйста :)

> термин concrete class ничего не говорит

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

> А теперь здесь подробнее, пожалуйста :)

gcc в принципе сожрет такое, насколько я знаю, но в целом, AFAIK, стандартном не определоно поведение для вот такого:

class ...
{

inline virtual void abc()
{
}
};

а все инстанцинируемые шаблонные функции следует рассматривать именно как inline методы, т.к. в общем случае инстанцинация будет производится на каждую еденицу компиляции. Такую вещь как extern template .... стандартизирут только в C++0x.

Собственно в чем проблема с inline virtual, - а в том, что указывать в таблице виртуальных функций собственно и некуда - код заинлайнился, и все, - куда тыкать то? :) А если и не заинлайнился, то получаем несколько экхемляров функции на каждый модуль кода, и опять-же, фиг его знает какие косяки с этим могут всплыть.

Да не заинлаинится такая функция, даже если ворнинга не будет.

Читаем внимательно и до конца..

"А если и не заинлайнился, то получаем несколько экхемляров функции на каждый модуль кода, и опять-же, фиг его знает какие косяки с этим могут всплыть."

> И ? Я не понимаю, куда вы клоните. Или вы из тех, кто считает что необязательно диструкторы делать виртуальными? :)

для конкретных классов? да, для них нет необходимости объявлять деструкторы виртуальными. от них никто не наследуется, на то они и конкретные. если в классе вообще есть необходимость в деструкторе [далеко не всегда она есть].

// wbr

а как же - "делаите деструкторы открытыми и виртуальными или защищенными и невиртуальными"

> для конкретных классов? да, для них нет необходимости объявлять деструкторы виртуальными. от них никто не наследуется, на то они и конкретные. если в классе вообще есть необходимость в деструкторе [далеко не всегда она есть]

Это вы рассказывать можете преподу, здавая код :)

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

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

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

// wbr

> а как же - "делаите деструкторы открытыми и виртуальными или защищенными и невиртуальными"

это откуда такое "как же"?

// wbr

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

Предварительно возмонжо портатив кучу времени (и денег), на поиски виновных

> Предварительно возмонжо портатив кучу времени (и денег), на поиски виновных

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

// wbr

>а все инстанцинируемые шаблонные функции следует рассматривать именно как inline методы, т.к. в общем случае инстанцинация будет производится на каждую еденицу компиляции

Бред.

> Бред.

необоснованный гон.

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

> Покажите на простом примере, где именно шаблоны и виртуальность дают неожиданные результаты, я тоже не совсем понимаю, что вы имеете в виду.

Ну во первых это просто идеологически некрасиво, смешивать два типа полиморфизма воедино (статический и динамический).

загуглив нашел такие варианты описания, почему нельшя темплейты и виртуальные методы (не-pure, а с реализацией):

1. Самое грозное:

The ANSI/ISO Standard says (14.5.2 p 3): "A member function template shall not be virtual." [взято с http://www.devx.com/tips/Tip/5738 ]

2. развернуто "почему" :

Templated virtual functions need whole-program analysis and code generation in the link phase, because a templated virtual function (if it existed in C++) is short for an _infinite_ potential set of virtual functions, which can only be handled properly by backpatching when the full set of actual instantiations is known.

That is very impractical with dynamically loaded libraries.

Dynamic libraries are not supported by the standard, but since they are very common the standard cannot stand in the way. So instead of imposing special, costly requirements, the standard is mostly silent. The only place I know that the standard goes out of its way to support dynamic libraries is in the wording of initialization of statics.

[ http://www.velocityreviews.com/forums/t288338-virtual-templates.html ]

//fmj, пароль помнит только кукиз браузера на работе

Все понятно, перепутали

template <...> 
class A {
    virtual void f ();};

class B {
    template <...>
    virtual void f() {};};

Первый можно, второй нет.

А также понятно откуда сравнение с inline функциями. 
(указатель нелься взять)

> Первый можно, второй нет.

ugu..

template <class SVC_HANDLER, ACE_PEER_ACCEPTOR_1>
class ACE_Acceptor : public ACE_Service_Object
{
  virtual int open (const ACE_PEER_ACCEPTOR_ADDR &local_addr,
                    ACE_Reactor *reactor = ACE_Reactor::instance (),
                    int flags = 0,
                    int use_select = 1,
                    int reuse_addr = 1);

  virtual ~ACE_Acceptor (void);

  virtual operator ACE_PEER_ACCEPTOR &() const;

  virtual ACE_PEER_ACCEPTOR &acceptor (void) const;

  virtual ACE_HANDLE get_handle (void) const;

  virtual int close (void);
  ......
}

и ведь живёт же и ничего (c) ACE.

// wbr

а где тут member templates?

>>(void)

суровые сишники суровы :)