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

C>В крит. секции может использоваться спинлок, который позволяет (неэффективно) ждать пока секция не разблокируется без участия ядра.

Но именно это "неэффективное" ожидание может спасти от ещё более неэффективного "засыпания" потока.

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

C>>В крит. секции может использоваться спинлок, который позволяет (неэффективно) ждать пока секция не разблокируется без участия ядра.
A>Но именно это "неэффективное" ожидание может спасти от ещё более неэффективного "засыпания" потока.
Если потоки засыпают — значит это кому-то нужно Т.е. его time slice будет использован каким-то другим потоком для выполнения какой-то полезной работы. В случае же со spinlock'ом мы просто будем бесполезно греть окружающую среду.

Следовательно, спинлоки имеет смысл использовать только при небольшой вероятности lock contention'а.

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

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

ZII>>А насчет задач — какая из упомянутых здесь на ваш взгляд не проверяет способность человека решать реальные практические задачи?
КЛ>На мой взгляд, Ваши задания сильно оторваны от практики. Мне кажется, на собеседовании надо задавать только те вопросы, ответы на которые могут как-то охарактеризовать кандидата. Т.е. каждый вопрос должен быть некоторым критерием. И если кандидат ему не соответствует (т.е. не отвечает на вопрос), то продолжать собеседование бесполезно. Какой вывод Вы можете сделать, если кандидат не ответит на Ваш вопрос? Да никакого! Ну, не знает человек, в каких случаях функтор не инлайнится — и что с того?

КЛ>Кроме того, Ваши задачи даны не в той постановке, как они встречаются на практике. Например, человек может зазубрить паттерны и красиво рисовать их UML-диаграммы, но стоит ему столкнуться с задачей, где потребуется Абстрактная Фабрика или Компоновщик, и он предпочтет switch или мешанину из dynamic_cast'ов. Лучшей дайте ему какое-нибудь практическое задание (взятое из Вашей практики) и попросите решить. А затем обсудите с ним решение, а заодно и паттерны. Из решения будет гораздо лучше видно, умеет человек проектировать (хотя бы на микроуровне) или нет. А абстрактные рассуждение ни о чем не говорят.

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

КЛ>На мой взгляд, Ваши задания сильно оторваны от практики. Мне кажется, на собеседовании надо задавать только те вопросы, ответы на которые могут как-то охарактеризовать кандидата. Т.е. каждый вопрос должен быть некоторым критерием. И если кандидат ему не соответствует (т.е. не отвечает на вопрос), то продолжать собеседование бесполезно. Какой вывод Вы можете сделать, если кандидат не ответит на Ваш вопрос? Да никакого! Ну, не знает человек, в каких случаях функтор не инлайнится — и что с того?

КЛ>Кроме того, Ваши задачи даны не в той постановке, как они встречаются на практике. Например, человек может зазубрить паттерны и красиво рисовать их UML-диаграммы, но стоит ему столкнуться с задачей, где потребуется Абстрактная Фабрика или Компоновщик, и он предпочтет switch или мешанину из dynamic_cast'ов. Лучшей дайте ему какое-нибудь практическое задание (взятое из Вашей практики) и попросите решить. А затем обсудите с ним решение, а заодно и паттерны. Из решения будет гораздо лучше видно, умеет человек проектировать (хотя бы на микроуровне) или нет. А абстрактные рассуждение ни о чем не говорят.

Не сочтите за хвастовство, но я сразу определяю вызубрил человек шаблоны проектирования или таки да понимает их и умеет использовать. Кстати, на собеседованиях я прошу кандидата описать те шаблоны, которые он реально использовал в своей практике. Да, приходят люди, которые утверждают что активно пользуются таким "баяном" как абстрактная фабрика. Но выясняется что это просто объект, которому делегировано создание других объектов. Или, ещё случай, что lightweight — это класс, в котором все члены — указатели.

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

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

ZII>>Уважаемый, мы брейнбенч-подобные вопросы используем только для предварительной фильтрации и не требуем 100% правильных ответов. Просто экономия времени. Мне кажется, что если человек из 20 вопросов по С++ правильно отвечает только на 10 (причем уверяю вас, мы не задаем супер сложные вопросы или вопросы с подковырками) то это говорит либо о том, что он только недавно начал учить С++, либо (если у него опыт на С++ 5 лет), что его желание развиваться и поднимать свой технический уровень под большим вопросом.
L>К слову сказать, я вот сеньор.
L>Только.. ну, как бы сказать, чтобы не обидеть.
L>Контора, которая выдает браинбенч-подобные вопросы в лоб (не важно, для фильтрации ли или в каких других целях) моментально перемещается в мой собственный черный список.
L>Так что смотрите, как бы чего лишнего не "отфильтровать"

Мне просто интересно, чем вас пугают брейнбенч-подобные вопросы? Кстати, а какие вопросы вы считаете таковыми?

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

A>>>-чем функтор лучше функции (в частности, эффективнее ли)
A>>>-в каких случаях функцтор или функция не инлайнится?

DC>>Хм.. Насколько я понимаю сильно от компилятора зависит. Кроме того это вроде как рекомендация компилятору, но функтор встроится вероятнее. Наличие >ссылок на функию может повлиять, хотя — хз я не разработчик компиляторов.

A>инлайн это такая необязательная штука, которую компилятор может выполнять, а может и нет.
A>например в VC++ целых три режима оптимизации, связанных только с инлайнами (+ __forceinline)
A>имхо такие вопросы стоит задавать только разработчикам компиляторов, если хотите услышать внятный ответ. у остальных ответ будет
A>носить характер домыслов

Указание inline для функции — совершенно бесполезная штука, по той простой причине что встраиваться код будет в контексте использования и польза от него может определяться только исходя из контекста использования. То есть и решение о встраивании можно принять только видя этот самый контекст. Но когда мы пишем функцию и объявляем её inline, мы то о контексте использования знать ничего не можем. Вот такой вот парадокс.

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

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

ZII>>Wow, прикольно почитать какое у нас сложное собеседование

B>Ну и как вы предлагаете "как избегать рейс кондишена при инициализации синглтона"?
B>Я бы лично ответил, что синглтоны надо инициировать вручную до того,
B>как будет создан второй поток. Наверное бы не прошел ваше интервью...

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

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

D>>>..."виртуальный конструктор"...

A>>

A>>class Base
A>>{
A>>public:
A>>   virtual Base* Clone()=0; // это он
A>>};
A>>

D>хм... это помойму просто метод Clone , как минимум второй части понятия ("конструктор") я не вижу тут
D>и второе, откуда взялся такой термит-то?

ага, с кодом напутали, это обычное клонирование, наверное скопировали не из того раздела вики
а виртульный конструкто взялся вот от этого "it deals with the problem of creating objects (products) without specifying the exact class of object that will be created."

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

A>-чем отличается критическая секция от мьютекса
A>(это их любимый вопрос -я до сих пор НЕ ЗНАЮ, как внутри работает критическая секция,
A>знаю только что она быстрее и ее нельзя шарить между процессами)

А при чем здесь C++? Это вообще-то вопрос про Win32. Есть системы, на которых C++ есть, а разделения на критические секции и мьютексы нету

Теперь про Win32.

Мьютекс это объект ядра. Программа имеет от него HANDLE, и любая операция с мьютексом требует переключения в kernel mode.

Критическая секция пытается не обращаться к ядру в типичном случае — на входе в незанятую критическую секцию (когда ожидание не требуется), и на выходе из критической секции, в которую никто больше не пытается войти (т.е., когда не надо никого будить). Делается это с помощью атомарных инкрементов и т.п. в user space.

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

Если же доходит до блокировки, внутри себя критическая секция имет мьютекс или что-то в этом роде (я не знаю, какой в точности объект синхронизации там используется, но это и не суть важно). Именно его аллоцирует, промежду прочьего, InitializeCriticalSection(), и освобождает DeleteCriticalSection().

Здоров всем,

конечно не в тему, но кто проходил собеседование в Лоджике UK ?

_O_>Я такой подход использовал при создании importer-а из Rational Rose в другой тул. Сей импортер должен был читать Rose файлы напрямую. Это потребовало создания внутреннего представления для файлов, которое как раз и является сложной разновидностью паттерна композит с перекрестным ссылками (в том числе и циклическими). Метамодель + вспомогательные шаблоны были написаны вручную (~ 4000 строк кода). Потом была нарисована UML модели внутреннего представления для Rose-файлов. Затем был написан небольшой кодогенератор (~2000 строк кода), который из этой модели генерил С++ классы + код, инициализирующий метамодель. Объем генеренного кода уже порядка 30 000 строк. В общем, за две недели получилось полноценное и эффективное внутреннее представление, с поддержкой таких операций, как сериализация/десеарилизация/клонирование/обход и т.д, которые зависят лишь от метамодели. Это позволило впоследствии дополнять и уточнять модель без переписывания этих методов.

Не знаю кому как, а мне почему-то захотелось пасть ниц