Interesting C/C++ interview questions

[Krokodil]

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

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

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

[Hamster]

У объявления деструктора виртуальным такие последствия:
будет создаваться vtable, даже когда он не нужен;
объект будет из-за этого занимать больше места;
деструктор будет всегда вызываться через vtable и его вызов не может быть inlined. Даже если тело деструктора пустое.

[Krokodil]

У объявления деструктора виртуальным такие последствия:
будет создаваться vtable, даже когда он не нужен;
объект будет из-за этого занимать больше места;
деструктор будет всегда вызываться через vtable и его вызов не может быть inlined. Даже если тело деструктора пустое.

Согласен со всем, но не могу понять почему последствия столь фатальны что людей нельзя допускать до программирования Несколько байт потерянной памяти и накладные на вызов функции вместо инлайна? У нас в конторе у многих выработался рефлекс описывать деструкторы virtual. Когда их спрашиваешь почему, то они говорят, что ТАК НАДО. Это сущие мелочи, по сравнению с другими вещами которые призодилось видеть...

[Vovka]

Согласен со всем, но не могу понять почему последствия столь фатальны что людей нельзя допускать до программирования

Ну, "недопуска до программирования" я там смайлик поставил, и не такое бывает.

А по сути - вам Hamster уже ответил. Если объекты маленькие и их много, то это может иметь значение.

Ещё есть причины:
1. (идеологическая) если что-то не необходимо, то это не нужно.
2. (педагогическая) если человек пишет вирт. дест. всегда, то он, быть может, не знает, когда и почему они нужны.
3. (технологическая) виртуальность деструктора ещё является чем-то вроде документации о назначении и использовании данного класса. Если деструктор не виртуальный - значит класс не может (и не предназначен) быть базой, и соответственно наоборот.

[uncle_Pasha]

Ну, "недопуска до программирования" я там смайлик поставил, и не такое бывает.
Ещё есть причины:
1. (идеологическая) если что-то не необходимо, то это не нужно.
2. (педагогическая) если человек пишет вирт. дест. всегда, то он, быть может, не знает, когда и почему они нужны.
3. (технологическая) виртуальность деструктора ещё является чем-то вроде документации о назначении и использовании данного класса. Если деструктор не виртуальный - значит класс не может (и не предназначен) быть базой, и соответственно наоборот.

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

Лишние байты - это ерунда. "Если деструктор не виртуальный - значит класс не может (и не предназначен) быть базой" - это Вы так решили для этого класса. А когда-нибудь, на n-ном году жизни проекта, кто-то иной решит иначе. И не проверит. А на n+1-ом году жизни еще кто-то сделает указатель на базовый класс....

Нет уж. Лучше пусть пишут виртуальный, даже если не понимают, зачем это надо.

Удачи!

[A. Fig Lee]

Согласен со всем, но не могу понять почему последствия столь фатальны что людей нельзя допускать до программирования :Д

Ну, "недопуска до программирования" я там смайлик поставил, и не такое бывает. :мргреен:

А по сути - вам Хамстер уже ответил. Если объекты маленькие и их много, то это может иметь значение.

Ещё есть причины:
1. (идеологическая) если что-то не необходимо, то это не нужно.
2. (педагогическая) если человек пишет вирт. дест. всегда, то он, быть может, не знает, когда и почему они нужны.
3. (технологическая) виртуальность деструктора ещё является чем-то вроде документации о назначении и использовании данного класса. Если деструктор не виртуальный - значит класс не может (и не предназначен) быть базой, и соответственно наоборот.

Наоборот. Я бы Вас не допуска. Виртуальный дестрактор - ето сейф. Сделал и забыл. Годится практически везде. Невиртуальный - вещь очень скользкая надо об етом всегда помнить и быть начеку. Нет, такой хокей нам не нужен!

[Krokodil]

Наоборот. Я бы Вас не допуска. Виртуальный дестрактор - ето сейф. Сделал и забыл. Годится практически везде. Невиртуальный - вещь очень скользкая надо об етом всегда помнить и быть начеку. Нет, такой хокей нам не нужен!

Кто здесь допуски выдает? Выдайте мне пожалуйста!

[Vovka]

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

Иначе решить нельзя.
Если класс в самом начале не задумывался как базовый, то он таким быть не должен. Если хотите реюзить - включите это класс как данные. Если у класса нет виртуальных методов и protected членов (а у класса без вирт. дуструктора таких быть просто не может), то не может быть ни одной причины предпочесть наследование включению.

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

[TLK]

кто только писал, блин, STL для шестой студии?

DinkumWare.
Take a look at some patches for MSVC STL:

http://www.dinkumware.com/vc_fixes.html

[jawabean]

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

[uncle_Pasha]

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

Иначе решить нельзя.

Опасность в том, что ++ проекты - они долгоживущие (в смысле, живут дольше программистов, их начинавших). Спустя время, кому-то "Иначе решить нельзя" может не показаться столь безаппеляционным.

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

Если класс не задумывался как базовый, почему бы не использовать struct?
Может это кого-то и остановит в будущем?

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

это я совсем не понял...
За сим и откланиваюсь.

Удачи!

[tchicago]

Ну вот, сейчас еще и скучающие C++-ники переругаются между собой. Может еще использование goto обсудить?

Встречал такой вопрос (скорее, не вопрос, а предложение темы для разговора): где и когда используется ключевое слово friend? Хорошо это или плохо? Почему?

[interrupt]

Наоборот. Я бы Вас не допуска. Виртуальный дестрактор - ето сейф. Сделал и забыл. Годится практически везде. Невиртуальный - вещь очень скользкая надо об етом всегда помнить и быть начеку. Нет, такой хокей нам не нужен!

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

[yocto]

Если класс не задумывался как базовый, почему бы не использовать struct?
Может это кого-то и остановит в будущем?

Так ведь объявление типа через struct не запрещает наследование.

[uncle_Pasha]

Если класс не задумывался как базовый, почему бы не использовать struct?
Может это кого-то и остановит в будущем?

Так ведь объявление типа через struct не запрещает наследование.

Оно объясняет смысл данного элемента данных.
99% что никому не прийдет в голову наследоваться от struct в дальнейшем

Удачи!