Какие проходили сами / можете посоветовать?

Желательно бесплатные, платить за тот же BrainBench денег нет, к сожалению.

хочешь тест — напиши хорошую полезную программу и перестань задавать глупые вопросы

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

PMT>Какие проходили сами / можете посоветовать?

PMT>Желательно бесплатные, платить за тот же BrainBench денег нет, к сожалению.

Quizful.net

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

PMT>Какие проходили сами / можете посоветовать?

Никакие. Авторы этих "тестов" в подавляющем большинстве C++ не знают.

L>Никакие. Авторы этих "тестов" в подавляющем большинстве C++ не знают.

BrainBench, судя по тем заданиям, которые на RSDN выкладывали, вполне неплохо сделан, разве нет? Другое дело, что большинство вопросов, которые там задаются, скорее связаны с точным знанием всех тонкостей стандарта, даже если на практике такие возможности использоваться, скорее всего, никогда не будут (вспомнить хотя бы различные вопросы про спецификации исключений).

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

PMT>BrainBench, судя по тем заданиям, которые на RSDN выкладывали, вполне неплохо сделан, разве нет?
Нет. Очень много вопросов в стиле "разберись в говнокоде, за который гнать надо сцаными тряпками".

PMT> Другое дело, что большинство вопросов, которые там задаются, скорее связаны с точным знанием всех тонкостей стандарта, даже если на практике такие возможности использоваться, скорее всего, никогда не будут (вспомнить хотя бы различные вопросы про спецификации исключений).
Типа того, да.
Теорию может такими вопросами и можно проверить, но никак не практику.

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

L>>Никакие. Авторы этих "тестов" в подавляющем большинстве C++ не знают.

PMT>BrainBench, судя по тем заданиям, которые на RSDN выкладывали, вполне неплохо сделан, разве нет?

Он сделан дилетантами. Как можно доверять составление "тестов" индивидуумам, которые даже не знают, что для листингов нужно использовать моноширинный шрифт?

Более-менее адекватные тесты, из тех, что мне встречались, были от вот этих ребят. Но просто так с улицы на них напроситься ИМХО не выйдет.

Я отношусь к этим тестам не столько как к проверке знаний, а как просто к возможности заглянуть в стандарт языка и что-то освежить в памяти.
Дело в том, что человеческая память (по крайней мере моя) так устроена, что то, что в данный момент не нужно. обычно быстро забывается. А тесты — это больше проверка на вашу память. Иногда даже очень квалифицированные специалисты по С++ допускают, так сказать, детские ляпы. Самый свежий такой ляп допущен при обсуждении вопроса о дружественнных функций. Оппонет, как я понимаю, из комитета по станжартизации, которого я, как говорится, за язык не тянул, предложил мне такой примерно код:

void f();

namespace N1
{
   struct A
   {
      friend void ::f() {}
   };
}

Здесь он умудрился сделать сразу четыре ошибки!
Во-первых, определять функцию можно лишь в том пространстве имен, где она объявлена (имеется в виду не ее переобъявление), или в пространстве имен, которое содержит пространство имен с объявлением функции.
Во-вторых, он должен был в глобальном пространстве имен указать, что функция является встраиваемой, то есть должен был присутствовать специфиактор функции inline. В-третьих, он не может определять дружественную функцию внутри класса, у имени которой указано квалифицированное имя.
В-четвертых, если дружественная функция определяется в классе, то функция должна иметь ту же самую область объявления.
Такие ляпы можно легко допустить любому человеку, который хорошо знает стандарт. То есть обычно любой квалифицированный ответ сначала выверяется по стандарту. Не стоит особо надеятсья на свою память. Стандарт С++ очень большой и по содержанию насыщенный.

Но что еще самое интересное, что этот предложенный пример некорректного кода успешно компилируется GCC 4.7.0!
Так что те, кто свои знания языка С++ основывает лишь на результатах обработки кода тем или иным компилятором, естественно дадут неверный ответ.

Здравствуйте, Сыроежка, Вы писали:

С>Я отношусь к этим тестам не столько как к проверке знаний, а как просто к возможности заглянуть в стандарт языка и что-то освежить в памяти.
С>Дело в том, что человеческая память (по крайней мере моя) так устроена, что то, что в данный момент не нужно. обычно быстро забывается. А тесты — это больше проверка на вашу память. Иногда даже очень квалифицированные специалисты по С++ допускают, так сказать, детские ляпы.

Высококвалифицированные программисты на C++ совершенно не обязательно помнят стандарт C++ наизусть. Да и не нужно это.
Стандарт нужно иметь под рукой, чтобы сверяться с ним в спорных местах. Вот я сейчас пишу код, который должен будет работать на x86, AVR (ага, с 2 килобайтами памяти) и ARM. И, поскольку в шаблонных выражениях не стесняюсь, приходится регулярно проверять, что стандарт думает на тему очередного выражения.


С>

С>   struct A
С>   {
С>      friend void ::f() {}
С>   };
С>

С>Здесь он умудрился сделать сразу четыре ошибки!

Ты чего так завелся-то? Может, человек хотел тебе принципиальный кусок кода на кусочке бумаги набросать? У меня вышеприведенный кусок без отсылок к стандарту вызывает лишь вопрос класса "что сказать-то хотел"?

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

L>Ты чего так завелся-то? Может, человек хотел тебе принципиальный кусок кода на кусочке бумаги набросать? У меня вышеприведенный кусок без отсылок к стандарту вызывает лишь вопрос класса "что сказать-то хотел"?

Я не завелся. Я просто проиллюстрировал свою мысль относительно тестов конкретным примером.
И, кстати сказть, возможно, что уже я сам ошибся, заявив, что предыдущее объявление функции должно иметь спецификатор inline в показанном мною примере. Место в стандарте, где об этом говорится, оставляет много вопросов. Сейчас после дополнительного обсуждения этого вопроса я склоняюсь к тому, что если в классе дружественная функция объявлена со спецификатором inline, и это объявление не является определениеп функции, то она обязана быть предварительно объявленной с этим же спецификатором. Тут возникает вопрос: то ли она обязана быть ранее объявлена, то ли если она объявляется в классе дружественной со спецификатором inline (но не определена), то если существует ранее ее объявление (которое не обязано быть), то оно должно иметь спецификатор inline.
То есть стандарт так написан, что оставляет место для различных трактовок. И очевидно, это не единственное такое место в стандарте, которое может вызывать вопросы.
Теперь представьте, что вам в качестве теста привели такой пример с дружественной функцией причем наряду с другими тестами, чтобы не заострялось ваше внимание именно на этом примере. Вы можете гарантировать, что вы ответите правильно относительно спецификатора inline? Я думаю, что многие вообще об этом даже не задумывались .

Здравствуйте, Сыроежка, Вы писали:

С>То есть стандарт так написан, что оставляет место для различных трактовок. И очевидно, это не единственное такое место в стандарте, которое может вызывать вопросы.
C>Вы можете гарантировать, что вы ответите правильно относительно спецификатора inline?

Я отвечу правильно и односложно "До свидания". Или даже "Прощайте". Если, конечно, это не позиция гуру-толкователя стандарта C++, но туда я даже и подаваться не буду.

Здравствуйте, Сыроежка, Вы писали:

С>Я не завелся...
Знаешь, почитав твои опусы я начинаю задумываться не добавить ли в критерии no hire пункт: наизусть учит стандарт и постоянно на него ссылается.