Interesting C/C++ interview questions

[Boriskin]

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

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

[AndreyT]

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

Вопрос формулируется обычно (4 из 4ех моих последних интервью) следующим образом - "в каких ситуация деструктор должен быть виртуальным и почему?" Четкий вопрос -> четкий ответ

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

Например, наиболее низкоуровневый формально правильный ответ на этот вопрос сформулирован в спецификации языка: класс 'A' должен иметь виртуальный деструктор тогда, когда программа содержит полиморфные удаления объектов-наследников класса 'A' через указатель типа 'A*'.

С точки зрения программного дизайна, это ответ не совсем хорош, несмотря на свою правильность, ибо он, скажем так, непрактичен. Тут более "правильными" являются ответы типа того, что можно увидеть на сайте Страуструпа (см. ссылку в одном из предыдущих сообщений) - виртуальный деструктор нужен тогда, когда класс уже содержит и другие виртуальные функции. Этот ответ не является 100%-но правильным с формальной точки зрения, но с чисто практической точки зрения он весьма и весьма хорош.

Зачастую можно услышать и такой вариант: если класс используется в качестве базового класса, то он должен имет виртуальный деструктор. Этот ответ в общем случае совершенно не верен. Хотя он может имет определенную ценность в кругу людей, зациклившихся на трактовке языка С++, как языка традиционного ООП, т.е. ООП базирующегося на run-time полиморфизме. У людей, умеющих использовать GP (generic programming) свойства С++ такой ответ может вызвать только недоумение. Тем не менее можно запросто встретить интервьюера, ожидающего именно такой "четкий ответ" и считающего все остальные ответы неверными.

[Quintanar]

Unix haters handbook about C++:

Q. Where did the names "C" and "C++" come from?
A. They were grades.

It was perhaps inevitable that out of the Unix philosophy of not ever making anything easy for the user would come a language like C++.
....

[Boriskin]

Вопрос формулируется обычно (4 из 4ех моих последних интервью) следующим образом - "в каких ситуация деструктор должен быть виртуальным и почему?" Четкий вопрос -> четкий ответ

Это вопрос не является четким.

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

[muzhik]

мне C# больше нравится именно как язык - он исправляет некоторые недостатки C++ как OO языка (struct, multiple inheritance), и при этом не уродует его как Java.

Елси я правильно понял, вы считаете что выделенное есть нехорошо? Почему так?

Это ерунда какая-то. Независимое дополнительное свойство языка никак не может являться недостатком. В принципе.Никто никого не заставляет использовать mutliple inheritance в С++. Поэтому о назывании mutliple inheritance "недостатком" не может быть и речи.

Коротко говоря, главный недостаток всех этих фичеров - и multiple inheritance, и virtual destructors - в не-дуракоустойчивости. Мы по привычке продолжаем воображать, что программеры все сплошь молодые таланты. А на самом деле программирование давно стало массовым ремеслом, и апологеты C++ напоминают фанатов Юникса, утверждающих, что домашний юзер должОн юзать только самый крутой FreeBSD или Линух.

Я тоже апологет C++ - но ИМХО пришла пора признать, что крутое владение C++ и знание заковыристых фичеров - мало кому реально нужно на рынке. А нужно - план по валу, и тут "заковырки" скорее мешают, чем помогают. то с одной стороны. А с другой стороны - Вам давно приходилось дебагить чужой код, использующий diamond multiple inheritance? (Ну, я так понял, что упоминать национальность автора того кода на Привете запрещено Лигой Защиты Индусов?... молчу, молчу...)

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

Вернее - попытка спасти программу от разрушения в будущем - ведь никто не даёт 100% гарантии от привнесения багов при последующей разработке...

А что до соответствия кода дизайну... ну нельзя же быть таким наивным в 2004 году!

Если какой-то неуч в последующем сделает такую глупость, как попытается полиморфно удалить объект класса без виртуального деструктора, то решать проблему надо путем давания такому неучу по голове учебником по С++ дизайну. И не одним.

Он не попытается "полиморфно удалить". Он попытается просто удалить.

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

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

Кстати, комплимент за комплимент - очень тяжело работать с человеком, который считает себя непогрешимым и подразумевает, что другие такие же непогрешимые - даже если сам он действительно ошибается крайне редко, то ожидать того же от ВСЕХ - просто нелогично.

[muzhik]

Я уже как-то приводил пример неправильности использования виртуального деструктора. Напомню. XML парсер - миллионы объектов, большинство которых ссылается на ту или иную общую "схему, описание", то есть занимает в памяти 4 байта. Если для "удобства" или "как всегда" сделать деструктор виртуальным получите 8 байт на объект, а теперь умножьте эти дополнительные 4 байта на несколько миллионов. Щедрая плата за то, чтобы не думать.

Да, верно. Но похоже, что подобные случаи экономии памяти - это ЕДИНСТВЕННЫЕ случаи, когда виртуальный деструктор себя не оправдывает. Может быть, Вы можете привести другой недостаток virtual destructors, кроме расходования памяти на поинтер на vtable?

И надо заметить, что класс, где мы НЕ ставим виртуальный деструктор - должен быть довольно небольшим изначально. У нас в компиляторе - похожая ситуация с expressions - типа b[5-i]+c[1]/d[i*7] - их масса в компилируемом коде, а код наших клиентов довольно велик; но всё равно наши expressions имеют виртуальные деструкторы, потому что для нас довольно часто maintainability важнее памяти.

В Вашем примере 4 х миллионы объектов - это ещё десяток-другой мегабайт памяти. Мне не кажется, что сегодня это - критичный параметр; хотя, конечно, задачи бывают самые разные...

Хотя он может имет определенную ценность в кругу людей, зациклившихся на трактовке языка С++, как языка традиционного ООП, т.е. ООП базирующегося на run-time полиморфизме. У людей, умеющих использовать GP (generic programming) свойства С++ такой ответ может вызвать только недоумение. Тем не менее можно запросто встретить интервьюера, ожидающего именно такой "четкий ответ" и считающего все остальные ответы неверными.

Штука в том, что классически виртуальное наследование (в частности, multiple, вирт. д-торы, етц) - считаются признаками "асовского" владения C++, a основа GP - templates - "макросами высокого уровня". Так сложилось исторически. Это раз. И два - полиморфизм всё-таки более "живой"; написать generic container с помощью полиморфизма - достаточно легко; а имплементировать RTTI с помощью GP - будет изрядным геморроем.

Так вот массовое объявление деструкторов виртуальными там, где они не нужны - это ни что иное, как попытка спасти от падения уже разрушенную программу. Это пример одной из самых грубых ошибок, которые могут существовать в С++ программировании (да и не только в С++ программировании).

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

ИМХО, это не "такая же" ошибка. Использование ведёт к расходу памяти, неиспользование - может привести к крэшу. Теоретически - надо ставить v.dtor только там, где есть виртуальное наследование; практически - it's a good habit.

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

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

ИМХО, отвечать надо чётко, но по максимуму развёрнуто. Т.е., что-то типа "д-тор должен быть виртуальным, если класс предназначен для виртуального наследования, то есть - <краткое объяснение>".

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

Во-во, это я и имел в виду в прошлом постинге.

[roadman]

Я уже как-то приводил пример неправильности использования виртуального деструктора. Напомню. XML парсер - миллионы объектов, большинство которых ссылается на ту или иную общую "схему, описание", то есть занимает в памяти 4 байта. Если для "удобства" или "как всегда" сделать деструктор виртуальным получите 8 байт на объект, а теперь умножьте эти дополнительные 4 байта на несколько миллионов. Щедрая плата за то, чтобы не думать.

Да, верно. Но похоже, что подобные случаи экономии памяти - это ЕДИНСТВЕННЫЕ случаи, когда виртуальный деструктор себя не оправдывает. Может быть, Вы можете привести другой недостаток virtual destructors, кроме расходования памяти на поинтер на vtable?

In my opinion, one example it's more then enough to start thinking before implementation. The example I provided was taken from a REAL development. My point is there are no silver bullets. Good C++ programmer understands what he/she is doing, no just blindly applying rules because they work in 95% cases. And on interview the answer depends on what's your REAL experience - not just "book" knowledge. This is an original topic issue. And this is how your answer will reflect your REAL experience.

[Boriskin]

Коротко говоря, главный недостаток всех этих фичеров - и multiple inheritance, и virtual destructors - в не-дуракоустойчивости.

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

Я тоже апологет C++ - но ИМХО пришла пора признать, что крутое владение C++ и знание заковыристых фичеров - мало кому реально нужно на рынке. А нужно - план по валу, и тут "заковырки" скорее мешают, чем помогают. то с одной стороны.

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

А с другой стороны - Вам давно приходилось дебагить чужой код, использующий diamond multiple inheritance? (Ну, я так понял, что упоминать национальность автора того кода на Привете запрещено Лигой Защиты Индусов?... молчу, молчу...)

Приходилось, как же без этого. "Входит, выходит; входит и выходит! " (с) Правда написано было не индусами, так что все работало как и должно было; поначалу не совсем все понятно, но как только иерархия классов в голове осела, все становится просто и очевидно...

[Boriskin]

ИМХО, это не "такая же" ошибка. Использование ведёт к расходу памяти, неиспользование - может привести к крэшу. Теоретически - надо ставить v.dtor только там, где есть виртуальное наследование; практически - it's a good habit.

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

[muzhik]

In my opinion, one example it's more then enough to start thinking before implementation.

Думать всегда надо, независимо от наличия контрпримеров...

My point is there are no silver bullets.

Тоталли... тьфу ты, Totally agree.

Good C++ programmer understands what he/she is doing, no just blindly applying rules because they work in 95% cases.

Toje... блин,... Тоже согласен.

НО - что делать, если под определение "good C++ programmer" попадает лишь часть программеров на рынке (будем оптимистами, скажем - половина), а остальных можно назвать "average"? Так вот, ХОРОШИЙ МЕНЕДЖЕР старается строить проект так, чтобы он по минимуму зависил от крутизны конкретного программиста Васи, Мойши, Динг Денга или Раджагуптасандживхарибабуказиравипати. Ему, менеджеру, некогда возиться с крутизной программеров, ему нужен код, работающий, и быстро.

Допустим, в моей конторе люди себе позволяют делать сурьёзный рефакторинг по книжке, оптиимизации по мелочам, етц - так у нас и людьми перебирают, потому как могут себе это позволить. Не везде это так. Где-то жизнь фирмы зависит от delivery timeline - подите поспорьте с менеджером...

And on interview the answer depends on what's your REAL experience - not just "book" knowledge. This is an original topic issue. And this is how your answer will reflect your REAL experience.

Стоп! "Real experience" всегда ограничен. Лучше всего выслушать разные точки зрения, причём не все критерии - чисто техинческие, как было указано выше.

Я бы определил данную проблему так:

- Для себя надо чётко знать, что происходит в случае если объявлять и если не.

- На интервью надо расписать все pros and cons и глядя на рожу интервьюера попытаться понять, на каком аспекте сделать упор, чтобы ему понравиться.

- Моё личное ИМХО: virtual destructor стоит объявлять везде, где только можно, кроме тех случаев, где это явно излишне (ради сохранения памяти, или просто в крохотнюсеньком объекте, пусть таких объектов и не много в системе) - но задумываться над возможностью виртуального наследования в будущем надо ВСЕГДА. Кстати, этот подход выработался в рез-те "real experience" в больших проектах, где люди даже если все достаточно сильные - но от ошибок (усталости, етц) не застрахован никто.

[Mongush]

Да, верно. Но похоже, что подобные случаи экономии памяти - это ЕДИНСТВЕННЫЕ случаи, когда виртуальный деструктор себя не оправдывает. Может быть, Вы можете привести другой недостаток virtual destructors, кроме расходования памяти на поинтер на vtable?

Ага какже, посмотрите библиотеки на boost.org и посчитайте сколько там виртуальных деструкторов.
С++ - это не только ООП!!!

[roadman]

НО - что делать, если под определение "good C++ programmer" попадает лишь часть программеров на рынке (будем оптимистами, скажем - половина), а остальных можно назвать "average"? Так вот, ХОРОШИЙ МЕНЕДЖЕР старается строить проект так, чтобы он по минимуму зависил от крутизны конкретного программиста Васи, Мойши, Динг Денга или Раджагуптасандживхарибабуказиравипати. Ему, менеджеру, некогда возиться с крутизной программеров, ему нужен код, работающий, и быстро.

Программисткий коллектив, как и любой другой надо делиться на разные группы, чтобы сделать его эффективным. Группа иногда может сотоять из одного человека.
Классные программисты - это "системная группа" - которая пишет базовые библиотеки или как здесь принято называть framework. При этом базовые библиотеки - это не только низкоуровневый код, типа memory management, но и базовые классы для бизнес-процессов тоже. Активно используется инкапсуляция. Всё что не надо видеть и напрямую использовать прячется внутри классов.
Программисты послабее - это рабочие лошадки, которые реализуют бизнес логику программы, но не с нуля, уродуя код и идею, а пользуясь базовым кодом как конструктором LEGO. Им писать базовый код запрешено. При этом процесс создания идет намного быстрее, код (базовый) переиспользуется, а значит автоматически тестируется многократно - растет надежность кода. "Системная группа" пишет базовые блоки на "заказ" и при этом имеет обратную связь от пользователей своих библиотек - простых программистов, иногда не очень лицеприятных - и если критика справедлива и простой программист предлагает дельное решение, то это путь в элитную группу.
Код review, менторство, ... - можно придумать кучу разных менеджерских трюков (в хорошем смысле слова), чтобы шел процесс обучения простых программистов и элита не задирала нос.
Я понимаю, что далеко не всякая компания (менеджемент) так строит свою работу, объясняя бардак, тем, что продукт нужен на рынке "сейчас, а не через час". Это всё болезни роста. Например, такие компании как Google, Ebay, да и некоторые крупные компании в России понимают, что процесс программирования - это и инженерия и искусство в одном флаконе и умеют это огранизовывать. Мой опыт работы в научных коллективах, на производстве и на ниве программирования говорит, что дело можно организовать правильно (ну почти) с самого начала, с пользой для всех. Проблема здесь скорее в квалификации менеджемента. Но если менеджер не совсем придурок, он всегда прислушается к дельному совету, в том числе и по организация самого процесса программирования. И не надо под видом "авральных работ" списывать свою некомпетентность (nothing personal). Код написанный методом "аврала" никогда не будет надёжным и легко сопроваждаемым, и в конечном итоге - принесет больше проблем, потери денег и репутации.

[muzhik]

Да, верно. Но похоже, что подобные случаи экономии памяти - это ЕДИНСТВЕННЫЕ случаи, когда виртуальный деструктор себя не оправдывает. Может быть, Вы можете привести другой недостаток virtual destructors, кроме расходования памяти на поинтер на vtable?

Ага какже, посмотрите библиотеки на boost.org и посчитайте сколько там виртуальных деструкторов.
С++ - это не только ООП!!!

17 штук насчитал, включая примеры.

Да, убедили. Принимаю поправку.

Anyway, думать надо всегда. Опять же, чукчей-читателей у того же boost'а куда больше, чем писателей. Т.е., общие рекомендации - они для пользователей базовых библиотек; для аппликационщиков, если угодно.

А кто пишет базовую библиотеку - в любом случае, думает своей головой.

Возвращаясь к интервью - вроде все согласны, что лучший ответ - по максимуму развёрнутый. Ну, с учётом настроения интервьюера. (Допустим, кому-то не нравится, что интервьюер явно хочет услышать свой любимый ответ; ну дык на интервью стоит задача его пройти - а потом уже можно решать не идти работать к не понравившемуся остолопу...)

Программисткий коллектив, как и любой другой надо делиться на разные группы, чтобы сделать его эффективным. Группа иногда может сотоять из одного человека.
Классные программисты - это "системная группа" - которая пишет базовые библиотеки или как здесь принято называть framework. При этом базовые библиотеки - это не только низкоуровневый код, типа memory management, но и базовые классы для бизнес-процессов тоже. Активно используется инкапсуляция. Всё что не надо видеть и напрямую использовать прячется внутри классов.

Да-да, конечно. Вот только далеко не всем менеджерам нравится быть зависимыми от "группы сильных программистов", которые могут и разбежаться. "Классные программисты" не любят годами сидеть на саппорте своего framework'а, и ищут себе другое занятие - и тогда саппорт и добавка фичеров переходит к людям попроще. Кроме того, в базовом коде - также есть места, где можно обойтись v.dtor'ы, и есть места, где не стоит.

Вообще, это классный метод в споре. "У вас работа неправильно поставлена, и опыта недостаточно!"

Я повторяю, мир не идеален. И в неидеальном мире, vdtor'ы нужны. Упомянутый индус, который писал аппликацию на нашей платформе - использующий направо и налево multiple inheritance - ставил автоматом vdtor, и правильно делал.

Я понимаю, что далеко не всякая компания (менеджемент) так строит свою работу, объясняя бардак, тем, что продукт нужен на рынке "сейчас, а не через час". Это всё болезни роста.

По-моему, так работает изрядная часть фирм на рынке.

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

I like this "ну почти". А если менеджер получает полуразваленую группу, и надо спасать продукт? А если .... да мало ли что.

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

Я только могу повторить: никто не гарантирует 100% профессионализма программистов, и никто не гарантирует 100% профессионализма менеджмента.

И не надо под видом "авральных работ" списывать свою некомпетентность (nothing personal).

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

Код написанный методом "аврала" никогда не будет надёжным и легко сопроваждаемым, и в конечном итоге - принесет больше проблем, потери денег и репутации.

Обратите внимание - Вы уже спорите не с моими словами, а со своими. Я не утверждал, что код ПИШУТ ИЗНАЧАЛЬНО авральным методом. Но поддержка кода и вправду частенько так выглядит - и вот тогда будут и уставшие люди, и некомпетентных больше на поддержке. Менеджерам же (умным, хорошим, етц) приходится лавировать между пониманием, что спешка хороша только при ловле блох, с одной стороны, и требованиями высшего менеджмента и рынка - с другой стороны.

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

P.S.
О "базовой группе". Очень жизненный пример. Я сделал всё от меня возможное (всего две недели назад), чтобы НЕ попасть в такую группу - и мне это удалось. (Меня пытались перевести - раньше эта работа была раскидана на две группы - по разным участкам, и часть "базового кода" была на мне.) У них работа на 80% состоит из саппорта и мелких фичеров и копания в той же структуре данных уже 3й или 4й год. А мы начинаем новый проект. Группа наша состоит почти вся из Sr. SW Eng'rs. В "базовую" нас - никакими пряниками не загонишь.

[muzhik]

Коротко говоря, главный недостаток всех этих фичеров - и multiple inheritance, и virtual destructors - в не-дуракоустойчивости.

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

Именно, и сборку мусора тоже. Зря что ли в Java сделали сборку мусора? (в C#, если не ошибаюсь, тоже...)

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

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

Опять ссылка на идеальную модель?Опять же, если "платформа" (а.к.а. "базовый фреймворк") достаточно большая (скажем, 300К строчек) - то "базовая группа" вырастает до размеров, где "крутых" просто не хватает... И тогда, повтроряю, не важно, что Плюсы предназначены именно для этого, а аппликации пишут на Perl, Tcl/Tk, или там на специально выведеном для юзеров API...

Опять же, есть сроки, нервы, давление рынка, юзеров, етц...

А с другой стороны - Вам давно приходилось дебагить чужой код, использующий diamond multiple inheritance?

Приходилось, как же без этого. "Входит, выходит; входит и выходит! " (с) Правда написано было не индусами, так что все работало как и должно было; поначалу не совсем все понятно, но как только иерархия классов в голове осела, все становится просто и очевидно...

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

Отладить и исправить можно всё, в конце концов. Но ИМХО - лучше бы ему и таких средств в руки не давали. В качестве превентивной, так сказать, меры.

[Boriskin]

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

Опять ссылка на идеальную модель?

Нужно же к чему то стремиться! Трудно жить без идеаловб да еще в Сев.Америке

Опять же, если "платформа" (а.к.а. "базовый фреймворк") достаточно большая (скажем, 300К строчек) - то "базовая группа" вырастает до размеров, где "крутых" просто не хватает... И тогда, повтроряю, не важно, что Плюсы предназначены именно для этого, а аппликации пишут на Perl, Tcl/Tk, или там на специально выведеном для юзеров API...

Имхо, 300к строк - не так и много. Мне приходилось в одиночку в течении года поддерживать, дорабатывать и писать новые вещи для 2ух engines весом около 8 мег сорскода. Правда это было совсем не core...

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

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

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