Interesting C/C++ interview questions

[uncle_Pasha]

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

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

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

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

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

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

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

Удачи!

[tchicago]

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

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

[interrupt]

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

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

[yocto]

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

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

[uncle_Pasha]

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

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

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

Удачи!

[uncle_Pasha]

Аргументы "пусть возьмет компьютер помощнее" - не принимаются

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

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

С++ проект (или часть проекта) будет более дорогой, по определению. Но будет более расширяемый (не упрется а лимит памяти сервера ), более производительный. Но если и ++ не удовлетворяет - тогда С/assembler/автокод/etc.

Удачи!

[8K]

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

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

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

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

[ballymahon]

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

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

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

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

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

[A. Fig Lee]

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

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

Ну, главное, хоть не отправляете читать начальные книжки как по сокетам - читать Стивенса как запустить УНИХ сокет на Виндоус.


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

[interrupt]

Делать класс тогда, когда ето имеет смысл.

И обьявлять деструктор виртульным тоже нужно, если в этом есть смысл... А не "лишь бы было"...

[A. Fig Lee]

Делать класс тогда, когда ето имеет смысл.

И обьявлять деструктор виртульным тоже нужно, если в этом есть смысл... А не "лишь бы было"...

Что - опьять как "УНИХ сокеты под Виндоус есть"?

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

[TLK]

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

И зачем ограничивать себя "все деструкторы должны быть виртуальными." или как многие любят "наследовать все классы в проекте от нашего CObject" или "нельзя использовать темплейты (наэймспейсы, etc)"...
Зачем ?!
Ну нужен деструктор виртуальный - сделайте! Или proxy class в иерархию вставьте с этим самым деструктором. Или темплейты.
Проблема то простая. На C++ ее решить быстрее чем я письмо писал. (с учетом последующего самоцензурирования)

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

[interrupt]

Делать класс тогда, когда ето имеет смысл.

И обьявлять деструктор виртульным тоже нужно, если в этом есть смысл... А не "лишь бы было"...

Что - опьять как "УНИХ сокеты под Виндоус есть"?

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

Да вы утомили немного со своими уних сокетами, теперь будете их вставлять на любой вопрос. Вы попросили любой пример под Windows, где бы использовались Юникс сокеты (при этом компилятор и библиотеки не оговаривались), я написал вам пример на C++ (CygWin, который я очень часто использую) под Windows с юникс сокетами (надстроенные над WinSock, как вы сами можете убедиться если загляните в исходники). Т.е. в споре вы пролетели как фанера, потому что получили ПРИМЕР, который скомпилируется в .EXE и будет работать под Windows.. К тому же есть еще полно других проектов, где есть полная реализация Unix сокетов для Windows (например U/WIN). Вместо того, чтобы признать что вы проиграли спор (потому что я вам код написал) или стыдливо промолчать, вы еще и начинаете выделываться...

[interrupt]

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

О! Вот это в точку. И библиотеки эти и быстрые и по памяти нетребовательные. А библиотеки которые Fig Lee будет писать, этими характеристиками обладать не будут

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

[A. Fig Lee]

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

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

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

Ето где Вы такое нашли? Я говорил? Прям таки - все? Или я говорил об общем случае?

Столько вокруг отличных библиотек красиво сдизайненных.
СТЛ, АТЛ, боост, АЦЕ. Где там "все деструкторы должны быть виртуальны?"

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

[A. Fig Lee]

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

О, батенька, да Вы похоже, не знаете почему именно дестракторы ДОЛЗНЫ быть виртуальными, а не функции, в чем смысл етого.
Советую - АРМ (Аннотатед Референце Мануал, по-моему) - Страуструп. Почитайте про уничтожение обьектов

[A. Fig Lee]

Да вы утомили немного со своими уних сокетами, теперь будете их вставлять на любой вопрос.

Да, ето навсегда Вы попались.

Т.е. в споре вы пролетели как фанера,
....
Вместо того, чтобы признать что вы проиграли спор (потому что я вам код написал) или стыдливо промолчать, вы еще и начинаете выделываться...

Да, ето Ваш главный пойнт - не проиграть выкрутится любой ценой.

Незвисимо от истины.
А УНИХ соцкетов таки в Виндоус нет. Думаю, теперь будете знать.

[алёша]

да-а???
а про COM никогда не слыхали?

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

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

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

Удачи!

[interrupt]

Незвисимо от истины.
А УНИХ соцкетов таки в Виндоус нет. Думаю, теперь будете знать.

Гы... Я вам привели пример двух пакетов для Windows позволяющих удобно работать с Юних сокетами - CygWin и U/Win. Оба обеспечивают имплементацию Юних Сокетов на основе WinSock. Даже программу я вам написал, которую я могу в EXE под Win откомпилировать. И как, будем все также, как заклинание повторять "Юникс сокетов в Виндоус нет" ?. Тогда повторяйте каждый вечер перед сном "нету, нету, нету", авось действительно они исчезнут, так вам хоть не так стыдно будет, что лопухнулись

[interrupt]

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

О, батенька, да Вы похоже, не знаете почему именно дестракторы ДОЛЗНЫ быть виртуальными, а не функции, в чем смысл етого.
Советую - АРМ (Аннотатед Референце Мануал, по-моему) - Страуструп. Почитайте про уничтожение обьектов

Спасибо, не надо, читали не раз, так же как и ANSI/ISO стандарты по С++... То что вы поняли мои слова, как вам того захотелось - это ваши проблемы. У меня есть подозрения, что я С++ по крайней мере не хуже вас знаю, так что не будем меряться сами знаете чем Просто я еще при этом программы оптимизирую всегда и виртуальными деструкторами "лишь бы было" не разбрасываюсь. Ну а у вас с этим похуже, но это не страшно, RAM нынче дешевый, заказчики непривередливые, если что - обьясните им, что еще памяти доставить нужно и процессор сменить, и все нормально заработает...

[interrupt]

да-а???
а про COM никогда не слыхали?

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

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

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

Удачи!

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

[Vovka]

Ух ты, какой чудный флейм получается!

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

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

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

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

это я совсем не понял...

Имелось в виду, что если класс не предполагается служить базой, то нет никакого смысла делать в нём вирт. ф-ции и protected члены. А следовательно, если вдруг нужно будет его код повторно использовать, то это можно будет сделать с помощью композиции, а не наследования.

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

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

[awq900]

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

Здесь по C++ тесты - http://v.psiola.ru/cpp/index.htm

Посмотрел вопросы для чайников и понял, что я даже в чайники не гожусь. Хотя я пограмаю на C ++ более 5 лет и, главное, это меня кормит, приносит "башки" моей компании и удовлетворение клиентам.

Вот например, первый вопрос из http://v.psiola.ru/cpp/index.htm для чайников.


Cколько символов "A" выведет на экран следующая программа:

#include <iostream>
using namespace std;
struct A
{A(){cout << "A";}; ~A(){cout << "A";};};
struct B : public A
{B(){cout << "B";}; ~B(){cout << "B";};};
struct C : public B
{C(){cout << "C";}; ~C(){cout << "C";};};
int main() {C c;return 0;}

Варианты ответа:
Программа не откомпилируется
0
1
2
3
4
Результат работы программы не предсказуем (недопустимая работа с памятью)


Я не знаю ответ, а главное и знать не хочу Мне кажется, что писать надо как можно проще: использовать конструкторы только для инициализации переменных, т.к. трудно возврашать код ошибок; мимизировать количество наследований, etc.

На brainbench подобные вопросы доминируют.

Я не доумеваю, для чего нужны такие тесты?! Зачем их используют при приеме на работу?

Может кто-нибудь занает ответы ...

Паша




[/i]

[interrupt]

Я не знаю ответ, а главное и знать не хочу Мне кажется, что писать надо как можно проще: использовать конструкторы только для инициализации переменных, т.к. трудно возврашать код ошибок; мимизировать количество наследований, etc.

На brainbench подобные вопросы доминируют.

Я не доумеваю, для чего нужны такие тесты?! Зачем их используют при приеме на работу?

Может кто-нибудь занает ответы ...

Паша

О нет... На этот вопрос точно нужно знать ответ. Иначе, вы не знаете C++, хотя возможно, что это не мешает вам на нем программировать и зарабатывать . Тут проверяются самые базовые знания механизма вызова деструкторов в C++. "Базовей" не придумаешь...

[jawabean]

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

согласно стандатра никакой разницы нет. но если напорешься на неграмотного интервьюера, то он тебе устроит кузькину мать за такой ответ. в Си# есть большая разница