Вопросы на собеседовании на вакансию C#

[Alexandr]

А нафига, если они уже описаны в стандарте как элементы языка?

ну типа как пример задачи
причем, которая реализована тупо через define )) (т.е. definом смотрим подо что компилим и подставляем нужную реализацию)

[Alexandr]

мы сейчас ищем людей на C++ и резюме на 5 страниц (коих подавляющее большинство), где описан опыт по C++, PHP, Java, JavaScript, Perl, Excel мacros , SQL... сразу идут в топку.

у меня как раз такое резюме
страницы на 3

А как-же правило - 2стр. максимум?

ну мож сокращу как-нть

[Мальчик-Одуванчик]

ну и на кой там pimpl упало? Они потоки под Linux и Windows в runtime переключать решили?

Тут как раз идея связана со второй фишкой пимпла: скрыть имплементацию. Для винды вам нужно хранить в классе, какой нибудь WINDOWS_THREAD_T handle, а для никсов int handle, и пимпл дает возможность это дело в имплементации скрыть, а декларация чистенькая и для обоих имплементаций одинаковая.
Дефайны, кстати, аццкое зло. И должны применяться в плюсах, только если иначе никак. (например, если вы решите countof через sizeof заимплементить).

А зачем в этом случае вообще париться с pimpl?
На мой взгляд, гораздо эффективнее будет специализация шаблонных классов (или отдельных методов) под это дело.

[assazello]

ну и на кой там pimpl упало? Они потоки под Linux и Windows в runtime переключать решили?

Тут как раз идея связана со второй фишкой пимпла: скрыть имплементацию. Для винды вам нужно хранить в классе, какой нибудь WINDOWS_THREAD_T handle, а для никсов int handle, и пимпл дает возможность это дело в имплементации скрыть, а декларация чистенькая и для обоих имплементаций одинаковая.
Дефайны, кстати, аццкое зло. И должны применяться в плюсах, только если иначе никак. (например, если вы решите countof через sizeof заимплементить).

А зачем в этом случае вообще париться с pimpl?
На мой взгляд, гораздо эффективнее будет специализация шаблонных классов (или отдельных методов) под это дело.

Специализировать шаблон типом OS?

[Prosche]

Как вы собрались без дефайнов писать мультиплатформенный код - хз

легко. вот буквально на днях отгрузили первому кастомеру либу, она кроссплатформенная, под все нынешние актуальные платформы, никаких дефайнов, весь платформ специфик код вынесен в отдельные классы, под каждую платформу свой, имплементации которых cmake (он у нас собирает билды на всех платформах) берет в зависимости от таргета (типа linux/thread.cpp, windows/thread.cpp etc).

А нафига, если они уже описаны в стандарте как элементы языка?

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

[Мальчик-Одуванчик]

Только сейчас понял, что потоки - это threads, а не streams.
А как по русски будут streams?

Что-то и я завис.
С одной стороны threads - это нити. Есть же устойчивый жаргон типа "создать нитку"
C другой - потоки, в контексте "многопоточных приложений"
streams - потоки ввода-вывода. Как-то так

[Prosche]

они в любом случае будут в private

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

[Мальчик-Одуванчик]

ну и на кой там pimpl упало? Они потоки под Linux и Windows в runtime переключать решили?

Тут как раз идея связана со второй фишкой пимпла: скрыть имплементацию. Для винды вам нужно хранить в классе, какой нибудь WINDOWS_THREAD_T handle, а для никсов int handle, и пимпл дает возможность это дело в имплементации скрыть, а декларация чистенькая и для обоих имплементаций одинаковая.
Дефайны, кстати, аццкое зло. И должны применяться в плюсах, только если иначе никак. (например, если вы решите countof через sizeof заимплементить).

А зачем в этом случае вообще париться с pimpl?
На мой взгляд, гораздо эффективнее будет специализация шаблонных классов (или отдельных методов) под это дело.

Специализировать шаблон типом OS?

Как вариант. Интерфейс же при этом остается неизменным.
Хотя вполне возможно специализировать типом операционки отдельные члены или функции класса.
Я постоянно типом конкретной модели микропроцессора, к примеру, специализирую. Или типом конкретной периферии.

[FromRussiaWithLove]

Только сейчас понял, что потоки - это threads, а не streams.
А как по русски будут streams?

Что-то и я завис.
С одной стороны threads - это нити. Есть же устойчивый жаргон типа "создать нитку"
C другой - потоки, в контексте "многопоточных приложений"
streams - потоки ввода-вывода. Как-то так

Streams были потоками ввода-вывода 30-40 лет, если только переопределили последние годы. Threads ето те же processes только легкие введены для быстрого переключения без затрат на полную смену контекста

[helg]

В былые времена мы говорили "поток данных" и "исполняемый поток". Но потом стали использовать "нить" и "поток" - так быстрее.

[FromRussiaWithLove]

В былые времена мы говорили "поток данных" и "исполняемый поток". Но потом стали использовать "нить" и "поток" - так быстрее.

What's the English term for "исполняемый поток"?

[Medium-rare]

Current thread.

[Мальчик-Одуванчик]

Как вы собрались без дефайнов писать мультиплатформенный код - хз

легко. вот буквально на днях отгрузили первому кастомеру либу, она кроссплатформенная, под все нынешние актуальные платформы, никаких дефайнов, весь платформ специфик код вынесен в отдельные классы, под каждую платформу свой, имплементации которых cmake (он у нас собирает билды на всех платформах) берет в зависимости от таргета (типа linux/thread.cpp, windows/thread.cpp etc).

А нафига, если они уже описаны в стандарте как элементы языка?

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

недостаток pimpl проявляется когда нужно в обычную функцию передать исходный тип (тот, который уж спрятан во внутренностях pimpl).

[valeriypi]

del

[valeriypi]

del

[valeriypi]

del

[Alexandr]

они в любом случае будут в private

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

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

[Prosche]

они в любом случае будут в private

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

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

Ну если вас устраивает такое:

Code: Select all

#ifdef WINDOWS
class X
{
	common API
private:
	win_t_1 w1;
	win_t_1 w2;
	win_t_1 w3;
	win_t_1 w4;
	win_t_1 w5;
	win_t_1 w6;
	win_t_1 w7;
	win_t_1 w8;	
}
#elif LINUX
class X
{
	common API
private:
	nix_t_1 l1;
	nix_t_1 l2;
	nix_t_1 l3;
}
#endif
}

вместо

Code: Select all

class X
{
	common API
private:
	class Impl;
	Impl* impl_;
}

То врядли мы друг друга поймем. Своим подопечным я за такое руки отрываю

[Alexandr]

не так, будет 2 h файла, и файл, который по definу включает нужный.

а своим pimplом вы:
1) Выделяете динамическую память, где это не нужно
2) Упороли производительность, так как:
2а) У вас методы теперь вызываются не по указателю (this->method), а по указателю на указатель (this->pimpl->method)
2б) Любые возможности оптимизации компилятора вы задвинули, так как работаете через указатель, где это не нужно
3) банально усложнили код, где в этом нет никакой необходимости

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

[Muddy Brunch]

Code: Select all

#ifdef WINDOWS
class X
{
	common API
private:
	win_t_1 w1;
	win_t_1 w2;
	win_t_1 w3;
	win_t_1 w4;
	win_t_1 w5;
	win_t_1 w6;
	win_t_1 w7;
	win_t_1 w8;	
}
#elif LINUX
class X
{
	common API
private:
	nix_t_1 l1;
	nix_t_1 l2;
	nix_t_1 l3;
}
#endif
}

вместо

Code: Select all

class X
{
	common API
private:
	class Impl;
	Impl* impl_;
}

То врядли мы друг друга поймем. Своим подопечным я за такое руки отрываю

Первый подход тоже имеет право на жизнь в случае если, конкрентные реализации не экспозиаться наружу, a например factory method возвращает shared_prt на interface за которым ужe стоят конкретные реализации (win or lin), которые клиенту не видны (т.е. прямая альтернатива pimpl).

Выставлять наружу platform specific details, даже спрятав их в приват секции, - уродство, со всеми вытекающими.

[Prosche]

Приобрел я как раз весьма много, я не вытаскиваю наружу ненужное, вы же своими дефайнами "дарите" тому, кто будет использовать ваш API еще и хедеры, где описаны win_t_1 и пр., которые совершенно неизвестно, что там внутри декларируют и дефайнят. Есть богатый опыт разруливания подобных конфликтов, когда хедеры работающие отлично поодиночке начинают сносить крышу компилеру вместе и начинается, а давай поменяем их местами, а давай попробуем #undef max или string. А по поводы производительности, не стоит заниматься преждевременной оптимизацией, к добру это не приводит обычно.

[Alexandr]

Приобрел я как раз весьма много, я не вытаскиваю наружу ненужное, вы же своими дефайнами "дарите" тому, кто будет использовать ваш API еще и хедеры, где описаны win_t_1 и пр., которые совершенно неизвестно, что там внутри декларируют и дефайнят. Есть богатый опыт разруливания подобных конфликтов, когда хедеры работающие отлично поодиночке начинают сносить крышу компилеру вместе и начинается, а давай поменяем их местами, а давай попробуем #undef max или string. А по поводы производительности, не стоит заниматься преждевременной оптимизацией, к добру это не приводит обычно.

А вы все свои классы через pimpl реализовываете?
если нет, то какие критерии, когда pimpl нужен, а когда нет?

[Alexandr]

Есть богатый опыт разруливания подобных конфликтов, когда хедеры работающие отлично поодиночке начинают сносить крышу компилеру вместе и начинается, а давай поменяем их местами, а давай попробуем #undef max или string.

Это к применению Pimpl никакого отношения не имеет, в общем-то.

[Мальчик-Одуванчик]

все что нужно - задать таг, описывающий настраиваемый тип оборудования, операционки, или иного настраиваемого ресурса.
На этапе компиляци вполне можно через макросы, параметры компилятора или тупо создавая файлы, специфичные для платформы.
дальше - специализации шаблона.
В рантайме - тоже несложно. Вполне вероятно что в следующей редакции языка это будет делать еще проще, благодаря std:unique_resource.
На мой взгляд, что pimpl что частичная специализации хороши лишь когда завязаны на raii - помимо инкапсуляции потрохов дополнительным плюсом будет автоматическое освобождение ресурса при возникновении исключения, следовательно более безопасный код.

[Alexandr]

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

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