Здравствуйте, Erop, Вы писали:

E>То есть

struct CXXX { void out() { std::cout << "XXX"; } };
E>class CMy : CXXX {
E>public:
E>    void ToDo() { out(); }
E>};

не скомпилируется?

E>Короче, если ты думаешь про себя, что ты хороший спец, то вот такой формальный "экзамен на зания" ты только что провалил

E>А всё потому, что private наследование -- тоже маргинальщина.
Интересно, и как такими ... вопросами можно определить — приличный программист на плюсах или нет?

E>Короче, если ты думаешь про себя, что ты хороший спец, то вот такой формальный "экзамен на зания" ты только что провалил
E>А всё потому, что private наследование -- тоже маргинальщина.

у нас стандартом кодирования запрещены :
-множественное наследование реализации
-виртуальные базы
-приватное наследование
но на интервью часто спрашивают как раз про всякую такую хрень
и еще про vector<bool> до кучи , который я бы тоже запретил

Здравствуйте, Awaken, Вы писали:

A>у нас стандартом кодирования запрещены :
A>-множественное наследование реализации
A>-виртуальные базы
A>-приватное наследование

А вы случаем не на C#/Java программируете?
Если нет, то попробуйте

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Интересно, и как такими ... вопросами можно определить — приличный программист на плюсах или нет?
ИМХО никак нельзя
Просто Константину такие нравятся, вот я ему ищё один и придумал.

Хотя, как это ни прикольно, обсуждая тут этот вопрос многие люди прокололись по каким-то маргинальным вещам. Кто-то забыл про функцию exit, кто-то о правилах privte наследования...

Здравствуйте, Awaken, Вы писали:

E>>Короче, если ты думаешь про себя, что ты хороший спец, то вот такой формальный "экзамен на зания" ты только что провалил
E>>А всё потому, что private наследование -- тоже маргинальщина.

A>у нас стандартом кодирования запрещены :
A>-множественное наследование реализации

тут, конечно, надо буть осторожным

A>-виртуальные базы

хм... Это что?

A>-приватное наследование

Конечно можно заменить делегированием, но на запрет не тянет

A>но на интервью часто спрашивают как раз про всякую такую хрень
A>и еще про vector<bool> до кучи , который я бы тоже запретил

+1

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Константин Л., Вы писали:

КЛ>>ну если конечно в команде есть ацкий любитель шаблонов, пихающий их куда попало...
E>Ну однажды был и такой.
E>Но в целом в конторе очень много разработок, весьма наукоёмких. За всеми-то не уследишь, а рефакторинг потом дорогой.
E>Ещё правда помогает то, что STL не используется. Используется своя библиотека контейнеров.

это настораживает. Хотя может быть специфика.

КЛ>>Опыт в поиске ошибок говорит о знаниях, которые не бывают лишними.
E>Ну мой вот опыт показал мне, что бывают люди которые хорошо знают всякие ж-ы, потому что при программировании из них не вылазят

))). Люди бывают разные

E>Просто опыт и знания можно как-то более прямо проверить, ИМХО

ага

[]

КЛ>>По дэфолту наследование private когда не указан спецификатор доступа, соотв. СMyOps::exit становится private для CMyprocessor. Или protected? кароче, забыл

E>То есть

struct CXXX { void out() { std::cout << "XXX"; } };
E>class CMy : CXXX {
E>public:
E>    void ToDo() { out(); }
E>};

не скомпилируется?

E>Короче, если ты думаешь про себя, что ты хороший спец, то вот такой формальный "экзамен на зания" ты только что провалил

1. я бы не стал задавать такой вопрос.
2. Я бы не стал на него отвечать
3. Я бы не принимал во внимание правильность ответа на него

E>А всё потому, что private наследование -- тоже маргинальщина.

Насколько я помню из курса социологии, маргинальщина по определению не делает какие-то вещи плохими. Она делает их редкими.

Здравствуйте, Erop, Вы писали:

E>>>>1) Какие соглашения о вызове совместимы с функциями с переменным числом параметров (которые ...)?
E>>>>ИМХО этот вопрос задавать на собеседовании глупо

RO>>wtf «соглашения о вызове»? ISO 14882:2003 такого не знает.
E>__cdecl например. Слышал такое слово?

Я слышал, Рихтер слышал, Страуструп — нет. Речь вроде о C++, не о конкретных его реализациях.

E>>>>2) Если я заключу кусок кода в

extern "c" {

тут код

}

, то что-нибудь в коде поменяется?

RO>>Поменяется.

E>А что именно?
E>В смысле в семантике самого кода?

Implementation-defined, потому что реализации обязаны поддерживать только extern "C" и extern "C++" :-)

extern "C" позволяет использовать функции C в C++, или наоборот. Обычно extern "C" отключает C++ name mangling со всеми вытекающими последствиями. Любопытно, что это не помешает объявлять операторы, но только по одному разу.

Здравствуйте, Константин Л., Вы писали:

E>>Ещё правда помогает то, что STL не используется. Используется своя библиотека контейнеров.
КЛ>это настораживает. Хотя может быть специфика.
Ну тут уже было недавно обсуждение минусов STL
У нас есть всё нужное "ещё с той войны", когда STL только изобретали. Теперь переходить на него толку никакого. Кроме того к нему есть ряд серьёзных претензий.
Короче у нас реально крутая IT контора с очень большим опытом разработок. Так что проверено на опыте -- STL не главное.

E>>А всё потому, что private наследование -- тоже маргинальщина.

КЛ>Насколько я помню из курса социологии, маргинальщина по определению не делает какие-то вещи плохими. Она делает их редкими.

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

На всяк случай. public и protected члены private базы наследуются как private члены.

Здравствуйте, Roman Odaisky, Вы писали:

E>>>>>1) Какие соглашения о вызове совместимы с функциями с переменным числом параметров (которые ...)?
E>>>>>ИМХО этот вопрос задавать на собеседовании глупо

E>>__cdecl например. Слышал такое слово?
RO>Я слышал, Рихтер слышал, Страуструп — нет. Речь вроде о C++, не о конкретных его реализациях.
речь о вопросах на собеседовании. Еслитебе трудно так общё, то можно обсудить gcc или VS

---

RO>extern "C" позволяет использовать функции C в C++, или наоборот. Обычно extern "C" отключает C++ name mangling со всеми вытекающими последствиями. Любопытно, что это не помешает объявлять операторы, но только по одному разу.

Ну почти угадал. extern "C" функции в глобальном namespace не могут быть перегружены. Именно до этого и можно дойти логическими рассуждениями

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Константин Л., Вы писали:

E>>>Ещё правда помогает то, что STL не используется. Используется своя библиотека контейнеров.
КЛ>>это настораживает. Хотя может быть специфика.
E>Ну тут уже было недавно обсуждение минусов STL
E>У нас есть всё нужное "ещё с той войны", когда STL только изобретали. Теперь переходить на него толку никакого. Кроме того к нему есть ряд серьёзных претензий.
E>Короче у нас реально крутая IT контора с очень большим опытом разработок. Так что проверено на опыте -- STL не главное.

ни кто и не сомневался

E>>>А всё потому, что private наследование -- тоже маргинальщина.

КЛ>>Насколько я помню из курса социологии, маргинальщина по определению не делает какие-то вещи плохими. Она делает их редкими.

E>Ну да, имеено поэтому реальные перцы, которые работают, а не ботают стандарт наизусть в маргинальных вещв
E>ах обычно плавают.

а совсем реальные перцы делают и то и то. Но их мало.

Здравствуйте, Константин Л., Вы писали:

КЛ>Важно, чтобы он знал, что this идет как скрытый аргумент методов класса.

Практически бесполезное знание неких деталей реализации,
которое в общем-то не нужно при программировании C++

Зачем это нужно, за исключением грязных хаков?

Здравствуйте, Awaken, Вы писали:

A>интересный и умный вопрос — когда к ответу приходишь логическим путем, а не просто "знаешь"

ИМХО на собеседовании важнее всего не вопросы, а стратегия и ясное понимание целей и задач мероприятия
Собственно всё дальше только моё ИМХО и подходит наверное только для большой конторы

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

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

Соответсвенно идеальный процесс лично мне представляется таким:

1) Собеседование. В результате решаем что
а) Кандидат и вы друг дургу не подходите
б) Кандидат подходит, но ему нужно подучиться
в) Кандидат подходит и вроде бы знает достаочно

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

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

Соответсвенно имеем три варианта собеседования.

1) Собственно стартовое собеседование
2) Экзамен-семинар для новичка
3) Экзамен-собеседование для чела с опытом

У всех трёх свои цели, задачи и, соответсвтенно, методы проведения
На стартовом собеседовании надо понять опыт кандидата, его общую математическую эрудицию, теоритические знания, уровень занния языка, библиотек, средств разработки. Выяснить личные качества и готовность принять ценнсоти, принятые в конторе.

Как-то так в общем

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Roman Odaisky, Вы писали:

E>>>>>>1) Какие соглашения о вызове совместимы с функциями с переменным числом параметров (которые ...)?
E>>>>>>ИМХО этот вопрос задавать на собеседовании глупо

E>>>__cdecl например. Слышал такое слово?
RO>>Я слышал, Рихтер слышал, Страуструп — нет. Речь вроде о C++, не о конкретных его реализациях.
E>речь о вопросах на собеседовании. Еслитебе трудно так общо, то можно обсудить gcc или VS :)

Насколько я помню, CDECL — аргументы кладутся на стек, который разбирает вызываемая функция, STDCALL (PASCAL) — тоже стек, но разбирает его вызывающая функция, и порядок аргументов у CDECL и STDCALL противоположный, и FASTCALL — аргументы в регистрах. Как-то так, надо будет — выгуглю. По идее, только CDECL умеет ..., но я не уверен.

E>

---

RO>>extern "C" позволяет использовать функции C в C++, или наоборот. Обычно extern "C" отключает C++ name mangling со всеми вытекающими последствиями. Любопытно, что это не помешает объявлять операторы, но только по одному разу.

E>Ну почти угадал. extern "C" функции в глобальном namespace не могут быть перегружены. Именно до этого и можно дойти логическими рассуждениями :)

А я о чем?

И всё равно забавно — extern "C" operator. В C++09 это будет запрещено, но пока можно.

Здравствуйте, Smal, Вы писали:

RO>>Ну примерно. А если вторая функция упорно требует std::string const &, а не Iterator, Iterator?
S>В эависимости от того как первая возвращает значение.

std::string getSomeInterestingData();

Здравствуйте, Erop, Вы писали:

E>ИМХО на собеседовании важнее всего не вопросы, а стратегия и ясное понимание целей и задач мероприятия
E>Собственно всё дальше только моё ИМХО и подходит наверное только для большой конторы

E>1) Икать надо людей способных быть хорошими программистами, а не изучивших что-то конкртеное. ИМХО личные качества и способности намного важнее знаний. Правда знания тоже очень важны, но никакие знания не компинсируют отсутсвие способностей. С другой стороны любые зания дело наживное.

E>2) Реальные качества программиста можно понять только за испытательный срок, а не во время собесдования.

E>Соответсвенно идеальный процесс лично мне представляется таким:

E>1) Собеседование. В результате решаем что
E>а) Кандидат и вы друг дургу не подходите
E>б) Кандидат подходит, но ему нужно подучиться
E>в) Кандидат подходит и вроде бы знает достаочно

Всё равно придется учиться/подстраиваться — это 100%.

Мне больше нравится подход Джоэла («The Guerrilla Guide to Interviewing») — чисто субъективно, я не специалист по кадрам.

Здравствуйте, Константин Л., Вы писали:

КЛ>а совсем реальные перцы делают и то и то. Но их мало.
Опять же по опыту. Настолько реальные перцы обычно ценны безотносительно к знанию маргинальных вещей

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

Здравствуйте, Roman Odaisky, Вы писали:

RO>Насколько я помню, CDECL — аргументы кладутся на стек, который разбирает вызываемая функция, STDCALL (PASCAL) — тоже стек, но разбирает его вызывающая функция, и порядок аргументов у CDECL и STDCALL противоположный, и FASTCALL — аргументы в регистрах. Как-то так, надо будет — выгуглю. По идее, только CDECL умеет ..., но я не уверен.

Ну где-то так примено. Общая идея такая, что можно передать только по такому соглашени о вызове, когда стек чистит вызывающая сторона. Это довольно принципиалное требование, ИМХО, и до него тоже можно дойти логическим путём.
Грубо говоря ответ на этот вопрос до какой-то степени демонстрирует понимание кандидатом "как устроен С++"

E>>

---

RO>А я о чем?
Ну я так и понял. Я бы твой ответ зачёл, так скажем. Просто тут ведь разные люди форум читают. Некоторрые могли твой ответ не расшифровать

RO>И всё равно забавно — extern "C" operator. В C++09 это будет запрещено, но пока можно.
Ну да, но это маргинальщина, ИМХО. Я бы, наоборот, отменил действие extern "C" на операторы

Здравствуйте, Roman Odaisky, Вы писали:

RO>

std::string getSomeInterestingData();

Ну типа copy пззвать от rbegin rend?

Здравствуйте, Roman Odaisky, Вы писали:

RO>Всё равно придется учиться/подстраиваться — это 100%.
Ну так поэтому и нужен испытательный срок с экзаменом-собеседованием-обсуждением всего что нужно для работы даже для знающего сотрудника.
У нас, например, он обычно равен месяцу.

RO>Мне больше нравится подход Джоэла («The Guerrilla Guide to Interviewing») — чисто субъективно, я не специалист по кадрам.

А коротко не перескажешь? А то долго читать, сейчас не затяну

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, alexeiz, Вы писали:

A>>- Как реализовать Singleton?

RO>Я уже представляю, что будет, если на это собеседование придет IB.

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

Фишка вопроса (как и всех, которые я задаю на интервью) в том, что он предпологает беседу. Вопрос задается кратко. Он недоформулирован. Человек начинает додумывать: какие требования, где применяется, и т.д. — мыслить вслух. Его можно направлять, т.е. сказать: "давайте возьмем вот этот случай". Я заранее предпологаю некоторый план, по которому может развиваться беседа. Иногда бывает так, что человек "забегает вперед". Т.е. он сразу начинает обсуждать проблемы, о которых я только собрался его спросить. Это большой плюс.

Мне очень понравился подход Joel Spolsky, и я взял его на вооружение. От человека на интервью требуется показать две вещи. Что он: 1) smart, 2) gets things done. Я считаю, что это можно в какой-то мере выяснить, наблядая, как он подходит к задаче, не имеющей законченного или предопределенного решения.