Interesting C/C++ interview questions

[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...

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

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

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

[roadman]

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

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

[muzhik]

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

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

1) Бардак есть хотя бы временами в любой большой корпорации. А в маленькой фирме - очень зависит от конкретных людей, етц.

2) Вы опять ссылаетесь на модель идеального программистского общества. "Они vdtor-ы используют не так, как я, г...но фирма - валить надо!"

3) Опыт у всех РАЗНЫЙ.

4) Правильно ли я понял, что Вы просто предлагаете не наниматься на работу, если на интервью показалось, что интервьюер ждёт ответа, с которым Вы не согласны?

[ig]

Just for fun: <a href="http://www.apocalypse.org/pub/u/kjc/cool/Card.on.Software.html" target="_new"> How Software Companies Die</a>

[roadman]

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

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

1) Бардак есть хотя бы временами в любой большой корпорации. А в маленькой фирме - очень зависит от конкретных людей, етц.

2) Вы опять ссылаетесь на модель идеального программистского общества. "Они vdtor-ы используют не так, как я, г...но фирма - валить надо!"

3) Опыт у всех РАЗНЫЙ.

4) Правильно ли я понял, что Вы просто предлагаете не наниматься на работу, если на интервью показалось, что интервьюер ждёт ответа, с которым Вы не согласны?

1. Временами да, это жизнь, вот и надо бардак исправлять или хотя бы не добавлять нового.
2. Вы считаете, что я работал и работаю в каких-то выдуманных, идеальных компаниях?
3. На то и форум, чтобы делиться опытом.
4. Ну не так прямолинейно. Если Вы видите, что тот, кто Вас интервьирует ждет ответа, который по Вашему не верен, постарайтесь ему аргументированно изложить свою, точку зрения. Недавно, мы с приятелем, за рюмкой чая, делились впечатлениями от интервью в Google и он привёл пример, когда на его ответ, ему было сказано: Вы ответили не правильно. А он спокойно с фломастеров в руках объяснил, что это не так. И это произвело куда более положительный эффект, чем просто "сдача" позиции.

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

[A. Fig Lee]

roadman, почему Вы щитаете, что именно та модель что Вы описали есть правильная, и что все должны работать именно так?
Может, просто каждый будет иметь свой кусок проекта - в смысле сначала до конца?
IMHO, не надо вносить новых порядков в компанию, если она работает, просто адаптироватся и все.

[roadman]

roadman, почему Вы щитаете, что именно та модель что Вы описали есть правильная, и что все должны работать именно так?
Может, просто каждый будет иметь свой кусок проекта - в смысле сначала до конца?
IMHO, не надо вносить новых порядков в компанию, если она работает, просто адаптироватся и все.

Надо быть больным на голову, чтобы советовать то, что считаешь неправильным. Однако я не считаю, что моя точка зрения единственная и непогрешимая. Не вешая ярлыков "правильная-неправильная" просто излагаю свой опыт, не теоретическую точку зрения, а опыт. У кого-то он может быть другим - ну и точка зрения другая, при чем тут правильный - неправильный?
Ну если можете адаптироваться, то почему и нет. Значит для Вас это и есть правильное решение.

[muzhik]

1. Временами да, это жизнь, вот и надо бардак исправлять или хотя бы не добавлять нового.
2. Вы считаете, что я работал и работаю в каких-то выдуманных, идеальных компаниях?
3. На то и форум, чтобы делиться опытом.
4. Ну не так прямолинейно. Если Вы видите, что тот, кто Вас интервьирует ждет ответа, который по Вашему не верен, постарайтесь ему аргументированно изложить свою, точку зрения. Недавно, мы с приятелем, за рюмкой чая, делились впечатлениями от интервью в Google и он привёл пример, когда на его ответ, ему было сказано: Вы ответили не правильно. А он спокойно с фломастеров в руках объяснил, что это не так. И это произвело куда более положительный эффект, чем просто "сдача" позиции.

2. По Вашим словам - так и получается. Ну, либо "быстро уходите" из тех, где Вам не нравится.

3. Угу. А из того, что у кого-то опыт/информация со стороны не совсем совпадает с Вашей, не следует, что они - идиоты, некомпетентные, етц - верно?

4. Угу. Обычно видно, кому ты можешь доказать, а кому - нет...

Ну, вроде "пришли к консензусу"...

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

Тут такое дело... В больших фирмах организация проекта оставлена на уровень group/team lead'ов. Интервью в этом смысле мало чем может помочь.
СознАюсь - я в маленькие фирмы давно уже не заглядывал.

[roadman]

2. По Вашим словам - так и получается. Ну, либо "быстро уходите" из тех, где Вам не нравится.

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

[muzhik]

Да как вам сказать... Может в Силиконовке и было принято в лучшие времена менять работу каждые пару месяцев, но мне почему-то казалось, что к месту работы надо относиться тщательнЕе, и "прыжки" могут изрядно подпортить резюме.

Есть ещё масса других факторов. Например, размер компании ~= стабильность. Если молодой-холостой, то это не критерий; а с детьми - это да критерий. Кому-то важна не очень долгая дорога до работы, кому-то в конкретном месте предложили намного больше, чем в другом, етц, етц...

Как было бы просто, если бы мы работали "за удовольствие"...

Честное слово, Вы действительно будто в идеальном мире живёте...

[muzhik]

Опять-таки, не все такие претензиозные как Вы или такие переборчивые как я Есть люди, которые впервые ищут работу; есть люди, которым нужно срочно поменять работодателя, етц, етц...

Да, самое главное - H1B. С H1B, если по к-л причине приходится менять работу - тем более не сильно и поперебираешь. Время оформления ГК в конце концов ограничено. Почитайте, какие проблемы бывают у людей.

Вывод: в идеальном мире - мы будем выбирать, где ставить vdtor, рассматривая каждый случай особо. В мире реальном - примем рекомендацию Строструпа. Для массивных ОО проектов это означает: vdtor - default. И для интервью в такие проекты - тоже.

Хотя, повторяю, самое правильно, ИМХО - расписать интервьюеру полную картину.

[muzhik]

Блин, кажется я попался...

Мне тут объясняли, что в программировании с темплейтами vdtor не нужен, а я имел глупость согласиться.

Так вот - я снова не согласен. Все аргументы, применимые для обычного ООП, годятся и для generic. Наследование и темплейты - это совершенно ортогональные вещи с точки зрения реализации (даже если полиморфизм и genericity позволяют решать сходные задачи); и от контейнера-темплейта можно унаследовать сына... потом скастить поинтер на класс-папу, и попробовать уничтожить...

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

ИМХО - лучше пусть там будет vdtor - разве только если критически нужно сэкономить эти самые 4 байта на обьект...

Хотя, может народ приведёт ещё примеры, к-ые мы до сих пор не обсудили....

[roadman]

Опять-таки, не все такие претензиозные как Вы или такие переборчивые как я Есть люди, которые впервые ищут работу; есть люди, которым нужно срочно поменять работодателя, етц, етц...

Да, самое главное - H1B. С H1B, если по к-л причине приходится менять работу - тем более не сильно и поперебираешь. Время оформления ГК в конце концов ограничено. Почитайте, какие проблемы бывают у людей.

Зачем читать, если я сам через это (H1-B) прошёл и до GC ещё не дошёл.
Вы знаете, когда человек "прогибается" он всегда найдет 100 причин объяснить, почему он так поступил - это нормальная реакция человеческой психики. Ни в коем случае не осуждаю таких людей. Но не надо выдавать это как рекомендации поступать всем другим и тем более упрекать тех, кто находит в себе силы "не гнуться" - это я опять безотносительно личностей.
У меня была возможность уйти из бодишопа через 6 месяцев на постоянную работу, но я этого не сделал, потому что понимал - попаду в сильную зависимость от компании где мне не очень нравилось работать. А когда Вы на контракте (который найти по стравнению с постоянной работой в 10 раз труднее) то в некотором смысле Вы более свободный человек.
Честно говоря мы уже отошли от первоначальной темы и это скорее топик в раздел "Жизнь".

[tchicago]

Достоинства и недостатки двух методов обработки exception

Code: Select all

class exep
{
public:
   exep(int err) : _error(err) {}
   int get_code() const { return _error; }
private:
   int _error;
};

int main()
{
   try
   {
      throw new exep(1);
   }
   catch (exep* x)
   {
      cout << x->get_code();
      delete x;
   }

   try
   {
      exep x(1);
      throw x;
   }
   catch (exep& x)
   {
      cout << x.get_code();
   }

А почему этот вопрос никто не удостоил вниманием? Все слишком просто или слишком сложно?

[шпиён]

Вопросы С++ вызывают дискуссии на 7 страниц, чего это вы, язык то мертвый... гы

Это Ц-острый - мертворождённый. Чтобы он стал по-настоящему массовым, надо чтобы весь мир перешёл на .Net, или чтобы появились альтернативные платформы Ц-острого, или ..., или .......

Все "или" упираются в одно: Мелкомягк не захочет выпускать Ц-острый из-под своего контроля, не даст его стандартизировать каким-то "комиссиям",
...

В общем, типичная ситуация: люди в MS толковые, постарались, а политика фирмы - ...

Всё это IMHO, конечно.

Ваше HO противоречит фактам. В отличие от сана, МС-таки что нужно стандартизовал:
http://msdn.microsoft.com/net/ecma/

ECMA and ISO/IEC C# and Common Language Infrastructure Standards
In August, 2000, Microsoft, Hewlett-Packard and Intel co-sponsored the submission of specifications for the Common Language Infrastructure (CLI) and C# programming language to the international standardization organization ECMA. As a result, ECMA formed two task groups (TG3 and TG2, respectively) within TC39, its technical committee responsible for programming languages and application development.

During the next year, the co-sponsor companies, in conjunction with other ECMA members and guests (including IBM, Fujitsu Software, Plum Hall, Monash University and ISE), refined these specifications into standards. In December, 2001, the ECMA General Assembly ratified the 1st edition of the C# and CLI standards as ECMA-334 and ECMA-335, respectively.
...
In April, 2003, ISO ratified the standards as ISO/IEC 23270 (C#), ISO/IEC 23271 (CLI) and ISO/IEC 23272 (CLI TR).

[шпиён]

Достоинства и недостатки двух методов обработки exception

Code: Select all

class exep
{
public:
   exep(int err) : _error(err) {}
   int get_code() const { return _error; }
private:
   int _error;
};

int main()
{
   try
   {
      throw new exep(1);
   }
   catch (exep* x)
   {
      cout << x->get_code();
      delete x;
   }

   try
   {
      exep x(1);
      throw x;
   }
   catch (exep& x)
   {
      cout << x.get_code();
   }

А почему этот вопрос никто не удостоил вниманием? Все слишком просто или слишком сложно?

С первого взгляда кажется просто.
1) Лишняя аллокация/деаллокация памяти. Да еще и лик может быть, если из catch своё исключение бросится до delete.
2) Лишнее копи-конструирование, что для приведенного в примере exep не хуже копирования указателя в случае 1, но для больших/сложных классов может быть дорого.
На мой взгляд, метод 2 однозначно лучше, т.к. за расчет на высокую скорость обработки исключений надо anyway бить лопатой по голове.