Здравствуйте, Selavi, Вы писали:
S>1) S>Да, я мог бы реализовать конструктор копирования в CTask и создавать копии заданий работы пула потоков (кстати, тоже можно придраться за лишние операции и расход памяти) S>Да, я мог бы реализовать корректное хранение и удаление заданий вне пула потоков
Возможно, я неудачно сформулировал.
В рамках пула тебе не надо было реализовывать управление ЖЦ заданий вообще. В задании же ясно показан "чистый" указатель на CTask. На стороне пользователя при этом можно управлять объектами как угодно, хоть в стеке их размещать — это уже не твоё дело. Главное, что будет полная ясность с политикой владения: пул заданиями не владеет, это ответственность пользователя. А если пул принимает на вход shared_ptr, то стереотипичная интерпретация такова, что контроль ЖЦ возложен на этот указатель и никаких дополнительных копий хранить не требуется.
А у тебя получается, что ты и на входе берёшь shared_ptr, и ещё требуешь хранить его вовне. Зачем?!
S>Но есть же какое то разумное ограничение на время для тестового задания? Или мне надо было писать промышленную версию? Я просто не стал морочиться и кстати, написал это и в комменте к строчке и в описании к ТЗ. Почему то Вы на это не обратили внимания.
Это никак не соотносится с тем, что ты написал в пояснительной записке.
S>2) Что такого плохого в this->clientTaskFinisher = clientTaskFinisher?
Да ничего плохого, просто лишние буквы, от которых можно было бы избавиться.
S>3) Чем же лучше 2хфазная инициализацию/разрушение?
Проще контролировать вылетающие исключения.
S>4) Вам не нравится использование интерфейсов в С++? Раздражает constructor injection? Что не так?
Тем, что __interface — это не C++, а MSVC.
S>5) Да, с комментариями больной вопрос. Лично я придерживаюсь идеи дядюшки Боба о том, что комментарии засоряют код и нужно комментировать названиями методов и переменных. Считаю, что код в ТЗ вполне понятен и не требует лишней прозы.
Как интервьюера, меня не интересует, почему ты так считаешь, мне не нравится расшифровывать семантику кода, которую можно было бы кратко обозначить в комментариях. Речь не идёт о том, чтобы комментировать каждый член класса, но алгоритмическую часть вполне можно было бы снабдить пояснениями.
S>6) Может и так, не буду спорить, хотя это снова мелочь.
Дружище, это не мелочи. Это то, что в сумме создаёт впечатление о твоём задании и главное — о твоём отношении к читателям твоего кода. А оно у тебя, мягко говоря, не очень.
S>Похоже на мелкие придирки, которые каждый может изобрести на свой вкус
S>Честно говоря, я ожидал, что будут замечания к алгоритму выборки клиентов, либо к реализации многопоточности в стиле "здесь можно было бы улучшить быстродействие"
В здравом уме и трезвой памяти это мало, кто будет делать. Тестовое задание — это самопрезентация, здесь "шоу" важнее, чем содержание.
Если кратко, то впечатление складывается такое:
— Задание реализовано неточно (CTask* vs. shared_ptr<CTask>);
— Работает странно;
— Оформлено небрежно.
Вывод?
S>А в итоге — все свелось к недовольству плохим стилем кода и отсутствием комментариев, хотя я написал аж целую сагу о том, как эта фигня работает.
А как правило в тестовых заданиях и не ставят задачу реализовать какой-то сложный алгоритм — о них можно дискутировать годами. Обычно хотят просто посмотреть на твои способности и как раз на те самые мелочи, которые ты презрительно отвергаешь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Selavi, Вы писали:
S>3) Чем же лучше 2хфазная инициализацию/разрушение?
По опыту смартпойнтеры + отсутствие 2х-фазных инициализации/разрушения + многопоточность это почти как кислород + масло + Гомер Симпсон.
S>4) Вам не нравится использование интерфейсов в С++? Раздражает constructor injection? Что не так?
S>Здравствуйте, gandjustas, Вы писали:
A>>1) слишком много классов, реализация размазана по трем классам, очень сложно читать A>>2) лишний поток для раскидывания задач, потоки — дорогое удовольствие. A>>3) отсутствует оповещение об окончании A>>4) из-за 3) неясно как будет освобождаться task A>>5) очередь стоило бы сделать lockfree
S>1) Сложно? Имо, наоборот, это как раз суть ООП — создавать абстракции и раскидывать их по классам. Если взять класс CThreadPoolX и просмотреть его методы, то становится однозначно понятно, что он делает. Я много раз видел, как люди запихивают все в 1 класс и это кошмар для понимания
Конечно сложно. Из-трех классов у тебя примерно в 3 раза больше кода, чем стоило бы написать. Никакое ооп не является оправданием. Избыток кода сильно затрудняет понимание.
S>2) Согласен, но без него будет подвисать пользователь пула потоков, что навряд ли правильно. Впрочем, тут вопрос производительности
Ничего подвисать не будет, если правильно писать.
S>3) Об окончании чего?
Выполнении задачи конечно.
S>4) Не совсем понял о чем речь. Все task обернуты в shared_ptr и корректно освобождаются после удаления их из очередей. Есть, конечно, вариант, что они освободятся на стороне пользователя пула потоков, но знаете, это же все таки тестовое задание, а не реальная разработка.
Ты получаешь указатель, и не сообщаешь вызываемому коду когда задача завершена. Внимание вопрос: когда освобождать CTask?
Я бы на твоем месте нагуглил хороший пример, а потом бы допилил алгоритм распределения задач.
Здравствуйте, gandjustas, Вы писали:
G>Ты получаешь указатель, и не сообщаешь вызываемому коду когда задача завершена. Внимание вопрос: когда освобождать CTask?
При таком интерфейсе CTask сам может сообщить о своем завершении, видимо это и предполагается в исходной задаче.
Здравствуйте, Selavi, Вы писали:
S>...выполнено слабо S>К сожалению, добиться обратной связи на тему "что именно слабо" не удалось. S>Пожалуйста, покритикуйте реализацию.
Буквально с первых строчек:
int _tmain(int argc, _TCHAR* argv[])
{
std::unique_ptr<CThreadPoolX> pool (new CThreadPoolX(5));
Тут никакой *_ptr вообще не нужен. Так обычно пишут Java/C# программисты не знающие идиом C++.
Советую начать с чтения книжек Страуструпа.
Здравствуйте, Геннадий Васильев, Вы писали:
S>>3) Чем же лучше 2хфазная инициализацию/разрушение? ГВ>Проще контролировать вылетающие исключения.
close/clear/finish — возможно (хотя подобное достигается через optional или default constructor + move assignment), но двухфазная инициализация точно не нужна.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Тут никакой *_ptr вообще не нужен. Так обычно пишут Java/C# программисты не знающие идиом C++. EP>Советую начать с чтения книжек Страуструпа.
И сколько же мне нужно прочитать книжек Страуструпа, чтобы найти идиому С++, которая объяснит почему тут не нужен умный указатель?
Наверное потому, что память все равно очистится при выходе из программы? Почему нельзя было просто это сказать, а не делать высокомерную отсылку к Страуструпу? Полезность такого поста нулевая.
Здравствуйте, Selavi, Вы писали:
EP>>Тут никакой *_ptr вообще не нужен. Так обычно пишут Java/C# программисты не знающие идиом C++. EP>>Советую начать с чтения книжек Страуструпа. S>И сколько же мне нужно прочитать книжек Страуструпа, чтобы найти идиому С++, которая объяснит почему тут не нужен умный указатель?
Достаточно одной TC++PL
S>Наверное потому, что память все равно очистится при выходе из программы?
Нет. Потому что вот это
std::unique_ptr<CThreadPoolX> pool (new CThreadPoolX(5));
заменяется на:
CThreadPoolX pool(5);
На C++ в большинстве случаев не нужны никакие владеющие указатели (ни умные, ни тем более простые).
S>Почему нельзя было просто это сказать, а не делать высокомерную отсылку к Страуструпу?
Потому что помимо этого базового пробела наверняка есть множество других. Пытаться фиксить их один за одним на форуме — малопродуктивно.
S>Полезность такого поста нулевая.
Я дал совет который считаю что даст максимальный полезный эффект. Конечно твоё право им не воспользоваться.
Здравствуйте, Selavi, Вы писали:
S>...выполнено слабо S>К сожалению, добиться обратной связи на тему "что именно слабо" не удалось.
К сожалению, в современном С++ я ничего не понимаю. Но, судя по комментариям, вы в задании не выполнили некие ритуалы, которые должны выполняться, но о которых не пишут в книгах, считая оные ритуалы самоочевидными. Также, в каждой конторе эти ритуалы слегка отличаются. То есть, от вас хотят видеть то же, что они хотели видеть в своих проектах. Это не означает, что в проектах у них это самое имеется, там может быть (и скорее всего есть) ужасная кодовая лапша. Однако же, со своей кодовой кодовой базой они сделать ничего не могут, зато могут требовать от соискателя соответствия неким идеалам, описанным только у них в голове.
Итого — лучше иметь возможность беседовать с интервьювером напрямую и постараться вести разговор самому, то есть — задавать тему. Любой человек может задать кучу вопросов, на которую не ответит любой собеседник. Постарайтесь донести до интервьювера мысль, что спрашивать надо о том, что человек знает, а не пытаться намеренно убедиться в его невежесте.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Selavi, Вы писали:
EP>>>Тут никакой *_ptr вообще не нужен. Так обычно пишут Java/C# программисты не знающие идиом C++. EP>>>Советую начать с чтения книжек Страуструпа. S>>И сколько же мне нужно прочитать книжек Страуструпа, чтобы найти идиому С++, которая объяснит почему тут не нужен умный указатель?
EP>Достаточно одной TC++PL
S>>Наверное потому, что память все равно очистится при выходе из программы?
EP>Нет. Потому что вот это EP>
EP>std::unique_ptr<CThreadPoolX> pool (new CThreadPoolX(5));
EP>
заменяется на: EP>
EP>CThreadPoolX pool(5);
EP>
EP>На C++ в большинстве случаев не нужны никакие владеющие указатели (ни умные, ни тем более простые).
S>>Почему нельзя было просто это сказать, а не делать высокомерную отсылку к Страуструпу?
EP>Потому что помимо этого базового пробела наверняка есть множество других. Пытаться фиксить их один за одним на форуме — малопродуктивно.
S>>Полезность такого поста нулевая.
EP>Я дал совет который считаю что даст максимальный полезный эффект. Конечно твоё право им не воспользоваться.
С>Итого — лучше иметь возможность беседовать с интервьювером напрямую и постараться вести разговор самому, то есть — задавать тему. Любой человек может задать кучу вопросов, на которую не ответит любой собеседник. Постарайтесь донести до интервьювера мысль, что спрашивать надо о том, что человек знает, а не пытаться намеренно убедиться в его невежесте.
Здравствуйте, Слава, Вы писали:
С>К сожалению, в современном С++ я ничего не понимаю. Но, судя по комментариям, вы в задании не выполнили некие ритуалы, которые должны выполняться, но о которых не пишут в книгах, считая оные ритуалы самоочевидными. Также, в каждой конторе эти ритуалы слегка отличаются. То есть, от вас хотят видеть то же, что они хотели видеть в своих проектах. Это не означает, что в проектах у них это самое имеется, там может быть (и скорее всего есть) ужасная кодовая лапша. Однако же, со своей кодовой кодовой базой они сделать ничего не могут, зато могут требовать от соискателя соответствия неким идеалам, описанным только у них в голове.
С>Итого — лучше иметь возможность беседовать с интервьювером напрямую и постараться вести разговор самому, то есть — задавать тему. Любой человек может задать кучу вопросов, на которую не ответит любой собеседник. Постарайтесь донести до интервьювера мысль, что спрашивать надо о том, что человек знает, а не пытаться намеренно убедиться в его невежесте.
Странная логика. И наниматель, и кандидат ищут друг в друге нечто более или менее определённое. Почему при этом именно работодатель должен старательно обходить сложные для кандидата моменты — сие неведомо. Простите, а кандидат тоже должен бояться спросить у работодателя, например, соблюдает ли тот КЗоТ? А то, вдруг не соблюдает и страшно оскорбится таким вопросом.
И потом, то, что в этом топике сказали топикстартеру, это не какие-то специфические "ритуалы", доступные только посвящённым, а в основном банальные, уже давно устоявшиеся правила хорошего тона с небольшой поправкой на ситуацию собеседования. Естественно, все понимают, что в production-коде может царить хаос и кабакЪ, но это же не означает, что на собеседовании нужно заниматься тем же самым.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Странная логика. И наниматель, и кандидат ищут друг в друге нечто более или менее определённое. Почему при этом именно работодатель должен старательно обходить сложные для кандидата моменты — сие неведомо. Простите, а кандидат тоже должен бояться спросить у работодателя, например, соблюдает ли тот КЗоТ? А то, вдруг не соблюдает и страшно оскорбится таким вопросом.
ГВ>И потом, то, что в этом топике сказали топикстартеру, это не какие-то специфические "ритуалы", доступные только посвящённым, а в основном банальные, уже давно устоявшиеся правила хорошего тона с небольшой поправкой на ситуацию собеседования. Естественно, все понимают, что в production-коде может царить хаос и кабакЪ, но это же не означает, что на собеседовании нужно заниматься тем же самым.
Ну мне кажется, что Вы преувеличиваете насчет банальных и давно устоявшихся.
Впрочем, наверное стоило бы говорить о требованиях к кандидату. Вы считате что человек, претендующий на 140к должен знать как минимум все что написано в этом топике? Имо, это все таки уровень сеньора и деньги другие. Если же Вы мне скажете, что это должен знать миддл, то я убьюсь об стенку.
Работая над этим ТЗ я потратил большую часть времени потратил на обдумывание алгоритма, который удовлетворяет требованиям задачи так, как я их вижу. На мой взгляд алгоритм получился очень даже неплохим и реализация его вполне себе рабочая, без дедлоков, гонок и прочего безобразия. Да, много деталей можно править и улучшать и в реальной обстановке я бы не раз возвращался к этому коду с целью оптимизации и рефакторинга, причем по собственному почину. А в итоге получается, что всем плевать на алгоритм, на ход размышлений, на то, что в итоге все работает, пусть и со скрипом. Главное, что я там вместо голого указателя использовал умный и что комменты не написал.
Кстати, неприятно, что в этой конторе сидят жлобы, которые даже не удосужились ответить. Подумаешь, кто-то там потратил N часов на ТЗ. Не понравилось, значит игнорим. Рашка, блин.
Здравствуйте, Selavi, Вы писали:
S>Ну мне кажется, что Вы преувеличиваете насчет банальных и давно устоявшихся.
Может и преувеличиваю, но ИМХО, по отношению к C++ они сводятся к нескольким основным принципам:
— По возможности точно следовать заданию или переспросить, если что-то неясно (+ коммуникационные навыки);
— Отслеживать и обрабатывать ошибочные ситуации (+ уверенность, что ты знаешь как работают реальные программы);
— Хорошо оформить (+ умение следовать стилю оформления, + забота о читателях);
— Не тащить в коде ничего лишнего (+ к уверенности, что ты умеешь себя ограничивать в творческих порывах);
— Следовать устоявшимся идиоматическим приёмам (+ к уверенности, что кандидат понимает, как ими пользоваться);
— Сделать автоматические тесты хотя бы по граничным значениям (+ к знанию методов тестирования).
Это что-то вроде общего знаменателя, можно сделать больше, но не стоит делать меньше. Вроде бы, ничего запредельного.
Update: Вообще, конечно, надо ещё смотреть на саму задачу. Если задача простая, то определённо, хотят посмотреть на "второстепенные" моменты. Если сложная — то скорее на ход мысли и порядок тестирования. У тебя задача относительно простая, следовательно "ход мысли" интересует в последнюю очередь.
S>Впрочем, наверное стоило бы говорить о требованиях к кандидату. Вы считате что человек, претендующий на 140к должен знать как минимум все что написано в этом топике? Имо, это все таки уровень сеньора и деньги другие. Если же Вы мне скажете, что это должен знать миддл, то я убьюсь об стенку.
Помимо комментариев и других оформительских штучек, ИМХО, самые серьёзные претензии крутились вокруг двух вещей:
— Лишние абстракции;
— Необычное использование shared_ptr.
Вроде бы, ничего сложного даже для миддла.
Я не совсем согласен с gandjustas, что здесь стоит вводить lockfree-очередь: при прочих равных она бы не помешала, но мне кажется вишенкой на торте, без которой можно и обойтись.
S>Работая над этим ТЗ я потратил большую часть времени потратил на обдумывание алгоритма, который удовлетворяет требованиям задачи так, как я их вижу. На мой взгляд алгоритм получился очень даже неплохим и реализация его вполне себе рабочая, без дедлоков, гонок и прочего безобразия. Да, много деталей можно править и улучшать и в реальной обстановке я бы не раз возвращался к этому коду с целью оптимизации и рефакторинга, причем по собственному почину. А в итоге получается, что всем плевать на алгоритм, на ход размышлений, на то, что в итоге все работает, пусть и со скрипом. Главное, что я там вместо голого указателя использовал умный и что комменты не написал.
Представь, что у тебя, например, пятеро таких кандидатов и каждый плюёт на оформление кода, но при этом ждёт, что ты расшифруешь ход его, вполне возможно, что и гениальной мысли. Почти наверняка взвоешь уже на третьем. Хрен с ними, с тестами, обрадуешься уже тому, что кто-то внятно прокомментировал код.
S>Кстати, неприятно, что в этой конторе сидят жлобы, которые даже не удосужились ответить. Подумаешь, кто-то там потратил N часов на ТЗ. Не понравилось, значит игнорим. Рашка, блин.
Согласен, если уж ты сам спрашивал о причинах непрохождения теста, могли бы и объяснить, хотя бы кратко. Высокомерно молчать — просто невежливо и уважения не добавляет.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Selavi, Вы писали:
S>Работая над этим ТЗ я потратил большую часть времени потратил на обдумывание алгоритма, который удовлетворяет требованиям задачи так, как я их вижу.
Чуть со стула не упал когда прочитал. Какая разница как ты видишь требования. Человек который не может выяснить\понять что нужно заказчику и тратит большую часть времени на "обдумывание алгоритма" вообще не должен работать программистом.
S>На мой взгляд алгоритм получился очень даже неплохим и реализация его вполне себе рабочая, без дедлоков, гонок и прочего безобразия.
А на мой взгляд ты вообще не решил исходную задачу. Там требовалось сделать вполне определенный API и оптимальную загрузку ресурсов. А у тебя лишние потоки и API не соответствует заданию. Ну и кому нужен твой алгоритм в итоге? Кроме того ты не уточнил задачу, возможно там требовался thread affinity для каждого клиента.
S>Да, много деталей можно править и улучшать и в реальной обстановке я бы не раз возвращался к этому коду с целью оптимизации и рефакторинга, причем по собственному почину. А в итоге получается, что всем плевать на алгоритм, на ход размышлений, на то, что в итоге все работает, пусть и со скрипом. Главное, что я там вместо голого указателя использовал умный и что комменты не написал.
Действительно всем плевать на алгоритм и на ход размышлений.
На что не плевать:
1) Понимание решаемой задачи
2) Точное выполнение задачи
3) Простота и понятность решения (в том числе комменты)
4) "чистый" код — без ненужных конструкций и в едином "хорошем" стиле
Ты всего этого не показал своим кодом, увы.
Из твоих сообщений понятно, что ты очень хотел сделать алгоритм вычисления наиболее ждущего клиента, а тут, гады, не оценили. Ни работодатели, ни коллеги на форуме. Обидели художника.
S>Кстати, неприятно, что в этой конторе сидят жлобы, которые даже не удосужились ответить. Подумаешь, кто-то там потратил N часов на ТЗ. Не понравилось, значит игнорим. Рашка, блин.
Ага, рашка во всем виновата и жлобы. А ты вообще на форум то зачем написал? Пожаловаться? Тогда зачем пример кода показывал? Жаловаться проще когда фактов нет.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Странная логика. И наниматель, и кандидат ищут друг в друге нечто более или менее определённое. Почему при этом именно работодатель должен старательно обходить сложные для кандидата моменты — сие неведомо. Простите, а кандидат тоже должен бояться спросить у работодателя, например, соблюдает ли тот КЗоТ? А то, вдруг не соблюдает и страшно оскорбится таким вопросом.
Я не знаю, давно ли вы меняли работу и приходили на новое место "с улицы", "по объявлению". Очень много есть гнилых контор, где люди хотят непонятно чего. Иногда, своего клона. Иногда, они вообще отсекают всех кандидатов, потому что им не нужны лишние люди, а причина отказа всегда найдется (см. анекдот: экзамен по истории — перечислите поименно всех погибших на великой отечественной)
Дано — работа, для ее выполнения требуются навыки н1..н10. У собеседующего есть навыки н6..н15, при этом от соискателя требуются по работе н1..н5 и возможно — в будущем, н16-н17, про это будущее интервьюер знает, но не помнит. По какому-то стечению обстоятельств он начинает опрашивать соискателя по тем знаниям, которые он почему-то считает более важными и это могут быть н9..н15, хотя для работы требуются именно н1..н10. Соискатель, если он займет пассивную позицию отвечающего на вопросы, может вообще не рассказать, что он знает н1..н4, н16..н17, его опросят по другой области и посчитают негодным.
Как пример — приходит человек CRUD лепить, а его зачем-то спрашивают про map-reduce, и просят выдумать алгоритм сортировки, а затем оценить его сложность, при том, что интервьюер сам занимался этим только в универе, если вообще занимался, а то ведь он может просто считать это важным, потому что Кнут! Дейкстра! Линус! SICP! Computer Science!, но применимо оно в большинстве проектов, как феррари в деревне — полюбовлся, и пошел дальше на тракторе работать. Задают мутные вопросы "что такое REST" (на это хорошим контрвопросом был бы "что такое говно" из сказок Дмитрия Гайдука), потому что интервьюера беспокоит, что их нынешний REST не канониченЪ, и он хочет найти себе единомышленника (даже если найдет, приведения к КанонуЪ все равно не состоится, потому что жизнь борьба). Еще хороший вопрос, на который невозможно ответить целиком и верно — "расскажите про протокол HTTP" (вы его диаграмму видели? а наизусть?).
Мое сообщение больше касалось именно личной беседы, а не тестового задания. В случае беседы зачастую бывает так, что от соискателя требуется быстрое решение и прямо сейчас, и верное. Но — этого ведь просто не бывает! Срочность в IT бывает только у админов (бэкап восстановить), а срочно чего-то изобрести — простите, тут не кино про хакеров, которые за 5 минут сервера ломают. Таких скорых задач нужно избегать, а если не получится, то откладывать их до того момента, когда уже сложится благоприятное впечатление. Именно поэтому, тестовое задание — хорошая мысль, если на его выполнение отводится достаточное время и возможность делать его дома в IDE, а не в офисе на бумажке. И только после беседы, а не до нее, потому что описываемые мной "местные ритуалы" проще выяснить на месте, чем потом доставать интервьюера письмами.
ГВ>И потом, то, что в этом топике сказали топикстартеру, это не какие-то специфические "ритуалы", доступные только посвящённым, а в основном банальные, уже давно устоявшиеся правила хорошего тона с небольшой поправкой на ситуацию собеседования. Естественно, все понимают, что в production-коде может царить хаос и кабакЪ, но это же не означает, что на собеседовании нужно заниматься тем же самым.
Очень многие программисты не в состоянии чего-то кому-то объяснить. С человеком поговорить, человеческим языком. Если у человека есть знания, но нет стиля, то почему бы его стилю попросту не научить? Нет, мы будем искать идеал полгода и возмущаться, что нет людей, кругом одни идиоты, мысли читать не умеют.
— Не соответствует тип возвращаемого значения (void вместо bool);
— Изменён тип входного параметра (const TaskPtr вместо CTask*);
— Нарушен стиль оформления имён параметров (clientID вместо _clientId).
Что, для того, чтобы буквально выполнить задание и скопировать прототип функции нужно развозить, извини меня, сопли на километр? Специально планировать стратегию собеседования? Копаться в тоннах мануалов? Ещё что-то?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Слава,
ГВ>О каких, к дьяволу, ритуалах и тонкой стратегии собеседования идёт речь, если в задании прямо сказано:
ГВ>
ГВ>Здесь три несоответствия на ровном месте:
ГВ>- Не соответствует тип возвращаемого значения (void вместо bool); ГВ>- Изменён тип входного параметра (const TaskPtr вместо CTask*); ГВ>- Нарушен стиль оформления имён параметров (clientID вместо _clientId).
ГВ>Что, для того, чтобы буквально выполнить задание и скопировать прототип функции нужно развозить, извини меня, сопли на километр? Специально планировать стратегию собеседования? Копаться в тоннах мануалов? Ещё что-то?
Ну хватит уже!
Придуман алгоритм и реализован корректно работающий пул потоков. Задача выполнена, пусть и не идеально.
Не нужно из простой невнимательности создавать химеру.
ГВ>Что, для того, чтобы буквально выполнить задание и скопировать прототип функции нужно развозить, извини меня, сопли на километр? Специально планировать стратегию собеседования? Копаться в тоннах мануалов? Ещё что-то?
Я его код не смотрел, но то что ты говоришь — это мелочи все. Ну и большинство-таки не может даже нормально задачу поставить. На этом форуме мне всего лишь один х64 на ум приходит который может четко изложить, что ему надо. Это из того, что я сам тут видел.
Ну и задание само так себе. Ну и сам факт что они дают задание говорит, что чуваки просто не умеют поговорить нормально на интервью.
На стороне пользователя при этом можно управлять объектами как угодно, хоть в стеке их размещать — это уже не твоё дело. Главное, что будет полная ясность с политикой владения: пул заданиями не владеет, это ответственность пользователя. А если пул принимает на вход shared_ptr, то стереотипичная интерпретация такова, что контроль ЖЦ возложен на этот указатель и никаких дополнительных копий хранить не требуется.
