Interesting C/C++ interview questions

[A. Fig Lee]

У меня есть подозрения, что я С++ по крайней мере не хуже вас знаю, так что не будем меряться сами знаете чем :ноно#:

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

[A. Fig Lee]

Гы... Я вам привели пример двух пакетов для Виндовс позволяющих удобно работать с Юних сокетами - ЦыгВин и У/Вин. Оба обеспечивают имплементацию Юних Сокетов на основе ВинСоцк.

А я что - про пакеты спрашивал? Я говорил в Виндоус - нет УНИХ сокетов. И их таки нет. Если они гдето имплементированы в какойто библиотеке - ето проблема етой библиотеки, а операционная система - таких возможностей не предоставляет. Возможно, Вы просто не можете провести грань, где операционная система, а где библиотеки. Кстати, по делу Вы так и не ответили - как использовать Ваш УНИХ сокет с майскюл.
И где Вы нашли у Стивенса, которого Вы мне рекомендовали про УНИХ сокеты под Виндоус, особенно с cygwin?

[uncle_Pasha]

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

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

А тут я ничего не понял. Какая вообще разница, class или struct?

Формально, разница только в видимости членов.
Но меня вполне устраивает, то что:
1. половина индусов не будет наследоваться от struct, потому что не знает, что это можно делать.
2. половина от оставшейся половины будет неуверена, хорошо ли это, и во время ближайшего код ревью будет убита тезисами первой половины, что это "страшная недокументированная фича, которая грозит неминуемой карой в виде чего-нибудь". И, в итоге, не станут этого делать.
3. Те же индусы, что останутся, переименуют структуру в класс и приделают виртуальный деструктор по привычке.

И никаких проблем

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

А почему я на C++ не могу писать с тем же результатом?

Вы не уловили разницу между можно/нельзя и стОит/не стОит?

Удачи!

[Mongush]

C++ как тут уже сказали - очень гибкий язык, и не надо ограничевотся только ОО подходом, который иногда может быть не эффективным, С++ и сделан чтобы можно было писать _эффективные_ программы и там для этого достаточно средств. А если их не использовать, то и смысла исплозовать С++ нет, лучше уж Java. А насчет виртуального деструктора, тут уже посоветовали посмотреть дизайн generic библиотек, в них то по моему и видна вся мощь языка, а уж не как не в MFC

[uncle_Pasha]

Столько вокруг отличных библиотек красиво сдизайненных.
STL, ATL, boost, ACE. Где там "все деструкторы должны быть виртуальны?"

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

Удачи!
PS Да, роговые RW[A-Za-z\ ]+\+\+ не самые быстрые.
Но они же поставляют очень приличную реализацию STL под многие компиляторы.

[uncle_Pasha]

C++ как тут уже сказали - очень гибкий язык, и не надо ограничевотся только ОО подходом, который иногда может быть не эффективным, С++ и сделан чтобы можно было писать _эффективные_ программы и там для этого достаточно средств. А если их не использовать, то и смысла исплозовать С++ нет, лучше уж Java. А насчет виртуального деструктора, тут уже посоветовали посмотреть дизайн generic библиотек, в них то по моему и видна вся мощь языка, а уж не как не в MFC

ACE - это не "generic" библиотека.

Никто не говорил что стоит делать виртуальный деструктор всегда.
Вопрос в том, что если кто-то не понимает зачем - пусть сделает виртуальным. Это безопаснее.
Растраты памяти в этом случае ничто по сравнению с утечками после "доработки".
Не хвататет производительности => отдельный проект => один или несколько нормальных мужиков (те, которые понимают) сядут и выбросят все ненужное.

Удачи!

[TLK]

ACE - это все-таки любительщина.

Удачи!
PS Да, роговые RW[A-Za-z\ ]+\+\+ не самые быстрые.
Но они же поставляют очень приличную реализацию STL под многие компиляторы.

I am not a big fan of RW STL...

As for the ACE yes it's free, opensource, yada, yada, yada
.... but it does not make it automatically unprofessional.
People writing it work for money and they are actually good at what they do.

List of customers:
http://www.cs.wustl.edu/~schmidt/ACE-sponsors.html

And I can assure you it is not complete.

[Volodja]

Narod,

Vot kod, kotorii dlja interview moget i ne samii lutshii, no sam po sebe interesen.

int i = 1;
int a[3] = {1,1,1};

i[a] = 2;

printf("%d %d %d",a[0],a[1],a[2]);

Вопроси: проидет ли компилязиу? Если да, напечатается ли что либо? Если напезатается, то что?
Ответ конечно легко получит с помощу compiler... попробуите без.

Кстати, общее замечание, почему то на "русских" профессионалних форумах
отсутствует увагение к себе подобним ...
Могно щитат "профессионализм" других не достаточним ... могно всех индусов
в куче щитат "лубителями" ... могно многое ... НО без увагения относится к лудям с которими общаешся (даге на форуме) - ето очен не красиво.
Vo.

[Seryi]

Narod,

Vot kod, kotorii dlja interview moget i ne samii lutshii, no sam po sebe interesen.

int i = 1;
int a[3] = {1,1,1};

i[a] = 2;

printf("%d %d %d",a[0],a[1],a[2]);

Вопроси: проидет ли компилязиу? Если да, напечатается ли что либо? Если напезатается, то что?
Ответ конечно легко получит с помощу compiler... попробуите без.

Кстати, общее замечание, почему то на "русских" профессионалних форумах
отсутствует увагение к себе подобним ...
Могно щитат "профессионализм" других не достаточним ... могно всех индусов
в куче щитат "лубителями" ... могно многое ... НО без увагения относится к лудям с которими общаешся (даге на форуме) - ето очен не красиво.
Vo.

Ох, уже 2 года как не трогал C, но попробую.
ИМХО код компиляцию не пройдет.
Но представим что пройдет, тогда:
i[a], если представим i как указатель, то результирующая ячейка памяти это:

Code: Select all

resultMem = i + a = 1 + a

. То есть это будет та же ячейка что a[1]
в итоге массив a будет иметь данные {1,2,1}
это и будет напечатано
1 2 1

[TLK]

Я люблю Ц++. Это мощный и красивый язык.
И на нем можно писать очень эффективные программы ничуть не хуже чем на Ц.

Нельзя. Точка.

Так, Вы или недопонимаете или лапшу на уши вешаете, СТЛ, АТЛ - темплейты - какие там виртуальные деструцторы?? Как Вы от пустого темплейта наследовать собрались? Лучше МФС посмотрите. боост, АCЕ - не знаю.

Dear Fig Lee, if we take a "small hiking trip" inside ATL together we will see that contemporary ATL is not ONLY "templates". It includes number of classes with virtual destructors and without them.
It even has (O Lord!) templates with virtual destructors.

As for MFC...a dead horse everybody beating for years.
It's 21 century, good time to retire this antient library.

[uncle_Pasha]

Кстати, общее замечание, почему то на "русских" профессионалних форумах отсутствует увагение к себе подобним ...
могно всех индусов в куче щитат "лубителями"

Volodja,

Я никогда не считал ВСЕХ индусов любителями. Если Вы прочитаете мой пост внимательно, то, по крайней мере 25% поступят вполне профессионально.
К тому же "индус" - это имя нарицательное. Так же как и "русский программист" (это тот, который глядя в код рвет на сабе волосы и старается переписать все с нуля).
Что касается Вашей задачи - от перемены мест слагаемых, как говорится...

Удачи!
PS не дай Вам бог индуса в начальники!

[uncle_Pasha]

I am not a big fan of RW STL...
As for the ACE yes it's free, opensource, yada, yada, yada
.... but it does not make it automatically unprofessional.
People writing it work for money and they are actually good at what they do.

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

Не надо мне приписывать то, что я не говорил. Найдете хоть один мой пост, где я утверждал, что ВСЕ деструкторы должны быть виртуальными?

List of customers:
http://www.cs.wustl.edu/~schmidt/ACE-sponsors.html

And I can assure you it is not complete.

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

Удачи!

[A. Fig Lee]

Dear Fig Lee, if we take a "small hiking trip" inside ATL together we will see that contemporary ATL is not ONLY "templates". It includes number of classes with virtual destructors and without them.
It even has (O Lord!) templates with virtual destructors.

Ok. What classes in ATL have NO virtual desrtuctor NOT on purpose?
Your point is - usual practice in C++ do not have virtual destructors unless we really need them, right?

As for MFC...a dead horse everybody beating for years.
It's 21 century, good time to retire this antient library.

Ok, it is Fundemental classes, so the purpose for them is to derive something. Ok, let thing it is not common practice.

You wonna ACE? I found at least 896 classes with virtual destructors. Do not know how many classes it has because cannot rely on word "class" - it uses templates. So, does it proove virtual destructors should not be used without special purpose?

[Volodja]

Seryi,
"ИМХО код компиляцию не пройдет." - na samom dele proidet.
(Let pjat nazad, kogda mne eto kto to na interview podsunul, ja oprobival i na gcc
i na Microsofte). Ostalnoe vse pravilno.
i[a] adekvatno *(i + a) ...*(a + i) to est kak absolutno prav uncle_Pasha "Что касается Вашей задачи - от перемены мест слагаемых, как говорится... "

uncle_Pasha, плохои началник ... очен сочуствуу. У меня тоге, уви, бивали.
Интересная тема, что хуге: технически подтянутии , но сволоч как человек или
технически некомпетентнии но "добреишеи души человек".

В общем, извините за баналност, но назионалност (проишогдение) началника - вещ обсолутно случаиная. Я знавал одного толкового "русского" мугика котории виидя в доволно болшое началство (руководил болшим проектом) вел себя
настолко как сволоч ... особенно с осталними ьрусскимиь...

Я на самом деле не об етом. Почитаите лубои профессионалнии форум на англииском. Луди ВЕГЛИВИ друг с другом. Спорит могно "зивилизованно"!

Ну что стоит например превести маленкии пример с "виртуал деструцтор" и виразит свое мнение почему он нуген , нуген ли всегда, какои подход щитаете правилним...

Почитал я тут ... Еще чут чут и появатся постинги типа "Ти не прав, потому что ти дурак а я умнии". А вед тут луди похоге с висшим образованием, профессионали. Луди которих когда то називали "техническая интелегензия".
Грустно как то ... страна где ми виросли, видимо нам етого не дала.
Видимо, то что с етои странои проишодит - закономерно ...
А очен гал!.
Vo.

[TLK]

Ok. What classes in ATL have NO virtual desrtuctor NOT on purpose?
Your point is - usual practice in C++ do not have virtual destructors unless we really need them, right?

Ok. I see I need to clarify something.
I have absolutely no point about "usual destructor practice in C++".
My point is I try to avoid common generalizations.
Class can be specifically designed to be derived and still leave long healthy life without virtual destructor. And often live well without any destructor at all.
The first example is "pure" interface definition. Another example are classes which will live on stack and never will be on heap. (That also happens even if it looks weird.)

Practically the only justification for having the damn thing is when we want to delete those inherited objects as pointers on the base class. In this case yes we NEED VD. Amen!

And even in this case somebody can find convinient to use some other technique to ensure proper deletion (like dynamic cast or even static cast).

So my pont is: it all depends.
Peace?

[TLK]

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

Support is here:

http://www.riverace.com/

and here:

http://www.theaceorb.com/

And actually works quite well. Of course it is not free.

[A. Fig Lee]

Серыи,
"ИМХО код компиляцию не пройдет." - на самом деле проидет.
(Лет пят назад, когда мне ето кто то на интервиев подсунул, я опробивал и на гцц
и на Мицрософте). Осталное все правилно.
и[a] адекватно *(и + а) ...*(а + и) то ест как абсолутно прав унцле_Паша "Что касается Вашей задачи - от перемены мест слагаемых, как говорится... "

унцле_Паша, плохои началник ... очен сочуствуу. У меня тоге, уви, бивали.
Интересная тема, что хуге: технически подтянутии , но сволоч как человек или
технически некомпетентнии но "добреишеи души человек".

В общем, извините за баналност, но назионалност (проишогдение) началника - вещ обсолутно случаиная. Я знавал одного толкового "русского" мугика котории виидя в доволно болшое началство (руководил болшим проектом) вел себя
настолко как сволоч ... особенно с осталними ьрусскимиь...

Я на самом деле не об етом. Почитаите лубои профессионалнии форум на англииском. Луди ВЕГЛИВИ друг с другом. Спорит могно "зивилизованно"!

Ну что стоит например превести маленкии пример с "виртуал деструцтор" и виразит свое мнение почему он нуген , нуген ли всегда, какои подход щитаете правилним...

Почитал я тут ... Еще чут чут и появатся постинги типа "Ти не прав, потому что ти дурак а я умнии". А вед тут луди похоге с висшим образованием, профессионали. Луди которих когда то називали "техническая интелегензия".
Грустно как то ... страна где ми виросли, видимо нам етого не дала.
Видимо, то что с етои странои проишодит - закономерно ...
А очен гал!.
Во.

Дык - сопротивляются! Приходится брать палку и загонять в светлое будущее. Силой насждать добро так сказать...

[A. Fig Lee]

Peace?

Sure. I cannot resist more than 3 times.

[uncle_Pasha]

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

Support is here:
http://www.riverace.com/
and here:
http://www.theaceorb.com/
And actually works quite well. Of course it is not free.

Товарисчь не понял.
Наличие платной поддержки ни о чем не говорит само по себе, если осуществляется сторонней конторой, по отдельному контракту.
Эта контора не заинтересована в "вылизывании" кода. Даже наоборот: больше багов - больше денег.
Это парадокс - чем более криво написана библиотека, тем выгоднее ее поддерживать. Открываешь кейс ($300), через 5 минут отвечаешь кастомеру - сам дурак. Нехрен от этого класса наследоваться! Надо аггрегировать! Следующий!

Удачи!
PS я не против ОпенСорц проектов. Просто не фанакт АЦЕ.
Соответственно не люблю, когда ее ставят в пример.

[шпиён]

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

Плохо ж Вы думаете о современных компиляторах...

[шпиён]

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

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

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

Если б эти фиксы еще исправили все баги...

[шпиён]

99% что никому не прийдет в голову наследоваться от struct в дальнейшем

[шпиён]

Неужели нельзя "запечатать" класс собственными средствами С++? Не верю.

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

Блин, народ, ну что вы всё ставите с ног на голову. Наследование от структур/классов без виртуальных дестракторов не страшно, страшен вызов delete на указатель на такой класс. Ну и?

[шпиён]

Class can be specifically designed to be derived and still leave long healthy life without virtual destructor. And often live well without any destructor at all.
The first example is "pure" interface definition.

This particular example is when the destructor MUST be virtual. (No, I am not a proponen of writing virtual anything by default).

[interrupt]

Class can be specifically designed to be derived and still leave long healthy life without virtual destructor. And often live well without any destructor at all.
The first example is "pure" interface definition.

This particular example is when the destructor MUST be virtual. (No, I am not a proponen of writing virtual anything by default).

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

Code: Select all

class IMyInterface
{
public:
   virtual ~IMyInterface() = 0
   {
   }

   virtual void MyMethod_1() = 0;
   virtual void MyMethod_2() = 0;
   // ..
};

почти на автомате пишется...
[/b]