Здравствуйте, pavard, Вы писали:
P>как объяснить вторую напечатанную строку? и почему она отличается от третей. )
P>
P>#include <iostream>
P>struct Iface
P>
Вторая строка (пустая) служит для разделения списка импортированных файлов и объявления структуры.
Она отличается от третьей, потому что одной пустой строки достаточно.
От модератора.
Как выяснилось, это не проблема, с которой топикстартер столкнулся, а вопрос, придуманный им для собеседований.
Вступая в дискуссию, делайте поправку на этот факт.
Здравствуйте, pavard, Вы писали:
P>как объяснить вторую напечатанную строку? и почему она отличается от третей. )
Автор спрашивает в частном сообщении, за что я поставил минус.
Я его поставил, потому что 1) вопрос мне не понравился, и 2) в тот момент не было желания отметить этот факт текстом комментария. Но раз уж всё равно его пишу, то есть смысл обяснить публично, а не в личке.
«0) Steps to reproduce.» — плохая формула багрепорта или вопроса на форуме.
«0) Steps to reproduce. 1) Observed behavior. 2) Expected behavior.» — хорошая, годная формула.
По-моему, логично, что в интересах вопрошающего предоставить максимум нужной (и минимум лишней) информации, и не заставлять читателей 1) интерпретировать код в уме, 2) читать мысли автора.
ты код еще раз прочитай только внимательно. особое внимание на строчку r.Func(). r типа reg_t, reg_t::Func() — не виртуальный. темнеменее r.Func() выполнит bus_t::Func() потом отвечай.
объясни что такое полиморфизм времени исполнения в плюсах? звучит клево и многообещающе. приходилось писать?
Х>Например: берем две-три задачки, не завязанные на конкретный язык программирования (например — первое, что пришло в голову: "выведите в консоль календарь за нынешний месяц")...
Здравствуйте, pavard, Вы писали:
P>как объяснить вторую напечатанную строку?
Особенностями компилятора. Имена начинающиеся с двух подчёркиваний часто имеют особый смысл.
P>и почему она отличается от третей. )
Потому, что вы использовали нестандартизованное имя __PRETTY_FUNCTION__.
Во-первых, из вашего вопроса вовсе не очевидно, что этот вопрос вы задаете на собеседованиях и уже знаете ответ. Читаем:
P>как объяснить вторую напечатанную строку? и почему она отличается от третей. )
Также не очевидно, какие именно комментарии вы хотели получить. Хвалебные ("чувак, классный вопрос для собеседования")? Критические ("не, для собеседования слишком просто")? Т.е. вы забыли самое главное — задать тот вопрос, на который вам хотелось бы получить ответ.
Но это не повод для минуса, неумение задавать вопросы — явление широко распространенное (яркий пример из недавнего
Главное, которое во-вторых — это ваша реакция на вполне логичные ответы на ваш прямо заданный вопрос. Вы не исправили ситуацию, не спросили прямо то, что вас интересует, а начали искрометно хамить
, а когда вам попытались объяснить ваш промах — вы с большим искусством перешли на личности.
От себя лично добавлю, что если бы мне на собеседовании стали задавать вопросы с таким уровнем понимания базовых принципов С++, да еще сопровождая вопросы комментариями в стиле "ты код еще раз прочитай только внимательно, потом отвечай", я бы отказался от предлагаемой вакансии. Отказался бы несмотря на плюшки.
Здравствуйте, Хреннос, Вы писали:
Х>От себя лично добавлю, что если бы мне на собеседовании стали задавать вопросы с таким уровнем понимания базовых принципов С++, да еще сопровождая вопросы комментариями в стиле "ты код еще раз прочитай только внимательно, потом отвечай", я бы отказался от предлагаемой вакансии. Отказался бы несмотря на плюшки.
сабж, то у меня такой вопрос: у вас есть проект, вам надо сделать часть проекта на с++(яве, в фотошопе, в блокноте), но вы в этом не шарите, а вам надо как-то провести тестирование кандидатов. Как быть, какие есть варианты? Можно нарыть в интеренете задачек, и даже не зная ответа, просто смотреть на реакцию претендента уверенно или нет отвечает, но тут, конечно же, можно влететь сразу по нескольким направлениям.
Для меня пока тут ответ: "никак".
Здравствуйте, CEMb, Вы писали:
CEM>сабж, то у меня такой вопрос: у вас есть проект, вам надо сделать часть проекта на с++(яве, в фотошопе, в блокноте), но вы в этом не шарите, а вам надо как-то провести тестирование кандидатов. Как быть, какие есть варианты?
Вариантов, на самом деле, масса. Задача собеседования ведь не в том, чтобы найти человека с самым глубочайшим знанием всех тонкостей языка — задача в том, чтобы найти человека, у которого голова работает нормально и с которым вы сможете работать.
Например: берем две-три задачки, не завязанные на конкретный язык программирования (например — первое, что пришло в голову: "выведите в консоль календарь за нынешний месяц"). Предлагаем кандидату их решить на бумажке, при этом чтобы он комментировал вслух процесс решения. Когда он начинает решать, задаем вопросы: а вот это зачем, а вот это что, а как вот это вот работает, а почему так сложно, а нельзя ли проще, а какие еще есть варианты сделать вот это вот, а под линуксом это будет работать или нет, а для этого точно не потребуется никаких сторонних библиотек или модулей? И т. д.
И смотрим, как себя ведет разработчик. Если он может внятно и доходчиво рассказать, что он делает и почему, то это хороший, годный разработчик. Если же он что-то там бубнит, хитрит, отказывается объяснить, то вряд ли у вас в дальнейшем получится с ним работать (даже если он знает язык программирования аки бог).
CEM>Можно нарыть в интеренете задачек, и даже не зная ответа, просто смотреть на реакцию претендента уверенно или нет отвечает, но тут, конечно же, можно влететь сразу по нескольким направлениям.
Это не очень хороший вариант, т.к. вы не сможете оценить адекватность решения, не совпадающего с "каноничным".
Лучше придумать какую-то общую задачку самому — тогда вы сами сможете понять, в правильном ли направлении шумит камыш в голове у кандидата. Кроме того, вы сможете задавать предметные вопросы: "а как обрабатывается такая-то ситуация (например, високосный год для календаря)?".
Впрочем, можно взять из интернета, скажем, тест по всяким закавыкам целевого ЯП, и дать его порешать кандидату. Тут главное понять, что хорошие результаты тестов не обязательно соответствуют глубоким знаниям. Поэтому тестирование лучше рассматривать как один из этапов собеседования, причем не главный. Вам с этим человеком потом придется вместе работать, а не кроссворды решать.
CEM>Для меня пока тут ответ: "никак".
Здравствуйте, pavard, Вы писали:
P>ты код еще раз прочитай только внимательно. особое внимание на строчку r.Func(). r типа reg_t, reg_t::Func() — не виртуальный. темнеменее r.Func() выполнит bus_t::Func() потом отвечай.
P>объясни что такое полиморфизм времени исполнения в плюсах? звучит клево и многообещающе. приходилось писать?
r у тебя типа reg_t& — ссылка на базовый класс. Ответь себе сам — при создании ссылки таблица виртуальных функций в b переписывается? Ситуация из букваря, поэтому и послал в букварь. Последний вызов, как ты сам заметил, не виртуальный, поэтому вызовется функция из reg_t.
Здравствуйте, Хреннос, Вы писали:
Х>И смотрим, как себя ведет разработчик. Если он может внятно и доходчиво рассказать, что он делает и почему, то это хороший, годный разработчик. Если же он что-то там бубнит, хитрит, отказывается объяснить, то вряд ли у вас в дальнейшем получится с ним работать (даже если он знает язык программирования аки бог).
некоторые вещи сложно объяснить тем кто ничего не понимает в предмете
вот например, по ходу решения задачи надо написать логирование, и я например напишу хелпер
а ты допустим С++ не знаешь и спросишь меня что тут вообще написано — что за template, зачем точки, что за &&, зачем initializer_list, что вообще значит {(os << ts, 0)...}
и как на это ответить так чтобы человек незнающий С++ что-то понял?
Х>Главное, которое во-вторых — это ваша реакция на вполне логичные ответы на ваш прямо заданный вопрос. Вы не исправили ситуацию, не спросили прямо то, что вас интересует, а начали искрометно хамить
Х>Вариантов, на самом деле, масса. Задача собеседования ведь не в том, чтобы найти человека с самым глубочайшим знанием всех тонкостей языка — задача в том, чтобы найти человека, у которого голова работает нормально и с которым вы сможете работать.
знать алгоритм и уметь его грамотно реализовать — это два разных свойства. нужно проверять оба.
если ты наймешь для командировки передодчика с теми установками что у тебя, — есть риск как минимум остаться не понятым и других не понять, как максимум — получить в бубен, если к примеру переводчик не будет знать и не учтет при переводе всех тонкостей языка и культуры народа.
так и в программировани, нужно не только знать хорошо язык, но когда и как компилятор что во что. )