Возможно, мне вскоре придется провести несколько собеседований на программиста С/С++ для ембеддинга (и не только)
Думаю, как лучше это сделать?
Пока мысли такие:
Рассказать о будущей работе, ответить на вопросы (~5-10 мин)
Спросить о прошлом опыте, если он есть — поговорить поподробней о каких-то решениях, их последствиях (~5-10 мин)
Несколько простых вопросов на знание языка (~15-20 мин):
— напишите функцию реверса строки
— чему равен размер struct {int a; char c;}
— зачем нужен volatile
—
char buf[20]={0};
*(unsigned*)(buf+5)=123456;
чем чревато, как лучше?
— #define MAX(a,b) — как написать, чем чревато?
— как написать шаблонную функцию max? Что она должна возвращать?
—
//a.cpp: struct S{ string a; int b; } sa;
//b.cpp: struct S{ int b; string a; } sb;
чем чревато? Как обойти?
— зачем нужен виртуальный деструктор? Как обойтись без него в случае, когда надо удалить объект, не зная его точного типа?
— Есть устройство, у которого могут быть разные каналы передачи данных (посл порт, tcp, twi, ...) и разные протоколы (отличаются форматом пакетов). Как бы вы спроектировали программу для него?
Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."
И оценить как работу проги (написать простой автотестер, который скормит кривые пакеты, случайный мусор, а также правильные команды и посмотрит на ответы), так и исходный код, наличие тестов, сборочного скрипта, репозитария dvcs
Здравствуйте, enji, Вы писали:
E>Рассказать о будущей работе, ответить на вопросы (~5-10 мин) E>Спросить о прошлом опыте, если он есть — поговорить поподробней о каких-то решениях, их последствиях (~5-10 мин)
Можно увеличить время до получасу-часу.
E>Несколько простых вопросов на знание языка (~15-20 мин):
Вопросы так себе, слишком простые.
E>Дать "домашнее задание" по теме работы (~2-4 часа).
Сколько вы готовы заплатить за выполнение "домашнего задания"?
Здравствуйте, enji, Вы писали:
E>Возможно, мне вскоре придется провести несколько собеседований на программиста С/С++ для ембеддинга (и не только)
E>Думаю, как лучше это сделать?
думаю тестовая задача должна быть не долгой и зависеть от того какую работу надо делать ... заодно можно посмотреть проявляет
ли человек интерес к этой области
E>>Рассказать о будущей работе, ответить на вопросы (~5-10 мин) E>>Спросить о прошлом опыте, если он есть — поговорить поподробней о каких-то решениях, их последствиях (~5-10 мин)
S>Можно увеличить время до получасу-часу.
Ну может быть , надо попробовать как пойдет. Сильно раздувать время неохота.
Да и о чем тут много говорить? Делаем тото и тото. Ты будешь заниматься вот чем-то таким. А может и чем-то другим
Рассказывать о каких-то подробностях особого смысла нет — начнет работать — узнает...
E>>Несколько простых вопросов на знание языка (~15-20 мин):
S>Вопросы так себе, слишком простые.
Забыл добавить еще пару вопросов про исключения и безопасность исключений.
А какие надо задавать? Знание всяких стл\бустов (лично у меня очень ограниченное знание и того и другого. Когда надо что-то нетривиальное — лезу в хелп) ? Алгоритмы (лично мне за последние 5 лет больше пригодился Макконел, а не Кнут)? Ромбовидное наследование (юзаю крайне редко, в основном для boost::exception)?
E>>Дать "домашнее задание" по теме работы (~2-4 часа).
S>Сколько вы готовы заплатить за выполнение "домашнего задания"?
А за что тут платить? Этот протокол давно реализован, код соискателя отправится прямиком в мусорку. Задание не слишком трудозатратное, зато позволяет посмотреть на код, который чел пишет в спокойной обстановке...
Может быть кстати дать это задание до собеседования? А на собеседовании обсудить его реализацию?
Здравствуйте, sysenter, Вы писали: S>Вопросы так себе, слишком простые.
не знаю, я бы во многих вопросах бы плавал
E>>Дать "домашнее задание" по теме работы (~2-4 часа). S>Сколько вы готовы заплатить за выполнение "домашнего задания"?
оно на один вечер — не думаю, что тут оплата имеет смысл
Здравствуйте, __kot2, Вы писали:
S>>Вопросы так себе, слишком простые. __>не знаю, я бы во многих вопросах бы плавал
У Страуструпа в белой книжке есть ответы почти на все эти вопросы, буквально на первых 100-150 страницах. Вопросы действительно простые.
НО, учитывая инфляцию кадров, я думаю вряд ли больше 10%-15% смогут на них ответить
2 enji, интересно, а на такие вопросы, примерно какая з.п. предусмотрена?
Для начала определиться, C это или C++
E>Несколько простых вопросов на знание языка (~15-20 мин):
Такого знания в природе не существует. Спрашивать надо указатели и рекурсию.
E>- напишите функцию реверса строки
Проще надо быть, проще:
1) Нарисуйте алгоритм реверса строки
2) Опишите его на псевдокоде
3) Начните писать на C
4) Достаточно
E>- чему равен размер struct {int a; char c;}
Это зависит от выравнивания, от разрядности и "pragma pack". Нечётко поставлена задача — минус собеседующему.
E>- зачем нужен volatile
Вопрос с открытым окончанием — ещё один минус собеседующему.
E>char buf[20]={0}; E>*(unsigned*)(buf+5)=123456;
"У вас что, весь код такой?"
E>- как написать шаблонную функцию max? Что она должна возвращать?
"Зачем нужен чёрный цвет? Как он должен выглядеть?"
E>чем чревато? Как обойти?
Зело чревато. Тем, что опытный специалист тихо свалит в туман и нанят не будет.
E>- зачем нужен виртуальный деструктор? Как обойтись без него в случае, когда надо удалить объект, не зная его точного типа?
Да не волнует никого ваш плохой код, честное слово... кому вы нужны, косолапые?
E>- Есть устройство, у которого могут быть разные каналы передачи данных (посл порт, tcp, twi, ...) и разные протоколы (отличаются форматом пакетов). Как бы вы спроектировали программу для него?
Да. Этот человек видит вас не только первый раз в жизни.
E>Дать "домашнее задание" по теме работы (~2-4 часа).
Но и в последний.
>К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод,
И ничего-то он вам не должен. Ничего.
E>И оценить как работу проги, так и исходный код, наличие тестов, сборочного скрипта, репозитария dvcs
www.его-личный-сайт.ru и возможно GitHub
E>Покритикуйте, плиз.
— Товарищи космонауты. Кхм. Американцы вот — на Луну. Человека. Высадили. Так мы вас — НА СОЛНЦЕ. Высадим.
— Леонид Ильич, мы же там все сгорим!!!
— А!.. Вы думаете — что? В Политбюро — м***ки сидят?! Мы вас — ночью. Кхм. Высадим.
Здравствуйте, os24ever, Вы писали:
E>>- чему равен размер struct {int a; char c;} O>Это зависит от выравнивания, от разрядности и "pragma pack". Нечётко поставлена задача — минус собеседующему.
а она и не должна быть сверх чётко поставлена, это же собеседование, в смысле разговор.
если что-то не чётко, или двусмысленно, то просто скажи про это — "зависит от компилятора/платформы, но большинстве случаях на дефолтных настройках будет X"
В том-то и дело, что не только. Код библиотек должен быть реентрабельным, чтобы несколько процессов или потоков могли войти в одну и ту же функцию одновременно. Следовательно, нельзя внутри библиотек хранить состояние. Следовательно, от "объектов" придётся отказаться.
И тогда что остаётся? Си и Паскаль. Не Фортран же.
Из этих двух языков удобнее Си: более сжатый код, указатели на функции (а значит, возможность делать сортировки и т.п. с помощью функций высшего порядка) и т.п.
E>Несколько простых вопросов на знание языка (~15-20 мин): E>- напишите функцию реверса строки E>- чему равен размер struct {int a; char c;} E>- зачем нужен volatile
Вы сами можете ответить на эти вопросы? Особенно на последний. Нет, я не про теорию, а про практику. Вы действительно хотите углубиться в обсуждение архитектур CPU, в понимание барьеров? Как мне кажется, лучше все-таки заменить этот вопрос на что-нибудь о sequence points, c какими-нибудь if (++count == 100).
E>- зачем нужен виртуальный деструктор? Как обойтись без него в случае, когда надо удалить объект, не зная его точного типа?
E>- Есть устройство, у которого могут быть разные каналы передачи данных (посл порт, tcp, twi, ...) и разные протоколы (отличаются форматом пакетов). Как бы вы спроектировали программу для него?
IMHO, это единственный осмысленный и хороший вопрос. С него надо начать, и дальше углубляться, в зависимости от того, что будет говорить собеседующий.
E>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд." E>И оценить как работу проги (написать простой автотестер, который скормит кривые пакеты, случайный мусор, а также правильные команды и посмотрит на ответы), так и исходный код, наличие тестов, сборочного скрипта, репозитария dvcs
Чтобы кто-то начал этим заниматься, вы должны предложить _ОЧЕНЬ_ хорошие условия — как минимум, существенно выше рынка зарплату. Терять день-два времени на тестовые задания — одно из бессмысленных времяпровождений. Про 2-4 часа и "наличие тестов" вы меня прямо позабавили.
Здравствуйте, SkyDance, Вы писали: __>>оно на один вечер — не думаю, что тут оплата имеет смысл SD>Это лукавство. SD>За один вечер production code с тестами не пишется.
тесты для лохов
Здравствуйте, enji, Вы писали:
E>Возможно, мне вскоре придется провести несколько собеседований на программиста С/С++ для ембеддинга (и не только)
E>Думаю, как лучше это сделать?
E>Пока мысли такие:
E>Рассказать о будущей работе, ответить на вопросы (~5-10 мин) E>Спросить о прошлом опыте, если он есть — поговорить поподробней о каких-то решениях, их последствиях (~5-10 мин)
Этого достаточно.
Если очень уж хочется посмотреть на код, то вот это ДО собеседования:
E>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."
SD>>За один вечер production code с тестами не пишется. __>тесты для лохов
ТС требует:
enji>И оценить как работу проги (написать простой автотестер, который скормит кривые пакеты, случайный мусор, а также правильные команды и посмотрит на ответы), так и исходный код, наличие тестов, сборочного скрипта, репозитария dvcs
Так что уж не обессудьте. Рискну предположить, тесты должны быть как минимум автоматическими, из серии make test.
Здравствуйте, SkyDance, Вы писали:
SD>Так что уж не обессудьте. Рискну предположить, тесты должны быть как минимум автоматическими, из серии make test.
Все это можно сделать крайне просто, если собрать в кучу CMake, CTest и, допустим, BOOST test. Хотя, даже с учетом этого, делать тестовое задание не для очень уж приглянувшейся компании не стал бы, хотят поглядеть на мой код — всегда есть репозитории на GitHub.
Здравствуйте, Piko, Вы писали:
P>У Страуструпа в белой книжке есть ответы почти на все эти вопросы, буквально на первых 100-150 страницах. Вопросы действительно простые.
Верно, позавчера очередной раз листал, со страницы 100 по 300 все ответы есть))
Здравствуйте, os24ever, Вы писали:
O>Для начала определиться, C это или C++ O>Такого знания в природе не существует.
Формально оно то так, но имеющиеся проекты написаны на смеси того и другого.
O>Спрашивать надо указатели и рекурсию.
Рекурсия имхо не сильно востребована. Указатели = реверс строки, если его на С писать.
E>>- напишите функцию реверса строки
O>Проще надо быть, проще: O>1) Нарисуйте алгоритм реверса строки O>2) Опишите его на псевдокоде O>3) Начните писать на C O>4) Достаточно
Ну хз, имхо так сложнее. Там функция из 5 строчек...
E>>- чему равен размер struct {int a; char c;} O>Это зависит от выравнивания, от разрядности и "pragma pack". Нечётко поставлена задача — минус собеседующему.
Это ж не тест. Мне интересен ответ и его обоснование, а не конкретное число.
E>>- зачем нужен volatile O>Вопрос с открытым окончанием — ещё один минус собеседующему.
Гм, что тут открыто?
E>>char buf[20]={0}; E>>*(unsigned*)(buf+5)=123456; O>"У вас что, весь код такой?"
Встречается и такое Более того, если писать (непереносимо) скажем под 8-битник, это просто и работает. Задача типичная для нас — положить число в буфер байт и выплюнуть его наружу. Как это лучше сделать и почему мой способ кривой — вполне тема для разговора
E>>- как написать шаблонную функцию max? Что она должна возвращать? O>"Зачем нужен чёрный цвет? Как он должен выглядеть?"
Не понял твоего возмущения. Если max получает однотипные аргументы — все просто. Стоит ли дать возможность получать разнотипные и что при этом она будет возвращать — вполне себе тема для разговора. Ну и базовые знания о шаблонах проверим
E>>чем чревато? Как обойти? O>Зело чревато. Тем, что опытный специалист тихо свалит в туман и нанят не будет.
Потому что не знает? Потому что так не пишет? Еще раз — это же не тест, интересны ответы...
O>www.его-личный-сайт.ru и возможно GitHub
И чего? Вот лежит там проект на 10000 строк. Как мне его оценить? Чтобы в нем разобраться, надо убить пару дней. Оно мне надо?
Как сравнить www.иванов.ru и www.петров.ru?
Если задача наша — тупой тестер выдаст число ошибок у иванова и число ошибок у петрова.
O>Да. Этот человек видит вас не только первый раз в жизни. O>Но и в последний. O>И ничего-то он вам не должен. Ничего. O>
O>— Товарищи космонауты. Кхм. Американцы вот — на Луну. Человека. Высадили. Так мы вас — НА СОЛНЦЕ. Высадим.
O>— Леонид Ильич, мы же там все сгорим!!!
O>— А!.. Вы думаете — что? В Политбюро — м***ки сидят?! Мы вас — ночью. Кхм. Высадим.
Ты вообще о чем?
Если есть чего сказать по теме — говори, буду благодарен.
Здравствуйте, enji, Вы писали:
E>>>- зачем нужен volatile O>>Вопрос с открытым окончанием — ещё один минус собеседующему. E>Гм, что тут открыто?
Найдите например статью Александреску про volatile и использование его в качестве примитива синхронизации.
E>И чего? Вот лежит там проект на 10000 строк. Как мне его оценить? Чтобы в нем разобраться, надо убить пару дней. Оно мне надо?
Это вы серьёзно? В первые минут 15 просмотра проекта всё сразу станет ясно...
Здравствуйте, enji, Вы писали:
E>А за что тут платить?
Чтобы была понятна мысль. Когда нанимаете грузчиков вы им тоже предлагаете передвинуть какой нибудь камень бесплатно или хирурга допустим тоже просите сначала вырезать апендикс кошке бесплатно с целью показать, что они могут выполнить работу? Или например когда ищете такси тоже просите водителя пару кругов проехать бесплатно, чтобы вы оценили, как он водит? А за что тут платить кошка бездомная, камень ничейный, а водителям вообще нравиться водить и пару кругов бесплатно ему только в радость проехать.
Здравствуйте, SkyDance, Вы писали:
E>>Несколько простых вопросов на знание языка (~15-20 мин): E>>- напишите функцию реверса строки E>>- чему равен размер struct {int a; char c;} E>>- зачем нужен volatile
SD>Вы сами можете ответить на эти вопросы? Особенно на последний. Нет, я не про теорию, а про практику. Вы действительно хотите углубиться в обсуждение архитектур CPU, в понимание барьеров? Как мне кажется, лучше все-таки заменить этот вопрос на что-нибудь о sequence points, c какими-нибудь if (++count == 100).
Ну как бы понимаю. По крайней мере для тех процессоров, под которые пишу. volatile отключает оптимизацию чтения и записи переменной. Нужен в случае, если переменная смаплена на специальную память (ввод-вывод скажем) или если к переменной есть обращения из разных потоков (в таком случае возможно нужны дополнительные усилия по обеспечению атомарности).
Но если мне ответят про барьеры и десктопные процы — тоже послушаю с интересом, почему нет
E>>- зачем нужен виртуальный деструктор? Как обойтись без него в случае, когда надо удалить объект, не зная его точного типа? SD>
ну простой тупой вопрос. С другой стороны — вполне себе на понимание работы С++ с памятью...
E>>- Есть устройство, у которого могут быть разные каналы передачи данных (посл порт, tcp, twi, ...) и разные протоколы (отличаются форматом пакетов). Как бы вы спроектировали программу для него? SD>IMHO, это единственный осмысленный и хороший вопрос. С него надо начать, и дальше углубляться, в зависимости от того, что будет говорить собеседующий.
Возможно, так и стоит сделать.
E>>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и
SD>Чтобы кто-то начал этим заниматься, вы должны предложить _ОЧЕНЬ_ хорошие условия — как минимум, существенно выше рынка зарплату. Терять день-два времени на тестовые задания — одно из бессмысленных времяпровождений. Про 2-4 часа и "наличие тестов" вы меня прямо позабавили.
hg init, hg commit = 5 минут
Тесты = текстовый файл, который подается на вход; эталонный текстовый файл, с которым сравнивается выход + батник, который это автоматизирует. С моим невеликим знанием бат-аники все это займет минут 15.
Описание подмножества протокола — ~5 страниц. Час на чтение и продумывание. Реализация тупая — просто стейт-машина из 5 по моему состояний. Еще час на реализацию. Отладка, красивости, тесты — еще час.
Если нет компилера — придется потратить минут 20 на скачивание и установку.
Зато на выходе получится код, который можно сравнить с кодом другого кандидата...
Здравствуйте, SkyDance, Вы писали:
__>>оно на один вечер — не думаю, что тут оплата имеет смысл
SD>Это лукавство. SD>За один вечер production code с тестами не пишется.
Про тесты ответил выше. Про продакшен-код — тут сильно упрощен ввод\вывод. Кроме того сама задача маленькая. Вполне пишется, имхо...
S>Найдите например статью Александреску про volatile и использование его в качестве примитива синхронизации.
volatile — то не только синхронизация, но еще и регистры ввода-вывода скажем...
Статью просмотрел. Не вижу противоречий с моим пониманием этого ключевого слова. Или что ты имел в виду?
S>Это вы серьёзно? В первые минут 15 просмотра проекта всё сразу станет ясно...
Возможно и да. Ок, переформулирую требования — проект на гитхабе\гуглокоде\... или домашнее задание.
Здравствуйте, sysenter, Вы писали:
S>Чтобы была понятна мысль. Когда нанимаете грузчиков вы им тоже предлагаете передвинуть какой нибудь камень бесплатно или хирурга допустим тоже просите сначала вырезать апендикс кошке бесплатно с целью показать, что они могут выполнить работу? Или например когда ищете такси тоже просите водителя пару кругов проехать бесплатно, чтобы вы оценили, как он водит?
Сравнивать программиста с грузчиком (простая и обычно разовая работа), а также с таксистом (разовая работа) не сильно корректно. Если я служба такси, то да, вероятно я попрошу таксиста сделать пару кругов перед наймом на работу.
У хирурга же обычно есть какая-то "оценка". Стаж в больнице, кол-во проведенных операций, выданные государством документы на право делать операции, хз я не разбираюсь в этом...
Лично я например не отказался бы от небольшого тестового задания. С другой стороны, чтобы не отсеять заранее ярых противников домашней неоплачиваемой работы — ок, я буду согласен на гитхаб etc.
Здравствуйте, enji, Вы писали:
E>Сравнивать программиста с грузчиком (простая и обычно разовая работа), а также с таксистом (разовая работа) не сильно корректно. Если я служба такси, то да, вероятно я попрошу таксиста сделать пару кругов перед наймом на работу.
Попробуйте попросить, потом расскажите))
E>У хирурга же обычно есть какая-то "оценка". Стаж в больнице, кол-во проведенных операций, выданные государством документы на право делать операции, хз я не разбираюсь в этом...
У программиста есть резюме в котором указаны ранее выполненные проекты часто которые можно посмотреть, так же указано какие задачи решал и чего добился, указан стаж. Всегда можно позвонить на предыдущие места работы и спросить.
E>Лично я например не отказался бы от небольшого тестового задания.
попробуйте))
E>С другой стороны, чтобы не отсеять заранее ярых противников домашней неоплачиваемой работы — ок, я буду согласен на гитхаб etc.
Не у всех на гитхабе есть проекты в свободном доступе.
Вы сами готовы предоставить свои исходники для просмотра? А то вдруг у вас там жуть и мрак, а программисту потом за ваши 40 тыр. это всё расхлёбывать?
Здравствуйте, enji, Вы писали:
E>volatile — то не только синхронизация, но еще и регистры ввода-вывода скажем...
Вы мне тут глаза открыли... на то, что я уже лет пять знаю...
E>Статью просмотрел. Не вижу противоречий с моим пониманием этого ключевого слова. Или что ты имел в виду?
Кто-то дальше понимания volatile, как указания не загружать в регистр/кеш не пошёл, а кто-то понимает что только этим volatile не ограничивается...
E>Возможно и да. Ок, переформулирую требования — проект на гитхабе\гуглокоде\... или домашнее задание.
У соискателя тоже может быть требование посмотреть ваш код, готовы предоставить?
Здравствуйте, sysenter, Вы писали:
S>У соискателя тоже может быть требование посмотреть ваш код, готовы предоставить?
По мне так ты несколько пригибаешь. Открытые исходники это одно, совершенно другое это исходники являющиеся собственностью компании. Не будешь же ты час-другой сидеть и их анализировать?
Вобщем-то замена выполнения тестового задания некими открытыми исходниками — штука вполне адекватная, на мой взгляд.
Здравствуйте, sysenter, Вы писали:
S>Не у всех на гитхабе есть проекты в свободном доступе.
Стоп. Т.е. ты против тестового задания и против гитхаба?
Резюме сложно оценить, не ясно, насколько оно соответствует реальности.
Идти по примеру Хауса и брать 40 человек, а потом их отсеивать — мне никто не даст
Таким образом сравнивать двух человек стоит по имеющемуся коду. Мне проще всего это сделать на подготовленной тестовой задаче. Но в принципе я согласен потерпеть неудобства и оценить код на публичном хостинге.
S>Вы сами готовы предоставить свои исходники для просмотра?
Смотря что понимать под предоставить? Прийти на собеседование и посмотреть — нет проблем. Выслать их программисту мылом — нет.
S>А то вдруг у вас там жуть и мрак, а программисту потом за ваши 40 тыр. это всё расхлёбывать?
Есть жуть, есть кромешная жуть, есть нормальные — все как обычно.
Здравствуйте, sysenter, Вы писали:
S>Кто-то дальше понимания volatile, как указания не загружать в регистр/кеш не пошёл, а кто-то понимает что только этим volatile не ограничивается...
А если посмотреть какой нить electronix.ru — масса вопросов, ответ на которые — "добавь volatile". Так что любые знания о нем — уже неплохо.
KP>Все это можно сделать крайне просто, если собрать в кучу CMake, CTest и, допустим, BOOST test. Хотя, даже с учетом этого, делать тестовое задание не для очень уж приглянувшейся компании не стал бы, хотят поглядеть на мой код — всегда есть репозитории на GitHub.
Гм, вот лично у меня эти 2-4 часа как раз и уйдут — скачать/обновить CMake, CTest, BOOST, создать репозиторий, структуру, файлики, сами тестовые паттерны.
Может, конечно, я и тормоз, — говнокодить быстро отвык. Ибо если начну, меня выгонят.
Здравствуйте, kaa.python, Вы писали:
KP>По мне так ты несколько пригибаешь. Открытые исходники это одно, совершенно другое это исходники являющиеся собственностью компании. Не будешь же ты час-другой сидеть и их анализировать?
Буду анализировать, хватит 15 минут — получаса.
У меня есть опыт подобного трудоустройства, знал бы что у них там внутри не пошёл бы, а на собеседование всё было ок. Сейчас хочу год досидеть, чтобы "трудовую" не портить. Всегда можно предложить подписать NDA, у меня такой опыт был, между первым и вторым собеседованиями подписал NDA.
KP>Вобщем-то замена выполнения тестового задания некими открытыми исходниками — штука вполне адекватная, на мой взгляд.
Здравствуйте, SkyDance, Вы писали:
SD>Гм, вот лично у меня эти 2-4 часа как раз и уйдут — скачать/обновить CMake, CTest, BOOST, создать репозиторий, структуру, файлики, сами тестовые паттерны. SD>Может, конечно, я и тормоз, — говнокодить быстро отвык. Ибо если начну, меня выгонят.
Ну... В принципе, у меня все это уже готовое есть, и я себе на всякий случай шпаргалку накидал
E>Ну как бы понимаю. По крайней мере для тех процессоров, под которые пишу. volatile отключает оптимизацию чтения и записи переменной. Нужен в случае, если переменная смаплена на специальную память (ввод-вывод скажем) или если к переменной есть обращения из разных потоков (в таком случае возможно нужны дополнительные усилия по обеспечению атомарности). E>Но если мне ответят про барьеры и десктопные процы — тоже послушаю с интересом, почему нет
Знаете, я не уверен, что вы готовы проводить собеседования.
Кстати, вопрос — вы вообще про какой компилятор говорите?
E>Описание подмножества протокола — ~5 страниц. Час на чтение и продумывание. Реализация тупая — просто стейт-машина из 5 по моему состояний. Еще час на реализацию. Отладка, красивости, тесты — еще час. E>Если нет компилера — придется потратить минут 20 на скачивание и установку. E>Зато на выходе получится код, который можно сравнить с кодом другого кандидата...
Попробуйте просто взять и сделать это с нуля. Сейчас. Самостоятельно. В качестве протокола возьмите, ну, скажем, EPP (есть такой XML-протокол для регистрации доменных имен). Не надо весь, просто залогиньтесь на EPP-сервер. Там как раз RFC на пару страниц, если брать только логин.
Здравствуйте, sysenter, Вы писали:
S>Это если есть открытые исходники.
Ну... Не хочу никого обидеть, но я не могу считать разработчика хорошим/стоящим разработчиком, если ему нечего показать в той или иной форме, будь то открытый код, профильные заметки, участие в публичном проекте, собственный проект в AppStore и т.п. Это довольно дико, на мой взгляд.
Здравствуйте, enji, Вы писали:
S>>Не у всех на гитхабе есть проекты в свободном доступе. E>Стоп. Т.е. ты против тестового задания и против гитхаба?
Мы против бесплатного тестового задания, любой труд должен быть оплачен.
Хочу снова повторить свои слова — не у всех на гитхабе есть проекты в свободном доступе. Т.е. может быть проект в котором человек участвует, но он ему не принадлежит и показать исходники нельзя. Вы же не хотите, чтобы в случае подобной ситуации человек показал например код написанный во время работу у вас? Полагаю нет.
E>Смотря что понимать под предоставить? Прийти на собеседование и посмотреть — нет проблем. Выслать их программисту мылом — нет.
Здравствуйте, kaa.python, Вы писали:
KP>Ну... Не хочу никого обидеть, но я не могу считать разработчика хорошим/стоящим разработчиком, если ему нечего показать в той или иной форме, будь то открытый код, профильные заметки, участие в публичном проекте, собственный проект в AppStore и т.п. Это довольно дико, на мой взгляд.
У кого может не быть времени и/или интереса делать бесплатные открытые проекты) Участие в закрытых коммерческих проектах уже не котируется?
Здравствуйте, SkyDance, Вы писали:
SD>Знаете, я не уверен, что вы готовы проводить собеседования.
Возможно, но другие не готовы еще сильнее Поэтому я и поднял эту тему — чего народ посоветует.
SD>Кстати, вопрос — вы вообще про какой компилятор говорите?
iar avr, gcc arm, msvc, mingw
SD>Попробуйте просто взять и сделать это с нуля. Сейчас. Самостоятельно. В качестве протокола возьмите, ну, скажем, EPP (есть такой XML-протокол для регистрации доменных имен). Не надо весь, просто залогиньтесь на EPP-сервер. Там как раз RFC на пару страниц, если брать только логин.
Ну смотри — ты пишешь "залогиньтесь на сервер". Для этого нужна какая-то tcp-либа или знание winapi. Нужно найти сервер для тестирования. Нужно знать XML, иметь либу для его формирования и разбора. Возможно там надо передавать не ascii. Тогда надо иметь либу для перекодировки cp1251->utf8. Если ты с этим не сталкивался — это уже займет несколько часов на установку всех либ и чтение по ним манов.
Я же предлагаю реализовать 5 страниц самодостаточного протокола, который не содержит отсылок на XML или tcp или куда-бы то ни было еще и не требует установки ничего сверх того, что есть в стандартном mingw — чтение из консоли, запись в консоль + собственный код соискателя.
Здравствуйте, sysenter, Вы писали:
S>У кого может не быть времени и/или интереса делать бесплатные открытые проекты) Участие в закрытых коммерческих проектах уже не котируется?
Исхожу исключительно из своего опыта: 99% разработчиков, которых я могу действительно назвать стоящими имеют что показать.
Здравствуйте, sysenter, Вы писали:
>Мы против бесплатного тестового задания, любой труд должен быть оплачен.
"Мы"?
Прийти на собеседование — труд. Тебе за него платят?
S>Хочу снова повторить свои слова — не у всех на гитхабе есть проекты в свободном доступе. Т.е. может быть проект в котором человек участвует, но он ему не принадлежит и показать исходники нельзя. Вы же не хотите, чтобы в случае подобной ситуации человек показал например код написанный во время работу у вас? Полагаю нет.
Смотри — например у меня нету публичных проектов, но я готов сделать задание. каа не хочет задание, зато предлагает гитхаб. Ни того, ни другого — ну тады хз. Может быть поможет увлеченный рассказ о прошлых проектах, или рекомендации от знакомых, или пачка сертификатов, или хорошие знания в нужных нам областях...
Но если приходит студент без всего этого и не хочет делать неоплачиваемое задание — наверное он пойдет лесом.
увольнять надо автора кода
E>- зачем нужен виртуальный деструктор? Как обойтись без него в случае, когда надо удалить объект, не зная его точного типа?
Это для имбедщиков? Первый вопрос банальный, второй вопрос крайне идиотический. Ну понятно, что можно сделать 50 dynamic_cast и после удачного каста сделать delete. Ответ на 100% верный, но тот кто так делает страдает легким дебилизмом.
E>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."
Здравствуйте, enji, Вы писали:
E>Здравствуйте, sysenter, Вы писали:
>>Мы против бесплатного тестового задания, любой труд должен быть оплачен. E>Прийти на собеседование — труд. Тебе за него платят?
Попробуйте ещё раз прочитать первую строчку цитирования, там сказано полностью отличное от того на что вы ответили.
Здравствуйте, Handie, Вы писали:
E>>- напишите функцию реверса строки
H>"боян" еще тот. Я писал раз десять и самое трудное в этом задании — изобразить работу мысли.
Да не надо изображать, просто напиши. Тут пробегала недавно мегатема про реверс списка вроде. Внезапно выяснилось, что для многих это чуть ли не олимпиадная задача
H>Какой скилл проверяет этот вопрос? sizeof может быть два, а может восемь.
Знание про выравнивание. Понимание, что на разных платформах оно разное.
два — это не по стандарту Разве что с особым ключом на gcc.
H>увольнять надо автора кода
Ну дык пусть соискатель напишет лучше. Не вижу проблемы.
H>Ну понятно, что можно сделать 50 dynamic_cast и после удачного каста сделать delete. Ответ на 100% верный, но тот кто так делает страдает легким дебилизмом.
Вариант с dynamic_cast вообще не рабочий — надо в точке удаления знать все возможные типы и класс должен быть виртуальным.
Я вообще-то имел в виду boost::shared_ptr или просто хранить вместе с объектом "удалятель"
H>Я бы на этом попрощался с Вашей компанией
Ну ок, собираем статистику.
30% — ханди, сисентер, os24ever — попрощался
10% — каа — предложил открытый проект
40% — я, карпентер, кот2, _AND — не против
10% — скиданс — не против, если хорошие условия
10% — THESERG — не ясно
т.е как минимум с 50-60% соискателей я найду понимание. С 30% — не найду
E>Да не надо изображать, просто напиши. Тут пробегала недавно мегатема про реверс списка вроде. Внезапно выяснилось, что для многих это чуть ли не олимпиадная задача
H>>Какой скилл проверяет этот вопрос? sizeof может быть два, а может восемь. E>Знание про выравнивание. Понимание, что на разных платформах оно разное. E>два — это не по стандарту Разве что с особым ключом на gcc.
Матчасть не знаете. Есть такие процесоры, называются DSP. в некоторых из них char == int.
И стандарт не знаете: 1 = sizeof(char) <= sizeof(short int) <= sizeof(int)...
Знак равно никогда не замечали в этом неравенстве? А есть паддинг или нет — это уж совсем мерзкий вопрос.
E>Вариант с dynamic_cast вообще не рабочий — надо в точке удаления знать все возможные типы и класс должен быть виртуальным. E>Я вообще-то имел в виду boost::shared_ptr или просто хранить вместе с объектом "удалятель"
И эти люди учат нас жить
extern BaseObject *something;
удалите something кроме как через dynamic_cast.
E>т.е как минимум с 50-60% соискателей я найду понимание. С 30% — не найду
Процент будет меньше. Во первых, больше половины народа откинется на собеседовании, из оставшихся большая часть откинется на переговорах о зарплате
Я ж не предлагал писать тебе тут Имелось в виду, что кандидат это "просто напишет"...
H>Матчасть не знаете. Есть такие процесоры, называются DSP. в некоторых из них char == int.
А, sizeof в char-ах возвращается... Да, забыл. Ну ничего страшного в этом нет, задача — проверить знания кандидата
H>extern BaseObject *something; H>удалите something кроме как через dynamic_cast.
да не вопрос
А теперь ты удали его через dynamic_cast
E>>т.е как минимум с 50-60% соискателей я найду понимание. С 30% — не найду
H>Процент будет меньше. Во первых, больше половины народа откинется на собеседовании, из оставшихся большая часть откинется на переговорах о зарплате
Ну дык мне нужен всего 1 человек... Причем адекватный
E>>>- зачем нужен volatile O>>Вопрос с открытым окончанием — ещё один минус собеседующему. E>Гм, что тут открыто?
А почему вы спрашиваете?
E>Ты вообще о чем? E>Если есть чего сказать по теме — говори, буду благодарен.
Не надо планировать заранее, кто этот человек, каким он будет, что он умеет делать и т.п.
В случае с буфером, он, может быть, использовал функции API, не вдаваясь в подробности.
В случае с кодом, да просто поискать "return" и "continue", посмотреть, где они стоят.
Здравствуйте, os24ever, Вы писали:
O>А почему вы спрашиваете?
П: А почему ты отвечаешь вопросом на вопрос?
И: Вы антисемит?
П: А почему тебя это беспокоит?
И: Нет, почему ВАС это беспокоит?
П: А кто тебе сказал, что меня это беспокоит?
И: А зачем вы спрашиваете?
...
E>Я ж не предлагал писать тебе тут Имелось в виду, что кандидат это "просто напишет"...
Я очень изображал мыслительный процесс. Здесь главное не функция, а актерское мастерство
H>>Матчасть не знаете. Есть такие процесоры, называются DSP. в некоторых из них char == int. E>А, sizeof в char-ах возвращается... Да, забыл. Ну ничего страшного в этом нет, задача — проверить знания кандидата
А если кандидат оказался умнее собеседуемого? А то некий собеседователь заявил что я дурак когда я сказал что class A{}; sizeof(A) == 1. Ну, бывает.
E>Ну дык мне нужен всего 1 человек... Причем адекватный
Нет, нужен человек готовый ради вакансии прогнуться и сделать тестовое задание дома. А у меня дочке годик и я не буду тратить субботу и воскресение на дрянные задания, я с ней в парк гулять пойду. Я дочку десять лет хотел, а вакансия в ООО "Пупкин" не стоит того
30.08.2012 23:58, enji пишет:
> Возможно, мне вскоре придется провести несколько собеседований на > программиста С/С++ для ембеддинга (и не только) > > Думаю, как лучше это сделать?
Хотелось бы тебе для начала посоветовать поставить лошадь впереди телеги.
Что ты хочешь от нового сотрудника?
31.08.2012 0:40, __kot2 пишет:
> S>Вопросы так себе, слишком простые. > не знаю, я бы во многих вопросах бы плавал
Я не так давно ради прикола сходил посмотреть на современное
собеседование (программирую на С и С++ уже 20 лет). Так вот на
простейший вопрос, то что я постоянно использую в повседневном
программинге не задумываясь уже лет 10, но поставленный в абстрактной
форме на собеседовании я ответить не смог.
Собеседования, подобные описанным выше фактически отбирают тех, кто
недавно прочитал книжки по языку и разобрался в них и все эта теория еще
не выветрилась.
31.08.2012 1:25, Piko пишет:
> У Страуструпа в белой книжке есть ответы почти на все эти вопросы, > буквально на первых 100-150 страницах.
Именно. Но в этом-то и ловушка подобных собеседований, в которую себя
загоняют работодатели, а потом плачут, что вот взяли весь такой красивый
на собеседовании, а делать нехера не хочет.
31.08.2012 10:58, enji пишет:
> H>Я бы на этом попрощался с Вашей компанией > > Ну ок, собираем статистику. > 30% — ханди, сисентер, os24ever — попрощался
Добавляй и меня сюда. Я тоже попрощаюсь. > 10% — каа — предложил открытый проект > 40% — я, карпентер, кот2, _AND — не против > 10% — скиданс — не против, если хорошие условия > 10% — THESERG — не ясно > > т.е как минимум с 50-60% соискателей я найду понимание. С 30% — не найду
Здравствуйте, Handie, Вы писали:
H>А если кандидат оказался умнее собеседуемого? А то некий собеседователь заявил что я дурак когда я сказал что class A{}; sizeof(A) == 1. Ну, бывает.
Да не проблема. Я буду только рад, честно А кто неправ в непонятной ситуации — компилятор рядом, несложно проверить...
E>>Ну дык мне нужен всего 1 человек... Причем адекватный
H>Нет, нужен человек готовый ради вакансии прогнуться и сделать тестовое задание дома. А у меня дочке годик и я не буду тратить субботу и воскресение на дрянные задания, я с ней в парк гулять пойду. Я дочку десять лет хотел, а вакансия в ООО "Пупкин" не стоит того
Ты передергиваешь. Мое задание весит часа 4 максимум — это вечер.
К тому ж я уже согласился на гитхаб. Если ты не готов ни на то, ни на другое и у тебя нет каких-то особенных скилов — ну что ж, не судьба...
Здравствуйте, Vzhyk, Вы писали:
>> Ну ок, собираем статистику. >> 30% — ханди, сисентер, os24ever — попрощался V>Добавляй и меня сюда. Я тоже попрощаюсь. >> 10% — каа — предложил открытый проект >> 40% — я, карпентер, кот2, _AND — не против
Я кстати тоже не против, только значение имеют не условия работодателя, а интересность задания. Очередной переворачиватель строки делать, уж извольте нет. А вот чего нить такое чего даже и делать как не понятно, это всегда пожалуйста.
Здравствуйте, Vzhyk, Вы писали:
>> Ну дык мне нужен всего 1 человек... Причем адекватный V>Чему? В этом весь вопрос.
Ну вестимо нашей фирме и нашим задачам.
Я вот пока не понял, в чем смысл твоих вопросов?
Здравствуйте, Vzhyk, Вы писали:
V>Я не так давно ради прикола сходил посмотреть на современное V>собеседование (программирую на С и С++ уже 20 лет). Так вот на V>простейший вопрос, то что я постоянно использую в повседневном V>программинге не задумываясь уже лет 10, но поставленный в абстрактной V>форме на собеседовании я ответить не смог.
if, switch, функции, классы — не? или в чем вопрос-то?
V>Собеседования, подобные описанным выше фактически отбирают тех, кто V>недавно прочитал книжки по языку и разобрался в них и все эта теория еще V>не выветрилась.
Ну хз, вопросы вроде как тривиальные. И вполне жизненные. Я чтобы их сформулировать, в книжку не лез. Просто взял несколько тем по памяти...
А чего спрашивать? Про круглые люки и гномиков — какой-то маразм. Вообще не спрашивать про язык? Ну дык ты ж на нем пишешь, тривиальные вещи должен знать.
31.08.2012 12:39, enji пишет:
> Поддержки имеющихся проектов, их улучшения, работы над новыми. > > Собственно чем мой ответ тебе помог? имхо, все хотят от сотрудников > примерно такого....
Мне ничем, ты же совета спрашиваешь. А твой ответ говорит только о том,
что ты не знаешь, что именно тебе нужно от нового сотрудника. А пример
применения такого подхода вот: http://rsdn.ru/forum/message/4870693.aspx
Здравствуйте, Vzhyk, Вы писали:
V>А твой ответ говорит только о том, V>что ты не знаешь, что именно тебе нужно от нового сотрудника.
Гм, сильное заявление. А что по твоему ответит тот, кто знает об этом?
V> А пример V>применения такого подхода вот: http://rsdn.ru/forum/message/4870693.aspx
Тему проглядел, к чему ты на нее ссылаешься — не понял. Наняли чуваков, которые пахали на испытательном, а потом обленились? Поговорить, если не работает — уволить. Проблем не вижу...
31.08.2012 12:41, enji пишет:
> Ну вестимо нашей фирме и нашим задачам.
Адекватным вашим задачам — это перл.
> Я вот пока не понял, в чем смысл твоих вопросов?
В том, чтобы ты сначала осознал четко, какие именно требования ты
предъявляешь к новому сотруднику, а затем уже выяснял, удовлетворяют ли
соискатели твоим требованиям ну и также осознавал, насколько твои
требования соответсвуют вашей деятельности. Главное, что требования ты
должен (себе) сформулировать точно и четко и так, чтобы их можно было
проверить.
Здравствуйте, Vzhyk, Вы писали:
>> Я вот пока не понял, в чем смысл твоих вопросов? V>В том, чтобы ты сначала осознал четко, какие именно требования ты V>предъявляешь к новому сотруднику, а затем уже выяснял, удовлетворяют ли V>соискатели твоим требованиям ну и также осознавал, насколько твои V>требования соответсвуют вашей деятельности. Главное, что требования ты V>должен (себе) сформулировать точно и четко и так, чтобы их можно было V>проверить.
О великий гуру! Расскажи же мне, чем плохи мои требования?
На всякий случай их тут повторяю:
— знание С, C++ — обязательно
приветствуются
— опыт работы
— знание наших процессоров
— умение читать принципиальные схемы
— знания в нашей прикладной области
Собеседование ставит своей целью проверить пункт номер 1 и выяснить, что получается по остальным пунктам. Пункты 1 и 2 важны, поэтому хочется посмотреть на код, который выдает соискатель.
31.08.2012 12:46, enji пишет:
>или в чем вопрос-то?
Это не вопрос. Это так пример к сведению.
> А чего спрашивать? Про круглые люки и гномиков — какой-то маразм. Вообще > не спрашивать про язык? Ну дык ты ж на нем пишешь, тривиальные вещи > должен знать.
Ну когда я ищу человека, я ищу в первую очередь того, кто будет работать
и изучать то, что нужно по дальнейшей работе. Для этого беседа о его
прошлой работе, что именно он делал и как, как решал различные
сложности. В общем беседа. А вот непосредственно С, C++, если есть 2-3
года коммерческого программирования мне достаточно. Если у меня есть
неуверенность в его опыте С++, предлагаю набросать класс vector, как он
его видит.
Да, для те, у кого опыта меньше 2 лет, тест на дом.
Здравствуйте, Vzhyk, Вы писали:
V>Ну когда я ищу человека, я ищу в первую очередь того, кто будет работать V>и изучать то, что нужно по дальнейшей работе. Для этого беседа о его V>прошлой работе, что именно он делал и как, как решал различные V>сложности. В общем беседа.
Ок, ясно, спасибо.
V>А вот непосредственно С, C++, если есть 2-3 V>года коммерческого программирования мне достаточно.
Вот тут не согласен. Был у нас чувак, который несколько лет писал вполне себе коммерческий код. Но как потом внезапно оказалось после его увольнения — совершенно не поддерживаемую копи-пасту.
Так что на код хотелось бы посмотреть, даже с 3 годами опыта...
E>Несколько простых вопросов на знание языка (~15-20 мин):
В виде кода, но не энциклопедических знаний. Это обязательно. Собственно это и есть самое главное. Ну кроме личных качеств.
E>- напишите функцию реверса строки E>- чему равен размер struct {int a; char c;} E>- зачем нужен volatile E>-
В таком виде лучше не надо. Разве что для проверки тех самых личных качеств. Хорошему программеру надо задавать вопрос с челленджем. Пусть маленьким, но челленджем. К тому же все мужики независимо от возраста дети, и любят играть и соревноваться.
E>- Есть устройство, у которого могут быть разные каналы передачи данных (посл порт, tcp, twi, ...) и разные протоколы (отличаются форматом пакетов). Как бы вы спроектировали программу для него?
От это уже неплохо. Но стоит добавить изюминку. Просто что бы была точка опоры и какая-то сложность.
E>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."
Бессмысленно. Лучше просить показать собственные наработки. Или просто любимые приёмы. Вам нужен человек который за всю свою карьеру ничего под себя не создал?!
E>И оценить как работу проги (написать простой автотестер, который скормит кривые пакеты, случайный мусор, а также правильные команды и посмотрит на ответы), так и исходный код, наличие тестов, сборочного скрипта, репозитария dvcs
От это тоже хорошо. Здесь с одной стороны есть фактура с которой работать и человеку проще начать, с другой умение читать и понимать, даже важнее умения писать. Написать то может любой, а вот прочитать, понять, и переделать с учётом изменившихся требований — далеко не каждый.
> Гм, сильное заявление. А что по твоему ответит тот, кто знает об этом?
Твои требования должны быть четко сформулированы тобой и проверяемы.
А не хочу сказать, что это плохо, проверять знания, если именно это ваши
требования и именно это вам и нужно.
То есть фактически. Твое требование (по первому посту): "Нам нужны
программисты с такими-то знаниями и не более" — и это ты и проверяешь.
Нюанс в том, что именно такое требование чрезвычайная редкость и даже с
твоим нечетким высказыванием выше это требование слабо согласуется.
> Тему проглядел, к чему ты на нее ссылаешься — не понял. Наняли чуваков, > которые пахали на испытательном, а потом обленились? Поговорить, если не > работает — уволить. Проблем не вижу...
У ТС большие проблемы с этим. Как понятно было из обсуждения — у них
такая ситуация типична.
31.08.2012 13:05, enji пишет:
> На всякий случай их тут повторяю: > — знание С, C++ — обязательно
Тогда полноценный экзамен самое логичное и правильное.
Но будут ли эти люди работать? Фактически основной вопрос, который ты
боишься поставить, но именно ответ на него тебе и нужен, вероятнее
всего. (немножко потелепал)
Здравствуйте, Vzhyk, Вы писали:
V>31.08.2012 13:05, enji пишет:
>> На всякий случай их тут повторяю: >> — знание С, C++ — обязательно V>Тогда полноценный экзамен самое логичное и правильное.
ИМХО, ты передергиваешь — вопросы из первого поста не являются экзаменом на С++. Просто несколько вопросов, чтобы оценить знания кандидата.
V>Но будут ли эти люди работать? Фактически основной вопрос, который ты V>боишься поставить, но именно ответ на него тебе и нужен, вероятнее V>всего. (немножко потелепал)
Оно то конечно так, но брать человека, который будет работать, но не знает С/С++ — как то страшновато. Сможет ли он освоить язык за разумный срок? Хз.
Брать человека, который язык знает, но генерит жуткий код — тож не охота. Если он уволится — мне же за ним подтирать. Отсюда идея про тестовое задание/открытый проект.
Будет ли работать тот, кто знает язык и нормально пишет — ну тоже хз. Однако если он "адекватен" — то будет, иначе накой он пришел на собеседование?
31.08.2012 13:14, enji пишет:
> V>А вот непосредственно С, C++, если есть 2-3 > V>года коммерческого программирования мне достаточно. > Вот тут не согласен. Был у нас чувак, который несколько лет писал вполне > себе коммерческий код. Но как потом внезапно оказалось после его > увольнения — совершенно не поддерживаемую копи-пасту.
Не понимаю, как такое может быть? Так или иначе код любого программиста
известен его начальнику. Либо человек пишет код так, как у нас принято,
либо увольняется.
Понятно, что каждый человек пишет код со своими особенностями, но проект
всегда разбит на модули, а модули на более мелкие модули, все модули
покрыты тестами. В итоге, если какой молодой наваял какую фигню в
течение 1 месяца (чаще все видно уже за 1-2 недели), достаточно
безболезненно все починить.
Как пример, один очень серьезный проект, был сделан фактически силами
студентов и двух "старичков", проект уже живет 7 лет и развивается и не
собирается умирать.
> Так что на код хотелось бы посмотреть, даже с 3 годами опыта...
"Обжегшись на молоке..."
31.08.2012 13:18, Alexéy Sudachén пишет:
> От это уже неплохо. Но стоит добавить изюминку. Просто что бы была точка > опоры и какая-то сложность.
По мне и так нормально, но нужно больше детализации в постановке задачи,
а то тянет на вариант: "угадайте, что мы хотим".
> Бессмысленно. Лучше просить показать собственные наработки. Или просто > любимые приёмы. Вам нужен человек который за всю свою карьеру ничего под > себя не создал?!
Только желательно предупреждать человека заранее об этом и в стиле дать
возможность человеку похвастаться.
Здравствуйте, Vzhyk, Вы писали:
V>Не понимаю, как такое может быть? Так или иначе код любого программиста V>известен его начальнику. Либо человек пишет код так, как у нас принято, V>либо увольняется.
Ну как тебе сказать. В идеале ты прав. Однако народа у нас в то время было мало, начальник был вообще не программистом и интересовала его функциональность, а не код.
В результате мы имеем:
V>Понятно, что каждый человек пишет код со своими особенностями, но проект V>всегда разбит на модули, а модули на более мелкие модули, все модули V>покрыты тестами.
Опять таки, в идеале ты прав. Я тож так считаю и потихоньку мы движемся в этом направлении. Но даже сейчас мы далеки от светлого будущего
>> Так что на код хотелось бы посмотреть, даже с 3 годами опыта... V>"Обжегшись на молоке..."
Возможно, но как еще определить? Брать и изгонять через месяц — имхо хуже...
Здравствуйте, enji, Вы писали:
E>- напишите функцию реверса строки
std::reverse.
если кандидат может ответить на остальные вопросы — строку он как-то развернет наверное
E>- чему равен размер struct {int a; char c;}
sizeof(T)
E>- зачем нужен volatile
хороший вопрос. очевидно затем чтобы передать переменную библиотечным функциям которые требуют volatile аргументы
или Вы про volatile у методов? даже хз
E>*(unsigned*)(buf+5)=123456;
вы уже уволили того кто так написал?
E>- #define MAX(a,b) — как написать, чем чревато?
макросы вместо функций? никак не писать.
E>- как написать шаблонную функцию max? Что она должна возвращать?
decltype(a > b ? a : b) , что же еще?
E>
E>//a.cpp:
E>struct S{ string a; int b; } sa;
E>//b.cpp:
E>struct S{ int b; string a; } sb;
E>
E>чем чревато? Как обойти?
тут только одна проблема — using namespace std;
E>- зачем нужен виртуальный деструктор? Как обойтись без него в случае, когда надо удалить объект, не зная его точного типа?
действительно хорошй вопрос. тут можно о многом поговорить (типа интерфейсы vs абстрактные классы)
E>- Есть устройство, у которого могут быть разные каналы передачи данных (посл порт, tcp, twi, ...) и разные протоколы (отличаются форматом пакетов). Как бы вы спроектировали программу для него?
какую программу? `int main() {}` за программу считается?
общем эти вопросы вызывот только недоумение со стороны адекватных кандидатов
E>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."
непонятно что можно оценить по программе в 200 строк.
задачу в такой постановке можно решить сотней способов, и многие из них субъективно покажутся "неправильными" — "много Си"/"много С++"/"выглядит как Java"
"возможность добавления новых команд" — это плохое условие, не указано сколько будет команд и насколько они сложные, в зависимости от этого решение может быть очень разным.
E>И оценить как работу проги (написать простой автотестер, который скормит кривые пакеты, случайный мусор, а также правильные команды и посмотрит на ответы), так и исходный код, наличие тестов,
всмысле "написать простой автотестер"? есть же готовые фреймворки
E>сборочного скрипта,
чего-чего? .sln чтоли? E>репозитария dvcs
для задачи которая делается за 1 коммит (1 час), репозиторий не нужен
Здравствуйте, Abyx, Вы писали:
A>если кандидат может ответить на остальные вопросы — строку он как-то развернет наверное
ок, выкидаем
E>>- чему равен размер struct {int a; char c;} A>sizeof(T)
встречный вопрос кандидату, чему будет равен этот sizeof, от чего это зависит.
E>>- зачем нужен volatile A>хороший вопрос. очевидно затем чтобы передать переменную библиотечным функциям которые требуют volatile аргументы
Странный ответ. Но если ответит так — спрошу про ввод\вывод или многопоточность...
E>>*(unsigned*)(buf+5)=123456; A>вы уже уволили того кто так написал?
встречный вопрос — почему его надо уволить?
E>>- #define MAX(a,b) — как написать, чем чревато? A>макросы вместо функций? никак не писать.
встречный вопрос — а если очень надо? Нет constexpr скажем...
E>>- как написать шаблонную функцию max? Что она должна возвращать? A>decltype(a > b ? a : b) , что же еще?
встречный вопрос — а если нет с++11?
A>тут только одна проблема — using namespace std;
на самом деле нет — нарушено ODR — будет ub и скорее всего вылет в дебаге...
E>>- Есть устройство, у которого могут быть разные каналы передачи данных (посл порт, tcp, twi, ...) и разные протоколы (отличаются форматом пакетов). Как бы вы спроектировали программу для него? A>какую программу? `int main() {}` за программу считается?
встречный вопрос — да, но когда ты научишь программу принимать команды — как сделать заменяемость каналов и протоколов7
A>общем эти вопросы вызывот только недоумение со стороны адекватных кандидатов
Ок, предложи более лучшие
A>непонятно что можно оценить по программе в 200 строк.
Ну например корректность ее работы. Подозреваю что там будет не 200 строк, а побольше все ж таки A>задачу в такой постановке можно решить сотней способов, и многие из них субъективно покажутся "неправильными" — "много Си"/"много С++"/"выглядит как Java"
Да фиг с ним — главное чтобы она работала, была понятна окружающим и позволяла легко расширить себя. A>"возможность добавления новых команд" — это плохое условие, не указано сколько будет команд и насколько они сложные, в зависимости от этого решение может быть очень разным.
А как иначе? Вот мне говорят — сделай такую-то функциональность. И все. Но завтра могут прийти и сказать сделать еще что-то. Я что скажу — идите лесом, вы вчера дали мне неверное задание? Приходится включать телепалку...
E>>И оценить как работу проги (написать простой автотестер, который скормит кривые пакеты, случайный мусор, а также правильные команды и посмотрит на ответы), так и исходный код, наличие тестов, A>всмысле "написать простой автотестер"? есть же готовые фреймворки
Для чего? Чтоб сравнить два файла?
E>>репозитария dvcs A>для задачи которая делается за 1 коммит (1 час), репозиторий не нужен
Я ж намекнул про расширение. Не нужен — ну поговорим, почему не нужен...
Про прошлые вопросы я уже все сказал, да и тут не раз уже их перетирали.
> Однако если он "адекватен" — то будет, иначе накой он пришел на > собеседование?
Да на вас посмотреть.
Здравствуйте, enji, Вы писали:
E>>>- чему равен размер struct {int a; char c;} A>>sizeof(T) E>встречный вопрос кандидату, чему будет равен этот sizeof, от чего это зависит.
тогда лучше сразу спросить от чего зависит,
или *как рассчитывается* — max(sizeof(int), default_align) + default_align (хотя хз чем это знать IRL)
E>>>- зачем нужен volatile A>>хороший вопрос. очевидно затем чтобы передать переменную библиотечным функциям которые требуют volatile аргументы E>Странный ответ. Но если ответит так — спрошу про ввод\вывод или многопоточность...
для атомарности — есть <atomic>,
а volatile, это так, вспомогательное средство чтоб гарантировать что в памяти всегда лежит самое свежее значение переменной, при помощи которого можно написать atomic типы
E>>>*(unsigned*)(buf+5)=123456; A>>вы уже уволили того кто так написал? E>встречный вопрос — почему его надо уволить?
за char[] и магическое число 5 вместо структуры с читабельным названием и именами полей
E>>>- #define MAX(a,b) — как написать, чем чревато? A>>макросы вместо функций? никак не писать. E>встречный вопрос — а если очень надо? Нет constexpr скажем...
очень надо бывает так редко, что можно и ?: обойтись
E>>>- как написать шаблонную функцию max? Что она должна возвращать? A>>decltype(a > b ? a : b) , что же еще? E>встречный вопрос — а если нет с++11?
а это звоночек
впрочем "Что она должна возвращать" зависит от того что мы хотим чтобы она возвращала.
это религиозный вопрос — разрешать возврат T& или ограничиться только const T& (ну и volatile не забыть)
хотя обсуждение религиозных вопросов это хорошо, потом не будете сожалеть что коллега пишет x.get() = 42;
A>>тут только одна проблема — using namespace std; E>на самом деле нет — нарушено ODR — будет ub и скорее всего вылет в дебаге...
да, действительно, там же нетривиальный конструктор/деструктор
E>>>- Есть устройство, у которого могут быть разные каналы передачи данных (посл порт, tcp, twi, ...) и разные протоколы (отличаются форматом пакетов). Как бы вы спроектировали программу для него? A>>какую программу? `int main() {}` за программу считается? E>встречный вопрос — да, но когда ты научишь программу принимать команды — как сделать заменяемость каналов и протоколов7
т.е. вопрос в том как спроектировать фреймворк для передачи данных по разным протоколам? ответ сильно зависит от структуры пакетов и требований по производительности.
это может быть либо AbstractDeviceFacade+AbstractXXXFacade с виртальными методами на каждый пакет, либо свободные функции и структуры на каждый пакет — вариантов много
A>>"возможность добавления новых команд" — это плохое условие, не указано сколько будет команд и насколько они сложные, в зависимости от этого решение может быть очень разным. E>А как иначе? Вот мне говорят — сделай такую-то функциональность. И все. Но завтра могут прийти и сказать сделать еще что-то.
однако обычно говорят что это либо "сейчас поддержать 5 пакетов, а завтра еще 500", или "сейчас 5 пакетов, а потом по 1-2 в месяц"
расширять можно по-разному
E>>>И оценить как работу проги (написать простой автотестер, который скормит кривые пакеты, случайный мусор, а также правильные команды и посмотрит на ответы), так и исходный код, наличие тестов, A>>всмысле "написать простой автотестер"? есть же готовые фреймворки E>Для чего? Чтоб сравнить два файла?
если у программы есть состояние, 1 большого теста мало, надо делать кучу тестов и в каждом сбрасывать состояние,
а то может получиться что программа работает только на одной начальной последовательности пакетов
A>>общем эти вопросы вызывот только недоумение со стороны адекватных кандидатов E>Ок, предложи более лучшие
я бы вообще не задавал вопросов, а дал бы несколько больших кусков какогонить опенсорсного кода, и сказал бы сделать им "ревью" — рассказать что в этом коде хорошо, а что плохо
Здравствуйте, SkyDance, Вы писали:
SD>Вы сами можете ответить на эти вопросы? Особенно на последний. Нет, я не про теорию, а про практику. Вы действительно хотите углубиться в обсуждение архитектур CPU, в понимание барьеров? Как мне кажется, лучше все-таки заменить этот вопрос на что-нибудь о sequence points, c какими-нибудь if (++count == 100).
не относящийся к теме вопрос. Какое отношение в c/c++ volatile имеет к барьерам? Оно же, вроде как, просто оптимизации на уровне компилятора запрещает? Спрашиваю, потому, что реально не знаю и интересно, что знающие люди скажут.
Здравствуйте, Abyx, Вы писали:
A>тогда лучше сразу спросить от чего зависит, A>или *как рассчитывается* — max(sizeof(int), default_align) + default_align (хотя хз чем это знать IRL)
Как рассчитывается — мне по фигу. Интересно, знает ли соискатель о выравнивании, о том что на разных платформах размер будет разным...
A>для атомарности — есть <atomic>,
только в c++11 A>а volatile, это так, вспомогательное средство чтоб гарантировать что в памяти всегда лежит самое свежее значение переменной, при помощи которого можно написать atomic типы
а при чем тут вообще атомик? В эмбеддинге через volatile обычно регистры ввода-вывода объявляют...
E>>>>*(unsigned*)(buf+5)=123456; A>>>вы уже уволили того кто так написал? E>>встречный вопрос — почему его надо уволить? A>за char[] и магическое число 5 вместо структуры с читабельным названием и именами полей
Насчет char[] — не соглашусь. Если выплевывать этот буфер наружу — проще char с вполне четким расположением в памяти, чем структура, с которой надо обращаться крайне аккуратно и окружать прагмами.
А вообще то на таком коде можно схватить аппаратное исключение из-за невыровненного доступа...
E>>встречный вопрос — а если нет с++11? A>а это звоночек
Вполне нормальная ситуация. Кто ж обновит сильно платный компилер ради с++11
A>т.е. вопрос в том как спроектировать фреймворк для передачи данных по разным протоколам? ответ сильно зависит от структуры пакетов и требований по производительности. A>это может быть либо AbstractDeviceFacade+AbstractXXXFacade с виртальными методами на каждый пакет, либо свободные функции и структуры на каждый пакет — вариантов много
Вполне себе тема для обсуждения...
A>я бы вообще не задавал вопросов, а дал бы несколько больших кусков какогонить опенсорсного кода, и сказал бы сделать им "ревью" — рассказать что в этом коде хорошо, а что плохо
Здравствуйте, Vzhyk, Вы писали:
>> У Страуструпа в белой книжке есть ответы почти на все эти вопросы, >> буквально на первых 100-150 страницах. V>Именно. Но в этом-то и ловушка подобных собеседований, в которую себя V>загоняют работодатели, а потом плачут, что вот взяли весь такой красивый V>на собеседовании, а делать нехера не хочет.
так базу в любом случае нужно знать
для embeded C++ вопросы абсолютно адекватные, и очень простые. если человек этого не знает, то вряд ли он подойдёт даже на должность "делать нехера не хочет"
Здравствуйте, enji, Вы писали:
E>Здравствуйте, Abyx, Вы писали:
A>>если кандидат может ответить на остальные вопросы — строку он как-то развернет наверное E>ок, выкидаем
не надо выкидывать, маленький алгоритм всё равно нужно давать.
программисты должны уметь их писать. если не умеют писать маленькие алгоритмы(например как этот http://www.rsdn.ru/forum/job/4875854.1.aspx
31.08.2012 17:17, Piko пишет:
> так базу в любом случае нужно знать
Надо. Но это лучше выяснить, беседуя с человеком о том, что именно он и
как делал.
> для embeded C++ вопросы абсолютно адекватные, и очень простые. если > человек этого не знает, то вряд ли он подойдёт даже на должность "делать > нехера не хочет"
Вопросы выше, скажем так, скользкие в массе своей. И самого то главного
и не выясняют, будет ли человек работать.
Но, если не важна работа, то годится. Но, каждый ССЗБ .
Здравствуйте, enji, Вы писали:
E>>>>>*(unsigned*)(buf+5)=123456; A>>>>вы уже уволили того кто так написал? E>>>встречный вопрос — почему его надо уволить? A>>за char[] и магическое число 5 вместо структуры с читабельным названием и именами полей E>Насчет char[] — не соглашусь. Если выплевывать этот буфер наружу — проще char с вполне четким расположением в памяти, чем структура, с которой надо обращаться крайне аккуратно и окружать прагмами.
не понял насчет расположения в памяти. типа явное смещение 5 лучще чем структура?
так если хочется чтобы в коде было явное число 5, то лучше юзать структуру, и написать static_assert(offsetof(Foo, bar) == 5, "invalid offset");
E>А вообще то на таком коде можно схватить аппаратное исключение из-за невыровненного доступа...
а была бы структура — компилятор увидел бы невыровненное смещение, и сгенерил бы нужный код
хотя мне почему-то кажется что и в случае с buf+5 компилятор должен увидеть смещение. зависит от компилятора конечно.
Здравствуйте, Vzhyk, Вы писали:
>> так базу в любом случае нужно знать V>Надо. Но это лучше выяснить, беседуя с человеком о том, что именно он и V>как делал.
эээ. то есть ты ожидаешь, что беседуя с человеком он вдруг начнёт говорить про базу? То есть друг ни с того ни с сего про алигмент, паддинг и волатиль?
Не легче (для выяснения знания базы) ли на прямую задать несколько вопросов, которые обязан знать каждый пришедший на это собеседование? (беседу это не отменяет)
>> для embeded C++ вопросы абсолютно адекватные, и очень простые. если >> человек этого не знает, то вряд ли он подойдёт даже на должность "делать >> нехера не хочет" V>Вопросы выше, скажем так, скользкие в массе своей. И самого то главного V>и не выясняют, будет ли человек работать.
ещё раз, эти несколько вопросов прощупывают знание базы (обязательной!), не более не менее
V>Но, если не важна работа, то годится. Но, каждый ССЗБ .
кто сказал что не важна?
ты думаешь топикстартер даже не собирался беседовать с кандидатом?
lol
Здравствуйте, enji, Вы писали:
E>Ну ок, собираем статистику. E>30% — ханди, сисентер, os24ever — попрощался
Меня тоже добавляй. Попросить примеры кода — ещё нормально. Любого, если говорит что нету — можно попросить набросать пример и предложить в качестве тематики то, что ты предлагаешь в виде тестового задания.
E>т.е как минимум с 50-60% соискателей я найду понимание. С 30% — не найду
ИМХО тестовое задание стоит сделать в трёх случаях: много свободного времени, интересное задание и очень хочется попасть в именно эту контору.
Не сишник, но если интересно, могу высказать свое ИМХО.
E>Рассказать о будущей работе, ответить на вопросы (~5-10 мин) E>Спросить о прошлом опыте, если он есть — поговорить поподробней о каких-то решениях, их последствиях (~5-10 мин)
Я бы не стал четко определять время на это. Пункты выше — самое главное в собеседовании. Им стоит уделить максимум внимания. В разговоре лучше всего виден уровень знаний и способность думать.
А вот дальше я бы, как минимум, разделил примерный ход собеседования на минимум 2 градации: начинающий, но толковый(бестолкового уже можно провожать), или опытный. Потому как вопросы ниже вызовут зевоту у опытного.
Ну и по самим вопросам:
E>Несколько простых вопросов на знание языка (~15-20 мин): E>- напишите функцию реверса строки
[зевает]
E>- чему равен размер struct {int a; char c;}
Может у некоторых вызвать подозрение собеседующего в некомпетенции(я же надеюсь, вы не скажете, что на этот вопрос есть точный ответ?).
E>- зачем нужен volatile
Вопрос скорее опытному. Ну, в двух словах оно понятно, но есть нюансы.
Студент может и про потоки толком ничего не знать, но это не значит, что он плох сам по себе.
E>- E>
Доктор, а откуда у вас такие картинки? Уж не придется ли мне это говно на работе разгребать?
E>- #define MAX(a,b) — как написать, чем чревато?
Дефайны для всего, кроме констант — фтопку. Именно из-за вот таких возможных побочных эффектов.
E>- зачем нужен виртуальный деструктор? Как обойтись без него в случае, когда надо удалить объект, не зная его точного типа?
Про второй вопрос — хз, много лет на плюсах не писал. Но его постановка отчего-то сильно попахивает вариантом, что тут все криво, и вообще говнокодом.
E>- Есть устройство, у которого могут быть разные каналы передачи данных (посл порт, tcp, twi, ...) и разные протоколы (отличаются форматом пакетов). Как бы вы спроектировали программу для него?
Норм.
E>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд." E>И оценить как работу проги (написать простой автотестер, который скормит кривые пакеты, случайный мусор, а также правильные команды и посмотрит на ответы), так и исходный код, наличие тестов, сборочного скрипта, репозитария dvcs
Несмотря на то, что задание вроде бы и несложное(я надеюсь, протокол-то хоть простой? А то бывают и многоуровневые с хитрым шифрованием, проверкой целостности и нетривиальными алгоритмами обработки ошибок для возвращения в рабочее состояние, это уже не лезет ни в какие ворота), я бы отказался писать. Мне даже банально влом было бы дома настраивать девелоперское окружение(это иногда занимает совершенно не то время, которое ожидается
). Ну и вообще, задачка похожа уж сильно на реальную . Как бы я это сделал, на словах бы рассказал. А писать — нене, у меня в графике таких как вы много, и тестовые нужны одной конторе из 10 в лучшем случае. Хотя не знаю, как у вас там в городе дела обстоят.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, enji, Вы писали:
E>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."
Плохая задача. Она очень муторная в обработке ошибок. Различные обрывы (и восстановления) связи с устройством, расхождения в контрольной сумме и прочие радости. Включая необходимость переотправки в некоторых случаях пакета с хоста (по таймауту).
Выделенное особенно плохо. Откуда вы такое вообще берете? Правильным в данном случае будет жестко закодировать обработку этих ваших 4-5 команд в код. Добавление новых команд делается либо типичными кейсами теми же (если случаи простые). Либо написанием нормальной инфраструктуры тогда, когда она понадобится (а мало ли, там на какую-то команду потребуется совсем другой обмен, например). Какие-то куски будут использованы из начального решения, но общая архитектура может сильно поменяться. Нужно хотя бы десяток команд. Лучше — десятка полтора-два. И из разных "аспектов" работы устройства. На практике обычно известно, что за устройство используется, и можно предполагать, что оно умеет делать. А также можно предполагать, что оно точно не умеет делать, и это не менее важно! И если вы хотите увидеть здесь стратегии — вы можете их не увидеть. Решение с простейшим case/if'ами тоже прекрасно поддерживается и сопровождается. А вот со стратегиями могут быть сложности (например, найти, где они инициализируются и т.п.). Нет, они тоже могут быть, но нужно понимать, с какой именно целью и куда они добавляются.
Здравствуйте, Abyx, Вы писали:
E>>Насчет char[] — не соглашусь. Если выплевывать этот буфер наружу — проще char с вполне четким расположением в памяти, чем структура, с которой надо обращаться крайне аккуратно и окружать прагмами. A>не понял насчет расположения в памяти. типа явное смещение 5 лучще чем структура?
Да, иногда лучше. В массиве char[] четко видно смещение 5. В структуре его не видно — надо складывать размеры всех предыдущих членов. Структуру надо окружать прагмами. Кроме того, есть bigendian, что добавляет гемора со структурами. Еще есть битовые поля — надо помнить правила их расположения, они кстати тоже зависят от big/little-endian
Также некоторые части пакета могут быть с нефиксированной длиной. Я даже не знаю, как это выразить структурой...
Мое решение — если мест формирования таких пакетов много — написать что-то вроде
Здравствуйте, Трололоша, Вы писали:
Т>Здравствуйте, enji, Вы писали:
E>>Ну ок, собираем статистику. E>>30% — ханди, сисентер, os24ever — попрощался Т>Меня тоже добавляй. Попросить примеры кода — ещё нормально. Любого, если говорит что нету — можно попросить набросать пример и предложить в качестве тематики то, что ты предлагаешь в виде тестового задания.
если бы ты прочел всю эту мегаветку, то увидел бы, что на примеры кода я согласен Так что ты пополняешь процент тех, с кем я найду общий язык.
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, enji, Вы писали:
E>>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."
M>Плохая задача. Она очень муторная в обработке ошибок. Различные обрывы (и восстановления) связи с устройством, расхождения в контрольной сумме и прочие радости. Включая необходимость переотправки в некоторых случаях пакета с хоста (по таймауту).
Тут как ты понимаешь, все зависит от протокола. Если протокол простой (как тот, что я имел в виду), то там все просто. CRC там обычный xor, обрыв связи устройство не колышит, протокол вида запрос-ответ, накладывается на обычную стейт-машину.
M>Выделенное особенно плохо. Откуда вы такое вообще берете? ....
Опять таки все зависит от протокола. В данном конкретном достаточно таблицы команда — функция-обработчик
Если реализовать ее не в виде switch, то можно будет добавлять новые команды динамически — например в зависимости от конфигурации. Или на одном хоботе поддерживать одни команды, а на другом — другие.
E>>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."
M>Плохая задача. Она очень муторная в обработке ошибок. Различные обрывы (и восстановления) связи с устройством, расхождения в контрольной сумме и прочие радости. Включая необходимость переотправки в некоторых случаях пакета с хоста (по таймауту).
Может я чего-то не понимаю, но ИМХО такие вещи надо делать генератором в ДКА. Описание в json/xml/yaml и генератор кода на питоне + утильный функционал писаный на кондовом С. И никаких радостей, всё скучно и однотипно.
Здравствуйте, Eugeny__, Вы писали:
E__>А вот дальше я бы, как минимум, разделил примерный ход собеседования на минимум 2 градации: начинающий, но толковый(бестолкового уже можно провожать), или опытный. Потому как вопросы ниже вызовут зевоту у опытного.
Согласен, тоже об этом думал. С другой стороны — ну позевает чел 10 минут — какие проблемы
E__>Несмотря на то, что задание вроде бы и несложное(я надеюсь, протокол-то хоть простой? А то бывают и многоуровневые с хитрым шифрованием, проверкой целостности и нетривиальными алгоритмами обработки ошибок для возвращения в рабочее состояние, это уже не лезет ни в какие ворота), я бы отказался писать.
Меня тут уже убедили отказаться от тестового задания, если чел может показать свой код на гитхабе скажем. Как тебе такой вариант?
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>Может я чего-то не понимаю, но ИМХО такие вещи надо делать генератором в ДКА. Описание в json/xml/yaml и генератор кода на питоне + утильный функционал писаный на кондовом С. И никаких радостей, всё скучно и однотипно.
Гм. Наверное зависит от задачи. Если состояния 2-3-4-5 то возни с твоим генератором будет на порядки больше.
AS>>Может я чего-то не понимаю, но ИМХО такие вещи надо делать генератором в ДКА. Описание в json/xml/yaml и генератор кода на питоне + утильный функционал писаный на кондовом С. И никаких радостей, всё скучно и однотипно.
E>Гм. Наверное зависит от задачи. Если состояния 2-3-4-5 то возни с твоим генератором будет на порядки больше.
Команд или состояний? Очевидно что если команд пять, то при сетевом обмене состояний в несколько раз больше. Но однако сие вопрос практики и тех нескольких команд которые надо добавить. О них же как бы заранее не известно. Как бы понятно, что логика состоит из типового применения утильного кода, а вся веселуха заключается в корректном протаскивании и пакетов в нужном порядке и обработки всяких ножидонностей. Мы же типа говорим не про сделать шоб запустилось, а про демонстрацию профессионального подхода и навыков. Не?
Здравствуйте, StanislavK, Вы писали:
SK>не относящийся к теме вопрос. Какое отношение в c/c++ volatile имеет к барьерам? Оно же, вроде как, просто оптимизации на уровне компилятора запрещает? Спрашиваю, потому, что реально не знаю и интересно, что знающие люди скажут.
volatile обычно связывают с видимостью переменной, разделяемой несколькими потоками, но у
нее есть и другое применение. Чтение и запись volatile-переменных неявно ставит барьер памяти.
Причем ввиду известных особенностей hardware reordering на x86 этот барьер неполный (не fence).
А вот с обеспечением атомарности volatile никак не связан, вопреки расхожему мнению.
Ой, тут все в двух словах не описать.
Здравствуйте, enji, Вы писали:
E>Тут как ты понимаешь, все зависит от протокола. Если протокол простой (как тот, что я имел в виду), то там все просто. CRC там обычный xor, обрыв связи устройство не колышит, протокол вида запрос-ответ, накладывается на обычную стейт-машину.
Ну да, естетсвенно, от протокола (и физического транспорта). Плюс обязательная обработка таймаутов. Вы же сами хотели кормить неверный ввод, а ошибки в передаче на устройство более важная проблема.
M>>Выделенное особенно плохо. Откуда вы такое вообще берете? ....
E>Опять таки все зависит от протокола. В данном конкретном достаточно таблицы команда — функция-обработчик E>Если реализовать ее не в виде switch, то можно будет добавлять новые команды динамически — например в зависимости от конфигурации. Или на одном хоботе поддерживать одни команды, а на другом — другие.
А почему в виде таблицы? Почему от конфигурации? Может, их нужно вообще с устройством согласовывать на самом деле? Кстати, а как устройство реагирует на неподдерживаемые (и неполностью полученные) команды? Там дополнительного восстановления не потребуется? Почему вообще обработка различных команд должна производиться на уровне устройства? Может, драйвер должен поддерживать все различные команды, а выбор должен делаться на другом уровне (ввода команд, например). Может, все команды можно описать вообще формально преобразованием из формата команды в пакет и обратно, тогда весь протокол будет задаваться кофнигом. Или будут "модальные" команды. Например, "войти в режим конфигурации", в котором до выхода действует свой набор команд. Этот вариант в вашу табличку хорошо ляжет?
Вот исходя из всех этих вопросов и не понятно, почему кандидат должен прийти к тому решению, которое вы хотите. Для простейшей задачи (даже с добавлением) табличка обработчиков — типичный overengeneering, там для решения if/of или case'ов более чем достаточно (особенно если ввод ручками парсить и на ошибки проверять!). А для корректного выбора более сложной схемы недостаточно данных. С реальном устройстом и приложением чуть попроще, там и круг комад ограничен, и сценарии использования более-менее очевидны.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, StanislavK, Вы писали:
SK>>не относящийся к теме вопрос. Какое отношение в c/c++ volatile имеет к барьерам? Оно же, вроде как, просто оптимизации на уровне компилятора запрещает? Спрашиваю, потому, что реально не знаю и интересно, что знающие люди скажут.
O>volatile обычно связывают с видимостью переменной, разделяемой несколькими потоками, но у O>нее есть и другое применение. Чтение и запись volatile-переменных неявно ставит барьер памяти. O>Причем ввиду известных особенностей hardware reordering на x86 этот барьер неполный (не fence). O>А вот с обеспечением атомарности volatile никак не связан, вопреки расхожему мнению. O>Ой, тут все в двух словах не описать.
volatile запрещает некоторые оптимизации компилятора и все. Область видимости переменной,
разделяемой потоками — одно из применений такого поведения как следствие. Никакие барьеры
памяти при обращении к volatile переменной не ставятся, запрещается лишь reordering с другими
volatile переменными на уровне компилятора (но компилятор может сделать reordering с
другими не-volatile переменными). Барьеры компилятора (для всех видов переменных) можно поставить
явно с помощью специальных конструкций или интринсиков.
Однако, даже если компилятор сгенерировал код в том порядке, что и в исходнике, сам процессор
может сделать reordering; cpu про volatile и барьеры компилятора ничего не знает. Тут нужны
барьеры памяти (mfence и пр.).
Еще один важный момент (не последний). Простое чтение volatile переменной не обязательно даст
последнее, "самее свежее значение", т.к. чтение может произойти из кеша cpu а не из RAM, а
volatile не обеспечивает когерентность кешей процессоров. Тоже решается хардварными барьерами
памяти.
Здравствуйте, vshemm, Вы писали:
V>Никакие барьеры памяти при обращении к volatile переменной не ставятся.
Чтение или запись из volatile-переменной и выступает таким барьером.
На x86 и amd64, за некоторыми исключениями, о которых необходимо знать разве что разработчикам
операционных систем, возможна только одна комбинация инструкций, которая подвержена hardware
reordering — это запись-чтение. Поэтому, когда встречается чтение из volatile, оно может быть
переупорядочено только в одном случае — если предшествующая операция была операцией записи.
Значит, есть гарантия, что чтение из volatile будет гарантированно выполнено до любых следующих за
ним операций (acquire semantics), поскольку ни load-load, ни load-store не переупорядочиваются.
Аналогично, операция записи в volatile может быть переупорядочена только со следующей за ней
операцией чтения, а значит гарантирует, что запись будет выполнена после всех предшествующих ей
операций (release semantics).
V>Однако, даже если компилятор сгенерировал код в том порядке, что и в исходнике, сам процессор V>может сделать reordering; cpu про volatile и барьеры компилятора ничего не знает. Тут нужны V>барьеры памяти (mfence и пр.).
Не может процессор сделать reordering операции store, если до нее была load.
Операция чтения или записи в volatile позволяет контролировать этот аспект (см. выше), поэтому ее
действие логически эквивалентно барьеру, хотя формально она им не является.
Ну я же написал в исходном сообщении: "неявно ставит барьер памяти".
V>Еще один важный момент (не последний). Простое чтение volatile переменной не обязательно даст V>последнее, "самее свежее значение", т.к. чтение может произойти из кеша cpu а не из RAM, а V>volatile не обеспечивает когерентность кешей процессоров. Тоже решается хардварными барьерами V>памяти.
volatile дает гарантию (не по Стандарту, но по факту) что чтение или запись будут осуществляться
через память, а не, скажем, через регистр процессора. На кэш-когерентных архитектурах этого
достаточно, поскольку когерентность обеспечивается аппаратно и один процессор никогда не
получит неверное значение ячейки памяти, если до этого ее обновил другой процессор.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, vshemm, Вы писали:
V>>Никакие барьеры памяти при обращении к volatile переменной не ставятся.
O>Чтение или запись из volatile-переменной и выступает таким барьером. O> ....
Нет. Есть 2 типа барьеров — компилятора и памяти (хардварный). Они независимы, за исключением того,
что оптимизатор может знать про целевую архитектуру. Путать их никак нельзя. Барьеры компилятора
действуют на уровне генерации кода, на уровне выдаваемых асмовских иснструкций, грубо говоря.
Обращение к volatile ставит слабый барьер компилятору — нельзя переупорядочивать эту операцию
с операциями с другими volatile. Сильный барьер запрещает reordering для всех переменных. Все.
V>>Однако, даже если компилятор сгенерировал код в том порядке, что и в исходнике, сам процессор V>>может сделать reordering; cpu про volatile и барьеры компилятора ничего не знает. Тут нужны V>>барьеры памяти (mfence и пр.).
O>Не может процессор сделать reordering операции store, если до нее была load. O>Операция чтения или записи в volatile позволяет контролировать этот аспект (см. выше), поэтому ее O>действие логически эквивалентно барьеру, хотя формально она им не является. O>Ну я же написал в исходном сообщении: "неявно ставит барьер памяти".
Может, даже х86 (сами признали, что некоторые делают reordering и для store; если что, могу привести
пример, когда x86 процессоры в одной линейке имеют разное поведение). volatile этот процесс
никак не контролируют, т.к. на уровне команд процессора обращение что к обычной, что к volatile
переменной выглядит одинаково. У процессора нет информации времени кодогенерации.
Еще раз, интерпретация должна быть такой: "неявно ставит слабый барьер компилятора".
V>>Еще один важный момент (не последний). Простое чтение volatile переменной не обязательно даст V>>последнее, "самее свежее значение", т.к. чтение может произойти из кеша cpu а не из RAM, а V>>volatile не обеспечивает когерентность кешей процессоров. Тоже решается хардварными барьерами V>>памяти.
O>volatile дает гарантию (не по Стандарту, но по факту) что чтение или запись будут осуществляться O>через память, а не, скажем, через регистр процессора. На кэш-когерентных архитектурах этого O>достаточно, поскольку когерентность обеспечивается аппаратно и один процессор никогда не O>получит неверное значение ячейки памяти, если до этого ее обновил другой процессор.
По факту тоже не дает (разве что на genuine intel и некоторых других cpu/архитектурах). Завязываться
на такое поведение — как минимум не кроссплатформенно.
Обращение к памяти идет через кеши процессора, и неизвестно, когда оно достигнет RAM. Когерентность
обеспечивается аппаратно, но не автоматически-"прозрачно", поэтому возможна ситуация, что я описал.
Опять же, volatile тут совсем не в кассу.
Пожалуйста, не смешивайте уровень компилятора (кодогенерации), только на который и влияет volatile,
и уровень аппаратуры. Грабли могут быть эпических масштабов.
Уточнение Говоря про кеши я подразумеваю L1-L2-L3 как одного процессора, так и разных.
Под когерентностью я понимаю когерентность кешей разных процессоров, а не локальных.
Т.е. переменную меняет ДРУГОЙ процессор, а мы на нашем читаем локальную копию. Из разных нитей.
И физически, а не логически одновременно (+- 200ns скажем).
Здравствуйте, vshemm, Вы писали:
O>>Чтение или запись из volatile-переменной и выступает таким барьером.
V>Нет. Есть 2 типа барьеров — компилятора и памяти (хардварный). Они независимы, за исключением того, V>что оптимизатор может знать про целевую архитектуру. Путать их никак нельзя.
Какая еще путаница ? Я ведь конкретно написал. Запись или чтение volatile происходит через память, —
это гарантируется компилятором, — а операции чтения или записи в память влияют на переупорядочивание
самым непосредственным образом. Предположим, вот есть такой код:
int volatile val1;
int volatile val2;
val1 = 100;
val2 = 200;
Здесь гарантируется, что процессор будет выполнять запись в порядке val1-val2, но никогда не наоборот,
причем эта гарантия основывается исключительно на особенностях архитектуры, а не на поведении компилятора,
хотя и оно тоже сказывается, так как он не станет изменять порядок обращения к volatile-данным.
И для данного примера не требуется вставлять никаких дополнительных барьеров — ни компиляторных,
ни особенно хардварных, так как это лишь приведет к дополнительным накладным расходам.
У нас уже есть барьер в виде того, что комбинация запись-запись [просто так] не переупорядочивается.
А вот если написать по-другому:
int volatile val1;
int volatile val2;
val1 = 100;
int a = val2;
то независимо от того, что используется volatile, чтение переменной val2 может случиться до
записи в переменную val1, опять же исключительно ввиду особенностей архитектуры, которая
допускает reordering для данной комбинации. Вот в таких случаях, если порядок выполнения данных
операций важен, и требуется настоящий хардварный барьер — lock, fence и т.д.
V>Барьеры компилятора действуют на уровне генерации кода, на уровне выдаваемых асмовских иснструкций, V>грубо говоря. Обращение к volatile ставит слабый барьер компилятору — нельзя переупорядочивать эту V>операцию с операциями с другими volatile. Сильный барьер запрещает reordering для всех переменных. Все.
Очевидно, не все. См. выше.
V>Еще раз, интерпретация должна быть такой: "неявно ставит слабый барьер компилятора".
Что значит "слабый" ? Неспособный влиять на hardware reordering ?
Ок. Сможете привести пример кода для x86 или amd64 а-ля тест Деккера, который бы доказал,
что запись или чтение volatile-данных не сказывается на hardware reordering ? Уверен, что нет.
V>Может, даже х86 (сами признали, что некоторые делают reordering и для store; если что, могу привести V>пример, когда x86 процессоры в одной линейке имеют разное поведение).
Приведите. Только не надо возвращаться к архаичным 80486.
V>volatile этот процесс никак не контролируют, т.к. на уровне команд процессора обращение что к V>обычной, что к volatile переменной выглядит одинаково. У процессора нет информации времени кодогенерации.
Кто ж спорит.
Вот только чтение или запись в память выполняется процессором, а не компилятором, а операции
доступа к памяти сказываются на переупорядочивании и могут его ограничивать. О чем я тут и талдычу.
V>Обращение к памяти идет через кеши процессора, и неизвестно, когда оно достигнет RAM. Когерентность V>обеспечивается аппаратно, но не автоматически-"прозрачно", поэтому возможна ситуация, что я описал. V>Опять же, volatile тут совсем не в кассу.
Для программы не имеет значения откуда она получила данные — реально из памяти или из кэша.
До тех пор, пока остальные процессоры "видят" то же самое значение через различные механизмы
синхронизации, в том числе через когерентность кэша. С другими архитектурами я не работал,
так что про них сказать не могу.
V>Пожалуйста, не смешивайте уровень компилятора (кодогенерации), только на который и влияет volatile, V>и уровень аппаратуры. Грабли могут быть эпических масштабов.
На что и как влияет volatile я уже написал выше. Никто не говорил о какой-то дополнительной
"волшебной" кодогенерации, сопутствующей volatile, речь о чисто хардварных вещах — чтение и запись в
память, которая неявным образом влияет на hardware reordering. volatile тут, по сути, вообще не
при чем, просто если использовать обычную, не-volatile переменную, нет гарантии, что компилятор не
"закэширует" ее в каком-нибудь регистре, а в случае volatile такая гарантия у нас есть.
E>>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."
M>Плохая задача. Она очень муторная в обработке ошибок. Различные обрывы (и восстановления) связи с устройством, расхождения в контрольной сумме и прочие радости. Включая необходимость переотправки в некоторых случаях пакета с хоста (по таймауту).
Ну, просто переотправка — это довольно просто. А так — согласен, обработка ошибок при общении с девайсом — это в реальном мире довольно сложный кейс, если мы говорим о автономной работе комплекса, когда нет возможности сообщить юзеру "произошла фигня, что делать будем?".
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
E>>>А за что тут платить? Т>>За трату времени.
E>Не всякая трата времени оплачивается. E>ты посетил собеседование, потратил время, но тебе за него не заплатили
А ведь это мысль!
Большинство контор в нашей местности платит около 1000$ сотруднику, рекомендовавшему друга, если последний прошел собеседу и устроился на работу. Так почему я, пришедший на работу сам, и рекомендующий сам себя, должен лишаться этой суммы? Заодно хоть отчасти окупит геморрой с собеседованиями. При следующей смене работы обязательно буду HR-ам предъявлять подобные размышления.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, enji, Вы писали:
E__>>А вот дальше я бы, как минимум, разделил примерный ход собеседования на минимум 2 градации: начинающий, но толковый(бестолкового уже можно провожать), или опытный. Потому как вопросы ниже вызовут зевоту у опытного.
E>Согласен, тоже об этом думал. С другой стороны — ну позевает чел 10 минут — какие проблемы
Не забывай: собеседование, оно двухстороннее. Человек компанию и собеседующего оценивеат не менее(а чаще и более), чем компания его. Позевает, и напишет в своем графике собеседований напротив вашей конторы что-то типа "квалификация собеседующего ниже плинтуса, контора — говно, решение — отказ". У меня при последней смене работы подобные записи получили 8 компаний(2 было выделено как особый трэш), хотя они все мне предлагали оффер.
Хотя, может, это специфика большого города, где чаша весов на рынке труда IT сильно перевешена в сторону работника.
E__>>Несмотря на то, что задание вроде бы и несложное(я надеюсь, протокол-то хоть простой? А то бывают и многоуровневые с хитрым шифрованием, проверкой целостности и нетривиальными алгоритмами обработки ошибок для возвращения в рабочее состояние, это уже не лезет ни в какие ворота), я бы отказался писать.
E>Меня тут уже убедили отказаться от тестового задания, если чел может показать свой код на гитхабе скажем. Как тебе такой вариант?
Ну, в си(++?) качество кода может решать больше, чем в более привычных мне языках(слишком много нюансов). На той же жабе, где "как думается, так и пишется", вполне достаточно оценить общий уровень, смотреть на код не особо есть смысл — там трудно написать как-то по-извращенному. Ну а если человек понимает некоторые важные моменты, то врядли у него плохое качество кода.
В случае си, код на гитхабе, и пару вопросов по случайным кускам(чтобы понять, что они не левые) — вполне достаточно, имхо.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Alexéy Sudachén, Вы писали:
E>>Гм. Наверное зависит от задачи. Если состояния 2-3-4-5 то возни с твоим генератором будет на порядки больше.
AS>Команд или состояний? Очевидно что если команд пять, то при сетевом обмене состояний в несколько раз больше. Но однако сие вопрос практики и тех нескольких команд которые надо добавить. О них же как бы заранее не известно. Как бы понятно, что логика состоит из типового применения утильного кода, а вся веселуха заключается в корректном протаскивании и пакетов в нужном порядке и обработки всяких ножидонностей. Мы же типа говорим не про сделать шоб запустилось, а про демонстрацию профессионального подхода и навыков. Не?
Нормальная реализация failover в рамках даже довольно простого протокола уже несколько выходит за пределы "простой задачи на пару часов". В рамках чуть более сложного — это уже реальная задача, решать которую нахаляву — глупость. В немалой степени из-за того, что в доках к девайсам я _никогда_ не видел полного описания всех возможных flow, остальное додумывать и доделывать самому. Может, ТС живет в мире эльфов, и там всегда есть более чем развернутая документация по устройствам. Я живу в реальном мире, где иногда единственное, что есть — это двойной автоперевод китайский-->английский-->русский(без оригиналов, есть в наличии только этот "русский" вариант), и несколько логов с перепиской каких-то индусов с кошмарным английским... Как хорошо, что хотя-бы цифры во всех языках одинаковы.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
SK>>не относящийся к теме вопрос. Какое отношение в c/c++ volatile имеет к барьерам? Оно же, вроде как, просто оптимизации на уровне компилятора запрещает? Спрашиваю, потому, что реально не знаю и интересно, что знающие люди скажут.
O>volatile обычно связывают с видимостью переменной, разделяемой несколькими потоками, но у O>нее есть и другое применение. Чтение и запись volatile-переменных неявно ставит барьер памяти. O>Причем ввиду известных особенностей hardware reordering на x86 этот барьер неполный (не fence). O>А вот с обеспечением атомарности volatile никак не связан, вопреки расхожему мнению. O>Ой, тут все в двух словах не описать.
В том-то и дело, что ТС этот вопрос ставит в один ряд с "переверните строку". А это умения и знания радикально разного уровня. Даже в жабе, где все более причесано, volatile имеет ряд неявных особенностей. В сях, с их низким уровнем, этих особенностей масса(какой компилятор, какая архитектура?).
А теперь вопрос: если человек нормально отвечает и рассказывает все нюансы при использовании volatile, стоит ли его грузить унылыми вопросами про переворот строки и прочим? Может ли человек, понимающий, как работает этот барьер памяти на уровне разных архитектур, не понимать указателей? Или чего-то еще?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>В том-то и дело, что ТС этот вопрос ставит в один ряд с "переверните строку". А это умения и знания радикально разного уровня. Даже в жабе, где все более причесано, volatile имеет ряд неявных особенностей. В сях, с их низким уровнем, этих особенностей масса(какой компилятор, какая архитектура?).
E__>А теперь вопрос: если человек нормально отвечает и рассказывает все нюансы при использовании volatile, стоит ли его грузить унылыми вопросами про переворот строки и прочим? Может ли человек, понимающий, как работает этот барьер памяти на уровне разных архитектур, не понимать указателей? Или чего-то еще?
Так в этом же самая соль. Спрашиваем у человека — чему равен размер struct {void *member}.
Один выпаливает: "4 байта". Второй говорит: "зависит от архитектуры, на x86 4 байта, на amd64 — 8".
Третий спрашивает: "а #pragma pack ? а настройки компилятора ? не-е, тут не все так просто,
давайте сидеть решать конкретно", четвертый прикалывается: "sizeof (struct)" и т.п.
Пятый молча берет бумажку и сходу пишет шаблонный класс, параметризируемый типом структуры, с
выведением типа, вложенными тайпдефами, воркэраундами и т.п. "Сейчас-сейчас, через полчаса у
нас будет универсальный шаблон для определения размера типа с проверкой в compile time".
Второго и третьего я бы повел дальше, к остальным надо подозрительно присмотреться.
Ну и так далее в том же духе. IMHO на собеседовании не столько важны сами вопросы и даже не
правильные/неправильные ответы на них, сколько реакция и поведение собеседуемого.
Чем больше получится узнать о его подходах, воззрениях, да и вообще узнать как человека, тем лучше.
Давать многочасовые сложные задания — бред. Спрашивать про разворот списка, как и про другие, не
шибко сложные, но требующие логического подхода и воображения вещи — можно и нужно.
Не с целью получить верный ответ, а с целью получить представление о способностях кандидата к
какому-то мышлению, выводам, поискам путей, как он будет выкручиваться, когда поймет, что не
может справиться с задачей, и т.п.
O>Здесь гарантируется, что процессор будет выполнять запись в порядке val1-val2, но никогда не наоборот, O>причем эта гарантия основывается исключительно на особенностях архитектуры, а не на поведении компилятора, O>хотя и оно тоже сказывается, так как он не станет изменять порядок обращения к volatile-данным.
Какой процессор? PowerPC? Alpha? ARM? Разумеется, нет. Здесь гарантируется, что компилятор сгенерирует
инструкции записи сначала для val1, потом для val2, и только. Не нужно особенности архитектуры выдавать
за свойство volatile.
O>И для данного примера не требуется вставлять никаких дополнительных барьеров — ни компиляторных, O>ни особенно хардварных, так как это лишь приведет к дополнительным накладным расходам. O>У нас уже есть барьер в виде того, что комбинация запись-запись [просто так] не переупорядочивается.
Барьера нет, если нужен именно такой порядок, следует вставить wmb. А уже его реализация для данной архитектуры
может быть пустой, что избавляет от оверхеда.
V>>Еще раз, интерпретация должна быть такой: "неявно ставит слабый барьер компилятора".
O>Что значит "слабый" ? Неспособный влиять на hardware reordering ? O>Ок. Сможете привести пример кода для x86 или amd64 а-ля тест Деккера, который бы доказал, O>что запись или чтение volatile-данных не сказывается на hardware reordering ? Уверен, что нет.
Уже говорил: слабый потому, что влияет только на volatile переменные. Все барьеры компилятора не влияют на
hardware reordering заранее известным способом, поэтому никаких предположений лучше не делать.
Пример кода вы привели сами — посмотрите на ассемблерный выхлоп, там не будет инструкций ни явно влияющих на
реордеринг (вроде mfence), ни влияющих неявно (вроде cmpxchg).
Кстати, попробуйте написать лок Деккера с использованием только volatile или других барьеров компилятора — для
мультипроцессорных систем не получится, т.к. там понадобятся барьеры памяти, которые volatile не обеспечивает.
O>Приведите. Только не надо возвращаться к архаичным 80486.
Например, линейка GeodeGX/LX/NX. Последний построен на базе атлона, поэтому, в отличие от первых двух, не
поддерживает store reordering.
O>Вот только чтение или запись в память выполняется процессором, а не компилятором, а операции O>доступа к памяти сказываются на переупорядочивании и могут его ограничивать. О чем я тут и талдычу.
А могут не ограничивать. Поэтому утверждение, что volatile всегда ограничивает реордеринг и ставит барьер
памяти — ложно.
O>Для программы не имеет значения откуда она получила данные — реально из памяти или из кэша. O>До тех пор, пока остальные процессоры "видят" то же самое значение через различные механизмы O>синхронизации, в том числе через когерентность кэша. С другими архитектурами я не работал, O>так что про них сказать не могу.
В мире полно процессоров, где когерентность кеша намного слабее, чем у интела. Но тут согласен, для
большинства потребительских (сиречь х86) на это можно не обращать внимания.
Здравствуйте, okman, Вы писали:
O>Какая еще путаница ? Я ведь конкретно написал.
Давайте проясним один вопрос. У меня сложилось впечатление, что все что вы пишете относится исключительно к случаю "Windows + майкросовтовской компилятор + x86". Я правильно понял?
Здравствуйте, StanislavK, Вы писали:
SK>Здравствуйте, okman, Вы писали:
O>>Какая еще путаница ? Я ведь конкретно написал. SK>Давайте проясним один вопрос. У меня сложилось впечатление, что все что вы пишете относится исключительно к случаю "Windows + майкросовтовской компилятор + x86". Я правильно понял?
Даже для такой связки явный барьер памяти нужен, но придется еще сильнее углубиться в архитектуру интеловских процессоров.
В SSE2 появились инструкции загрузки/сохранения с помощью non-temporal hint в обход всех кешей (они быстрые
и не засоряют кеш). Реализуется через write-combining протокол работы с памятью. Поэтому, хотя такие инструкции
записи и не будут переупорядочены, переменные val1 и val2 для других процессоров могут обновиться в противоположном
порядке, т.е. эффект аналогичен переупорядочиванию инструкций. Можете представить себе отладку подобных багов. Так что
если алгоритм требует барьера памяти — его нужно ставить явно, а не полагаться на volatile и знания конкретной архитектуры.
И раз уж пошла такая пьянка, когерентность кешей инструкций в х86 не обеспечивается, т.е. при работе с self-modifying кодом
(например, вы ваяте JIT) это тоже надо учитывать — одного volatile мало.
Здравствуйте, Eugeny__, Вы писали:
E__>А теперь вопрос: если человек нормально отвечает и рассказывает все нюансы при использовании volatile, стоит ли его грузить унылыми вопросами про переворот строки и прочим? Может ли человек, понимающий, как работает этот барьер памяти на уровне разных архитектур, не понимать указателей? Или чего-то еще?
KP>Исхожу исключительно из своего опыта: 99% разработчиков, которых я могу действительно назвать стоящими имеют что показать.
У меня, напротив, несколько иной опыт: 99% тех, кто горд своими open source и прочими публичными проектами, в работе оказываются так себе. Потому что им, однако, интереснее продолжать пиарить свой open source и проекты.
Не претендую на всеобщность, просто такая подборка опыта вышла.
AS>Может я чего-то не понимаю, но ИМХО такие вещи надо делать генератором в ДКА. Описание в json/xml/yaml и генератор кода на питоне + утильный функционал писаный на кондовом С. И никаких радостей, всё скучно и однотипно.
Тогда это может даже и не на 2 дня быть, а больше. Особенно для тех, кто раньше не занимался подобным.
E__>В том-то и дело, что ТС этот вопрос ставит в один ряд с "переверните строку". А это умения и знания радикально разного уровня.
Собственно, об этом я и написал. Но ТС продолжил настаивать на своей версии "volatile нужен для того, чтобы писать в регистры устройств". Немного понимая подоплеку этого высказывания (embedded же), а также увидев цифры "40к. в месяц", можно сделать вывод — ищут недавнего студента, который в состоянии заучить несколько страниц из Страуструпа. И тестовое задание нужно ровно для того же, понять, способен ли претендент хоть что-то написать.
В таком варианте все встает на свои места. Первый же, кто такое собеседование пройдет, вполне удовлетворит компанию ТС, ибо им и не надо звезд с неба.
Здравствуйте, Eugeny__, Вы писали:
E>>- #define MAX(a,b) — как написать, чем чревато?
E__>Дефайны для всего, кроме констант — фтопку. Именно из-за вот таких возможных побочных эффектов.
Здравствуйте, enji, Вы писали:
H>>Ну понятно, что можно сделать 50 dynamic_cast и после удачного каста сделать delete. Ответ на 100% верный, но тот кто так делает страдает легким дебилизмом. E>Вариант с dynamic_cast вообще не рабочий — надо в точке удаления знать все возможные типы и класс должен быть виртуальным. E>Я вообще-то имел в виду boost::shared_ptr или просто хранить вместе с объектом "удалятель"
shared_ptr. В embedded? Мьсе знает толк.
Не говоря уже о том, что наличие shared_ptr эквивалентно знанию конкретного типа.
Здравствуйте, vshemm, Вы писали:
V>Не нужно особенности архитектуры выдавать за свойство volatile.
Если особенности архитектуры имеют место быть, они и являются свойством volatile.
Пусть и побочным, не относящимся к прямому назначению этого квалификатора и тому,
как его действие описано в стандарте. Я привел один из примеров для x86 — архитектуры, с
которой работаю 99.9% своего рабочего времени.
V>Барьера нет, если нужен именно такой порядок, следует вставить wmb. А уже его реализация для данной архитектуры V>может быть пустой, что избавляет от оверхеда.
With Visual Studio 2005, the compiler uses acquire semantics for read operations on volatile
variables and release semantics for write operations on volatile variables (when supported by the CPU).
Therefore, you can correct the example as follows:
И дальше исправленный код, где все исправление сводится к добавлению volatile.
И он будет работать корректно, без явных MemoryBarrier() или _mm_mfence().
Microsoft CL 14.0.0 and later versions tighten the restrictions on the types of
reordering that can occur around volatile variables. In these compilers, reads
from volatile locations are treated as acquires and writes to volatile locations are
treated as releases on hardware architectures that support these semantics.
An operation has acquire semantics if other processors will always see its effect before any
subsequent operation's effect. An operation has release semantics if other processors will
see every preceding operation's effect before the effect of the operation itself.
Подытоживая вышесказанное — на x86/amd64 чтение/запись из/в volatile ставит acquire/release барьер.
Что и было написано в моем исходном сообщении.
V>Уже говорил: слабый потому, что влияет только на volatile переменные. Все барьеры компилятора не влияют на V>hardware reordering заранее известным способом, поэтому никаких предположений лучше не делать.
Да, для кросс-платформенной разработки это так. Там вообще используется std::atomic и остальное.
V>Пример кода вы привели сами — посмотрите на ассемблерный выхлоп, там не будет инструкций ни явно влияющих на V>реордеринг (вроде mfence), ни влияющих неявно (вроде cmpxchg).
Что характерно для данной дискуссии — я нигде не утверждал иное.
V>Кстати, попробуйте написать лок Деккера с использованием только volatile или других барьеров компилятора — для V>мультипроцессорных систем не получится, т.к. там понадобятся барьеры памяти, которые volatile не обеспечивает.
Насколько я помню, Деккер требует full memory barrier, который volatile, естественно, поставить не может.
Но в определенных случаях volatile можно использовать и это будет дешевле, чем звать lock или fence,
которая, если не ошибаюсь, и не на всех архитектурах-то поддерживается.
V>Например, линейка GeodeGX/LX/NX. Последний построен на базе атлона, поэтому, в отличие от первых двух, не V>поддерживает store reordering.
Здравствуйте, StanislavK, Вы писали:
SK>Давайте проясним один вопрос. У меня сложилось впечатление, что все что вы пишете относится исключительно к случаю "Windows + майкросовтовской компилятор + x86". Я правильно понял?
Я стараюсь всегда отмечать, что речь идет про конкретную архитектуру, за исключением форумов,
где это подразумевается по умолчанию (например, в "WIN API").
C>>UB при пустой входной строке. Сравнение на больше/меньше указателей, не указывающих в один и тот же массив.
H>Неправда. strlen гарантирует что нулей между поинтерами нет.
Каких таких нулей? strlen возвращает 0, после чего p2 указывает на один байт левее, чем p1. Формально это уже UB. Фактически проблема проявится, если нам посчастливилось исполняться на архитектуре, где нулевой адрес доступен для пользовательских программ и входная строка как раз окажется там; или же в случае, если арифметика адресов знаковая и входная строка оказалась по адресу -2^(n-1), где n — разрядность адресов.
Так С или C++?
E>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд." E>И оценить как работу проги (написать простой автотестер, который скормит кривые пакеты, случайный мусор, а также правильные команды и посмотрит на ответы), так и исходный код, наличие тестов, сборочного скрипта, репозитария dvcs
Лучше напиши немног оговнокода и попроси исправить и отформатировать на ноуте.
E>Покритикуйте, плиз.
Домашние задания в топку.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, StanislavK, Вы писали:
SK>>Давайте проясним один вопрос. У меня сложилось впечатление, что все что вы пишете относится исключительно к случаю "Windows + майкросовтовской компилятор + x86". Я правильно понял? O>Я стараюсь всегда отмечать, что речь идет про конкретную архитектуру, за исключением форумов, O>где это подразумевается по умолчанию (например, в "WIN API").
Ну и что именно вы тут отметили? "Windows + майкросовтовской компилятор + x86" или нет?
Даже если предположить, что вы имели ввиду это связку. Не понятно почему вы упоминаете барьеры без оговорок. В 2005 студии там да, все так как вы описали (http://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.80).aspx):
Objects declared as volatile are not used in certain optimizations because their values can change at any time. The system always reads the current value of a volatile object at the point it is requested, even if a previous instruction asked for a value from the same object. Also, the value of the object is written immediately on assignment.
Also, when optimizing, the compiler must maintain ordering among references to volatile objects as well as references to other global objects. In particular,
A write to a volatile object (volatile write) has Release semantics; a reference to a global or static object that occurs before a write to a volatile object in the instruction sequence will occur before that volatile write in the compiled binary.
A read of a volatile object (volatile read) has Acquire semantics; a reference to a global or static object that occurs after a read of volatile memory in the instruction sequence will occur after that volatile read in the compiled binary.
This allows volatile objects to be used for memory locks and releases in multithreaded applications.
Однако, в статье за 2012 уже все нескольно иначе (http://msdn.microsoft.com/en-us/library/12a04hfd.aspx). Подобное поведение сохранятся по-умолчанию (причем только на x86), но так же появляется совместимое с ISO, которое уже, как я понимаю, не подразумевает барьеров.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, sysenter, Вы писали:
S>>Это если есть открытые исходники.
KP>Ну... Не хочу никого обидеть, но я не могу считать разработчика хорошим/стоящим разработчиком, если ему нечего показать в той или иной форме, будь то открытый код, профильные заметки, участие в публичном проекте, собственный проект в AppStore и т.п. Это довольно дико, на мой взгляд.
Не у всех людей есть желание публичного признания или пиара через yoba приложение в аппстор.
C>Каких таких нулей? strlen возвращает 0, после чего p2 указывает на один байт левее, чем p1. Формально это уже UB. Фактически проблема проявится, если нам посчастливилось исполняться на архитектуре, где нулевой адрес доступен для пользовательских программ и входная строка как раз окажется там; или же в случае, если арифметика адресов знаковая и входная строка оказалась по адресу -2^(n-1), где n — разрядность адресов.
Смотрите внимательней. Разыменование указателей идет только тогда, когда p1<p2. По нулевому адресу адрес располагаться не может, в C++ ясно прописано что (void*)0 не может ссылаться на объект. -2^(n-1) это нечто за гранью фантастики — никогда не видел поинтеров типа 0xFFFFFFFF.
Здравствуйте, StanislavK, Вы писали:
SK>Ну и что именно вы тут отметили? "Windows + майкросовтовской компилятор + x86" или нет? SK>Даже если предположить, что вы имели ввиду это связку. Не понятно почему вы упоминаете барьеры без оговорок.
Виноват.
Все написанное относится к Windows-x86/x64, компилятор Visual C/C++ 2005 и выше.
SK>В 2005 студии там да, все так как вы описали (http://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.80).aspx). SK>Однако, в статье за 2012 уже все нескольно иначе (http://msdn.microsoft.com/en-us/library/12a04hfd.aspx). Подобное поведение сохранятся по-умолчанию (причем только на x86), но так же появляется совместимое с ISO, которое уже, как я понимаю, не подразумевает барьеров.
Как я понимаю, /volatile:iso — опция исключительно для ARM-ов, а программы для x86/x64 должны
поддерживать совместимость с существующими функциями вроде _InterlockedIncrement, которые
тоже "завязаны" на volatile. Поэтому трудно представить, что Visual C++ 2012, да и вообще
любой Windows-совместимый компилятор, использующий заголовки из SDK/Visual Studio, имел бы
иное поведение volatile. Видимо поэтому /volatile:ms для данных архитектур стоит по умолчанию.
Но это так, рассуждения вслух.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, vshemm, Вы писали:
V>>Не нужно особенности архитектуры выдавать за свойство volatile.
O>Если особенности архитектуры имеют место быть, они и являются свойством volatile. O>Пусть и побочным, не относящимся к прямому назначению этого квалификатора и тому, O>как его действие описано в стандарте. Я привел один из примеров для x86 — архитектуры, с O>которой работаю 99.9% своего рабочего времени.
Стандарт языка не привязан к архитектуре, и полагаться на подобные особенности, — значит, получить грабли в дальнейшем.
O>В обоих случаях отмечается, что эффект volatile зависит от CPU/архитектуры. O>Что такое, по-Вашему, acquire и release semantics ? O>Ответ здесь: O>http://msdn.microsoft.com/en-us/library/windows/hardware/ff540496(v=vs.85).aspx O>
O>An operation has acquire semantics if other processors will always see its effect before any
O>subsequent operation's effect. An operation has release semantics if other processors will
O>see every preceding operation's effect before the effect of the operation itself.
O>Подытоживая вышесказанное — на x86/amd64 чтение/запись из/в volatile ставит acquire/release барьер. O>Что и было написано в моем исходном сообщении.
A write to a volatile object (volatile write) has Release semantics; a reference to a global or static object that occurs before a write to a volatile object in the instruction sequence will occur before that volatile write in the compiled binary.
A read of a volatile object (volatile read) has Acquire semantics; a reference to a global or static object that occurs after a read of volatile memory in the instruction sequence will occur after that volatile read in the compiled binary.
Т.е. речь идет о acquire и release semantics применительно к кодогенерации, а не ко времени исполнения.
Это и есть барьеры компилятора, а не барьеры памяти.
И как быть с SSE инструкциями с memory-relaxed model тоже непонятно из документации.
Accesses to non-volatile objects are not ordered with respect to volatile accesses. You cannot use a volatile object as a memory barrier to order a sequence of writes to non-volatile memory.
Вот на это поведение и нужно рассчитывать, имхо.
V>>Пример кода вы привели сами — посмотрите на ассемблерный выхлоп, там не будет инструкций ни явно влияющих на V>>реордеринг (вроде mfence), ни влияющих неявно (вроде cmpxchg).
O>Что характерно для данной дискуссии — я нигде не утверждал иное.
Так что же из этого следует?
V>>Кстати, попробуйте написать лок Деккера с использованием только volatile или других барьеров компилятора — для V>>мультипроцессорных систем не получится, т.к. там понадобятся барьеры памяти, которые volatile не обеспечивает.
O>Насколько я помню, Деккер требует full memory barrier, который volatile, естественно, поставить не может. O>Но в определенных случаях volatile можно использовать и это будет дешевле, чем звать lock или fence, O>которая, если не ошибаюсь, и не на всех архитектурах-то поддерживается.
Думаю, что на "железных" acquire и release это сделать тоже можно. Правда, в х86 для них специальных инструкций нет.
Есть мнение, что для синхронизационных задач volatile вообще не нужен (ну, кроме триков а-ля Александреску, но
там модификатор используется для других целей).
Здравствуйте, Handie, Вы писали:
C>>Каких таких нулей? strlen возвращает 0, после чего p2 указывает на один байт левее, чем p1. Формально это уже UB. Фактически проблема проявится, если нам посчастливилось исполняться на архитектуре, где нулевой адрес доступен для пользовательских программ и входная строка как раз окажется там; или же в случае, если арифметика адресов знаковая и входная строка оказалась по адресу -2^(n-1), где n — разрядность адресов.
H>Смотрите внимательней. Разыменование указателей идет только тогда, когда p1<p2.
5: When an expression that has integral type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the pointer operand points to an element of an array object, and the array is large enough, the result points to an element offset from the original element such that the difference of the subscripts of the resulting and original array elements equals the integral expression. In other words, if the expression P points to the i-th element of an array object, the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N has the value n) point to, respectively, the i + n-th and i − n-th elements of the array object, provided they exist. Moreover, if the expression P points to the last element of an array object, the expression (P)+1 points one past the last element of the array object, and if the expression Q points one past the last element of an array object, the expression (Q)-1 points to the last element of the array object. If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined.
То есть даже не сравнение p1 < p2, а уже само формирование p2 = "" + 0 — 1 даёт UB. О разыменовании указателей в никуда я не говорю — его тут действительно нет (кроме того патологического случая, когда "" == reinterpret_cast<char*>(0)).
H>По нулевому адресу адрес располагаться не может, в C++ ясно прописано что (void*)0 не может ссылаться на объект.
Нулевой указатель не обязан быть побитово равен нулю, он может быть произвольным битовым паттерном. Если наша реализация представляет нулевой указатель как 0xDEADBEEF0FC0FFEE, то reinterpret_cast<char*>(0) потенциально может указывать на реальный объект.
Здравствуйте, Abyx, Вы писали:
E>>>- #define MAX(a,b) — как написать, чем чревато?
E__>>Дефайны для всего, кроме констант — фтопку. Именно из-за вот таких возможных побочных эффектов.
A>для констант есть const/constexpr
Тем более.
У меня имеется опыт разбора чужого кода с хитровывернутыми дефайнами. Нафиг-нафиг.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, vshemm, Вы писали:
V>Стандарт языка не привязан к архитектуре, и полагаться на подобные особенности, — значит, получить грабли в дальнейшем.
Не всякая программа, особенно завязанная на многопоточность, может быть написана исключительно
стандартными средствами. std::atomic не всемогущ. К тому же, он только в C++11.
Тогда и _mm_mfence нестандартен, и InterlockedIncrement, и еще куча всего.
V>Хмм, читаем внимательно: http://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.80).aspx V>
V>A write to a volatile object (volatile write) has Release semantics; a reference to a global or static object that occurs before a write to a volatile object in the instruction sequence will occur before that volatile write in the compiled binary.
V>A read of a volatile object (volatile read) has Acquire semantics; a reference to a global or static object that occurs after a read of volatile memory in the instruction sequence will occur after that volatile read in the compiled binary.
V>Т.е. речь идет о acquire и release semantics применительно к кодогенерации, а не ко времени исполнения. V>Это и есть барьеры компилятора, а не барьеры памяти.
А Вы заметили, что в обоих топиках, ссылки на которые я давал выше, были явно
упомянуты CPU и architecture ?
Что мне не удалось Вас убедить.
V>Есть мнение, что для синхронизационных задач volatile вообще не нужен (ну, кроме триков а-ля Александреску, но V>там модификатор используется для других целей).
Здравствуйте, okman, Вы писали:
O>Не всякая программа, особенно завязанная на многопоточность, может быть написана исключительно O>стандартными средствами. std::atomic не всемогущ. К тому же, он только в C++11. O>Тогда и _mm_mfence нестандартен, и InterlockedIncrement, и еще куча всего.
Ага, старые стандарты не касались многопоточности. В новом же std::atomic таки всемогущ, т.к. он
имеет атомарные load, store и CAS, с помощью чего можно реализовать любую синхронизацию.
O>А Вы заметили, что в обоих топиках, ссылки на которые я давал выше, были явно O>упомянуты CPU и architecture ?
Аналогично, там предполагается отсутствие store reordering у процессора (и даже упоминается, что с non-temporal
инструкциями на х86 это не работает). Я с этим и не спорю.
V>>>>Пример кода вы привели сами — посмотрите на ассемблерный выхлоп, там не будет инструкций ни явно влияющих на V>>>>реордеринг (вроде mfence), ни влияющих неявно (вроде cmpxchg).
O>Что мне не удалось Вас убедить. O>
Ну а я делаю (имхо, очевидный) вывод, что барьеры памяти компилятором не ставятся
O>Да, я встречал это мнение раньше. O>Вот, например, была здесь такая тема несколько лет назад — http://www.rsdn.ru/forum/cpp/978815.flat.aspx
Вообще, по технической части у нас с вами особых противоречий нет, просто вы слишком оптимистично воспринимаете
поведение volatile, хотя это всего лишь побочный эффект и особенности архитектуры.
V>>В новом же std::atomic таки всемогущ, т.к. он V>>имеет атомарные load, store и CAS, с помощью чего можно реализовать любую синхронизацию.
D>отнимая 100% CPU?
Не всегда. В конце концов, есть wait-free. Если нужно уметь засыпать — придется дополнительно
использовать вызовы ядра, ибо стандарт не занимается шедулированием.
Здравствуйте, enji, Вы писали:
E>- напишите функцию реверса строки
Кстати, о реверсе строки.
Напишите свою, если не сложно(ну, кандидат-то должен, отчего бы и вы не написали бы?). Мне вот интересно было бы посмотреть.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
E__>Кстати, о реверсе строки.
E__>Напишите свою, если не сложно(ну, кандидат-то должен, отчего бы и вы не написали бы?). Мне вот интересно было бы посмотреть.
Ах, да, чтобы чисто было — данные берем из файла, кладем в файл.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, landerhigh, Вы писали:
L>shared_ptr. В embedded? Мьсе знает толк.
эмбеддед — он вообще-то разный Есть 8к флеша, а есть мегабайт... Где-то нельзя использовать динамическую память, где-то можно. К тому ж у нас есть и не эмбеддед тоже
L>Не говоря уже о том, что наличие shared_ptr эквивалентно знанию конкретного типа.
Да неужели.
struct A
{
};
struct B : A
{
string s;
};
shared_ptr<A> createB() { return shared_ptr<A>(new B); }
{
auto pA = createB();
} // тут мы не знаем типа B, однако он вполне корректно удалится
И согласись, что шаред птр не эквивалентен "50 dynamic_cast" вообще никак. Вариант с dynamic_cast (который кстати не поддерживается тем-же иар-ом ) — это полная жопа как по написанию, так и по поддержке.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, enji, Вы писали:
K>Так С или C++?
Дык писал выше. И то и то. Есть старые проекты, которые вообще были на асме, потом мигрировали на С, потом частично дописываются на С++.
K>Лучше напиши немног оговнокода и попроси исправить и отформатировать на ноуте.
Можно и так, спасибо за идею
Здравствуйте, enji, Вы писали:
L>>shared_ptr. В embedded? Мьсе знает толк. E>эмбеддед — он вообще-то разный Есть 8к флеша, а есть мегабайт... Где-то нельзя использовать динамическую память, где-то можно. К тому ж у нас есть и не эмбеддед тоже
Ну ты сам упомянул эмбеддед, в чем вопрос? И таки да, бывает, что и динамическую память использовать можно, и ее вроде бы даже много, мегабайты, да на поверку оказывается, что лучше не надо.
L>>Не говоря уже о том, что наличие shared_ptr эквивалентно знанию конкретного типа. E>Да неужели.
Абсолютно.
E>
E>struct A
E>{
E>};
E>struct B : A
E>{
E> string s;
E>};
E>shared_ptr<A> createB() { return shared_ptr<A>(new B); }
E>{
E> auto pA = createB();
E>} // тут мы не знаем типа B, однако он вполне корректно удалится
E>
В том-то и дело, что тут мы "знаем" тип B, точнее, о нем за нас "знает" shared_ptr. Равно как знали бы, если бы нам дали голый указатель вместе с его удалятором. Такой случай никакого интереса не представляет, ибо о корректном удалении позаботились заранее.
Вот когда у тебя уже есть только IInterface* pPointer, да без виртуального деструктора, и ничего больше, как будешь выкручиваться?
Здравствуйте, Eugeny__, Вы писали: E__>Напишите свою, если не сложно(ну, кандидат-то должен, отчего бы и вы не написали бы?). Мне вот интересно было бы посмотреть.
std::string rev(const std::string &s)
{
std::string r = s;
for (auto i = 0U, len = s.size(); i < len/2; ++i)
std::swap(r[i], r[len - i - 1]);
return r;
}
про std::reverse я в курсе, но на память не помню, что он принимает.
Здравствуйте, landerhigh, Вы писали:
L>В том-то и дело, что тут мы "знаем" тип B, точнее, о нем за нас "знает" shared_ptr.
Тут его знаем не мы, а шаред-птр, что вещи немного разные.
L>Вот когда у тебя уже есть только IInterface* pPointer, да без виртуального деструктора, и ничего больше, как будешь выкручиваться?
Ну вестимо обращаться к тому, кто мне его дал. Вероятно там предусмотрена процедура его удаления. А если не предусмотрена — то стоит ли его мне вообще удалять? МОжет быть он удалится автоматом при удалении какого-то другого объекта?
И только если я точно знаю, что тут косяк у автора библиотеки, который не предусмотрел удаление, и не могу поправить исходный код и согласен при каждом новом выпуске библиотеки проверять это место на предмет того, не добавились ли новые типы-наследники IInterface и не поменялась ли иерархия наследования (а ведь проверить это не имея кода — невозможно. А если код есть, то его можно поправить), и библиотека настолько ценна, что я не могу от нее отказаться — вот только тогда я сделаю кучу динамик-кастов.
Кстати если мы все еще про эмбеддинг — то часто динамик-каста там нет... Кроме того, готовые скомпилированные библиотеки для эмбеддинга — редкость. Слишком большой зоопарк компиляторов и их опций.
Здравствуйте, maxkar, Вы писали:
M>Плюс обязательная обработка таймаутов. Вы же сами хотели кормить неверный ввод, а ошибки в передаче на устройство более важная проблема.
Проверка таймаутов нужна далеко не всегда. Особенно подчиненному устройству. Во многих протоколах начало пакета четко определяется и таймауты не нужны.
E>>Опять таки все зависит от протокола. В данном конкретном достаточно таблицы команда — функция-обработчик E>>Если реализовать ее не в виде switch, то можно будет добавлять новые команды динамически — например в зависимости от конфигурации. Или на одном хоботе поддерживать одни команды, а на другом — другие.
M>А почему в виде таблицы?
Потому что проще добавить новую команду в рантайме, если есть таблица указателей на обработчики. а не фиксированный свитч. M>Почему от конфигурации?
Потому что задачи разные, сегодня одна, завтра другая. Иногда проще иметь общий код и конфигурацию, а не два свитча. M>Может, их нужно вообще с устройством согласовывать на самом деле?
Не понял вопроса...
M>Кстати, а как устройство реагирует на неподдерживаемые (и неполностью полученные) команды?
Как описано в протоколе. На неподдерживаемые возвращает ошибку, не полностью полученные игнорирует
M>Вот исходя из всех этих вопросов и не понятно, почему кандидат должен прийти к тому решению, которое вы хотите. Для простейшей задачи (даже с добавлением) табличка обработчиков — типичный overengeneering, там для решения if/of или case'ов более чем достаточно (особенно если ввод ручками парсить и на ошибки проверять!). А для корректного выбора более сложной схемы недостаточно данных. С реальном устройстом и приложением чуть попроще, там и круг комад ограничен, и сценарии использования более-менее очевидны.
Я не хочу, чтобы он пришел к моему решению. Пусть придет к своему. Если оно будет правильным — т.е. при данном вводе даст правильный вывод, то дальше можно дискутировать — об архитектуре, о стиле...
Еще раз повторяю — это не тест, это разговор...
Здравствуйте, Eugeny__, Вы писали:
E__>Нормальная реализация failover в рамках даже довольно простого протокола уже несколько выходит за пределы "простой задачи на пару часов". В рамках чуть более сложного — это уже реальная задача, решать которую нахаляву — глупость. В немалой степени из-за того, что в доках к девайсам я _никогда_ не видел полного описания всех возможных flow, остальное додумывать и доделывать самому. Может, ТС живет в мире эльфов, и там всегда есть более чем развернутая документация по устройствам. Я живу в реальном мире, где иногда единственное, что есть — это двойной автоперевод китайский-->английский-->русский(без оригиналов, есть в наличии только этот "русский" вариант), и несколько логов с перепиской каких-то индусов с кошмарным английским... Как хорошо, что хотя-бы цифры во всех языках одинаковы.
Протокол, который я прошу реализовать (а точнее его часть) — очень простой. Кроме того, он наш собственный, дока на него весьма проста, подробна и на русском. Про то, что протоколы бывают разные — я как бы в теме, лет 5 уже ими занимаюсь
Более того, даже если два устройства работают по одному протоколу, они могут быть не совместимы — например первое делали немцы, а второе — турки. И каждый понял исходный американский протокол по своему
Здравствуйте, Eugeny__, Вы писали:
E__>А теперь вопрос: если человек нормально отвечает и рассказывает все нюансы при использовании volatile, стоит ли его грузить унылыми вопросами про переворот строки и прочим? Может ли человек, понимающий, как работает этот барьер памяти на уровне разных архитектур, не понимать указателей? Или чего-то еще?
Ок, согласен. Стоит упорядочить от сложного к простому
Здравствуйте, enji, Вы писали:
E__>>Напишите свою, если не сложно(ну, кандидат-то должен, отчего бы и вы не написали бы?). Мне вот интересно было бы посмотреть.
E>
E>std::string rev(const std::string &s)
E>{
E> std::string r = s;
E> for (auto i = 0U, len = s.size(); i < len/2; ++i)
E> std::swap(r[i], r[len - i - 1]);
E> return r;
E>}
E>
E>про std::reverse я в курсе, но на память не помню, что он принимает.
Я не зря уточнил про чтение и запись в файл.
Меня, в частности, интересует корректность работы алгоритма с разными хитрыми юникодами(особенно всякие диакритики и суррогаты). Там все оказывается не совсем просто.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Я не зря уточнил про чтение и запись в файл. E__>Меня, в частности, интересует корректность работы алгоритма с разными хитрыми юникодами(особенно всякие диакритики и суррогаты). Там все оказывается не совсем просто.
Ну батенька, куда нам до юникодов. Нам по простому, в ascii
Но если кандидат спросит про юникод — честь и хвала ему.
А кстати да, ведь как только начинается юнокод, задача сразу становится нетривиальной. Там символ может быть выражен несколькими "кодовыми точками" (или как она правильно называются)...
E__>>Я не зря уточнил про чтение и запись в файл. E__>>Меня, в частности, интересует корректность работы алгоритма с разными хитрыми юникодами(особенно всякие диакритики и суррогаты). Там все оказывается не совсем просто.
E>Ну батенька, куда нам до юникодов. Нам по простому, в ascii E>Но если кандидат спросит про юникод — честь и хвала ему.
E>А кстати да, ведь как только начинается юнокод, задача сразу становится нетривиальной. Там символ может быть выражен несколькими "кодовыми точками" (или как она правильно называются)...
Ну а вдруг человек раньше плотно работал с юникодом? Ты-то про ascii в задании не упомянул! А как раз задача реверснуть строку в случае юникода становится именно что не особо тривиальной — твой алгоритм превратит строку в кашу. Потому он будет думать о написании переворота юникода, и может вполне не вспомнить все нюансы, потому скажет "без компа не смогу выполнить это задание". А ты подумаешь, что он банально байты поменять местами не умеет .
Мораль простая — точнее описывать задания.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Ну а вдруг человек раньше плотно работал с юникодом? Ты-то про ascii в задании не упомянул! А как раз задача реверснуть строку в случае юникода становится именно что не особо тривиальной — твой алгоритм превратит строку в кашу. Потому он будет думать о написании переворота юникода, и может вполне не вспомнить все нюансы, потому скажет "без компа не смогу выполнить это задание". А ты подумаешь, что он банально байты поменять местами не умеет . E__>Мораль простая — точнее описывать задания.
Может быть. Но в этой ветке к примеру только ты вспомнил про юникод Мне все же кажется, что человек перед тем как начать думать над явно нетривиальным алгоритмом, задаст вопрос. Хотя конечно, стоит уточнить
Здравствуйте, enji, Вы писали:
E>Здравствуйте, maxkar, Вы писали:
M>>Плюс обязательная обработка таймаутов. Вы же сами хотели кормить неверный ввод, а ошибки в передаче на устройство более важная проблема. E>Проверка таймаутов нужна далеко не всегда. Особенно подчиненному устройству. Во многих протоколах начало пакета четко определяется и таймауты не нужны.
Не понял. Если к подчиненному устройству ничего не подключить, оно у вас зависнет намертво (потому что ответа не получает)? Или как? Таймауты нужны не потому, что нужно определять начало/конец пакета. Таймату нужны, чтобы программа не зависала в следующих случаях:
* Устройство не подключено (пакеты уходят, но не приходят). Это если линия связи не поддерживает состояние "установлено соединение".
* Подключено другое устройство. Оно спокойно съело ваш пакет и ждет еще, ничего не отвечая.
* Устройство чем-то ответило, но в ответе нет маркеров начала/конца пакета.
* Пришла только часть ответа устройства, а остальная не пришла из-за нарушения канала связи (очень похоже на предыдущий варинат).
И во всех этих случаях если читать ответ от устройства на блокирующем канале без таймаутов, у вас драйвер зависнет навсегда. Кроме того, у вас в задаче драйвер пишется не для подчиненного, а для ведущего устройства (там управление с консоли вроде бы было). Это те сценарии, где ваш "автотестер" который вместо кривых пакетов вообще ничего не отвечает. Это вполне вероятная ситуация для устройств.
E>>>Опять таки все зависит от протокола. В данном конкретном достаточно таблицы команда — функция-обработчик E>>>Если реализовать ее не в виде switch, то можно будет добавлять новые команды динамически — например в зависимости от конфигурации. Или на одном хоботе поддерживать одни команды, а на другом — другие.
M>>А почему в виде таблицы? E>Потому что проще добавить новую команду в рантайме, если есть таблица указателей на обработчики. а не фиксированный свитч. M>>Почему от конфигурации? E>Потому что задачи разные, сегодня одна, завтра другая. Иногда проще иметь общий код и конфигурацию, а не два свитча. M>>Может, их нужно вообще с устройством согласовывать на самом деле? E>Не понял вопроса...
Последнее — это когда нужно понять, какая ревизия устройства, и автоматически определить набор команд.
По всем пунктам выше. Они не были в исходной задаче. Зато там было сформулировано "Предусмотрите возможность добавления новых команд". И оно никак к тому выше отношения не имеет. Для этого нужно знать предметную область или хотя бы конкретную задачу.
M>>Кстати, а как устройство реагирует на неподдерживаемые (и неполностью полученные) команды? E>Как описано в протоколе. На неподдерживаемые возвращает ошибку, не полностью полученные игнорирует
M>>Вот исходя из всех этих вопросов и не понятно, почему кандидат должен прийти к тому решению, которое вы хотите. Для простейшей задачи (даже с добавлением) табличка обработчиков — типичный overengeneering, там для решения if/of или case'ов более чем достаточно (особенно если ввод ручками парсить и на ошибки проверять!). А для корректного выбора более сложной схемы недостаточно данных. С реальном устройстом и приложением чуть попроще, там и круг комад ограничен, и сценарии использования более-менее очевидны. E>Я не хочу, чтобы он пришел к моему решению. Пусть придет к своему. Если оно будет правильным — т.е. при данном вводе даст правильный вывод, то дальше можно дискутировать — об архитектуре, о стиле...
А к чему тогда фраза про "предусмотрите возможность добавления новых команд"? Она выглядит так, как будто работодатель чего-то хочет, но сам не может объяснить, чего именно. Причем по виду вопроса видно, что он на самом деле хочет конкретного решения. А нужно описывать исходную проблему. Вот как вы отнесетесь к вопросу кандитада "для чего предусматривать возможность добавления новых команд" вместо выполнения задания? А ведь именно ответ на этот вопрос должен быть в постановке задачи. И уже из самой задачи будет понятно, нужно ли там "добавление новых команд". Может, будут еще куча вариантов решения именно той, исходной, задачи.
Здравствуйте, enji, Вы писали:
L>>В том-то и дело, что тут мы "знаем" тип B, точнее, о нем за нас "знает" shared_ptr. опровоп E>Тут его знаем не мы, а шаред-птр, что вещи немного разные.
Не вижу никакой разницы. Главное то, что конкретный тип объекта или конкретный удалятор известен. Что в корне меняет суть изначального вопроса.
L>>Вот когда у тебя уже есть только IInterface* pPointer, да без виртуального деструктора, и ничего больше, как будешь выкручиваться? E>Ну вестимо обращаться к тому, кто мне его дал. Вероятно там предусмотрена процедура его удаления. А если не предусмотрена — то стоит ли его мне вообще удалять? МОжет быть он удалится автоматом при удалении какого-то другого объекта?
вот ты сам и ответил на свой вопрос. А правильный ответ будет "не надо заниматься ерундой, а надо добавить виртуальный конструктор. Если нельзя (интерфес не наш) — ищи варианты". Вариантов уже озвучили кучу.
В дальнейшем я говорю с т.зр подчиненного устройства. ТЗ как раз и состоит в его реализации.
M>>>Плюс обязательная обработка таймаутов. Вы же сами хотели кормить неверный ввод, а ошибки в передаче на устройство более важная проблема. E>>Проверка таймаутов нужна далеко не всегда. Особенно подчиненному устройству. Во многих протоколах начало пакета четко определяется и таймауты не нужны. M>Не понял. Если к подчиненному устройству ничего не подключить, оно у вас зависнет намертво (потому что ответа не получает)?
Протокол типа запрос-ответ. Если к подч устройству ничего не подключить, то оно не получит ответа и не будет формировать запросов. Если подключить и тут же отключить, то если устройство успеет получить запрос, оно выплюнет ответ. При этом ему все равно, получен ответ или нет. Если ответ не может быть получен, он просто уйдет в пустоту.
M> * Устройство не подключено (пакеты уходят, но не приходят). Это если линия связи не поддерживает состояние "установлено соединение".
Линия связи в данном конкретном случае RS232, без доп сигналов — только RX\TX M> * Подключено другое устройство. Оно спокойно съело ваш пакет и ждет еще, ничего не отвечая.
Это его проблемы. А не подчиненного устройства. Подчиненное устройство просто отвечает на правильные запросы правильными ответами и делает свою работу. M> * Устройство чем-то ответило, но в ответе нет маркеров начала/конца пакета.
Это как? Подчиненное устройство ответило, но нет маркеров? Ну значит в программе бага, надо ее править. M> * Пришла только часть ответа устройства, а остальная не пришла из-за нарушения канала связи (очень похоже на предыдущий варинат).
Опять таки проблемы мастера. Если ему это важно, он может переспросить или считать состояние. M>И во всех этих случаях если читать ответ от устройства на блокирующем канале без таймаутов, у вас драйвер зависнет навсегда.
Мы говорим про реализацию подчиненного устройства, а не мастера. Кроме того, в реальном устройстве чтение вообще-то идет в отдельном потоке, не мешая работе всего остального. Конкретно в данной тестовой задаче не подразумевается "ничего остального", поэтому используется обычное блокирующее чтение из консоли, без всяких потоков. M> Кроме того, у вас в задаче драйвер пишется не для подчиненного, а для ведущего устройства (там управление с консоли вроде бы было).
Нет, для подчиненного. Которое управляется с консоли и плюет ответы в консоль
M>>>Вот исходя из всех этих вопросов и не понятно, почему кандидат должен прийти к тому решению, которое вы хотите. M>>>Для простейшей задачи (даже с добавлением) табличка обработчиков — типичный overengeneering, там для решения if/of или case'ов более чем достаточно (особенно если ввод ручками парсить и на ошибки проверять!).
Еще раз, самый последний — я не прошу кандидата прийти к моему решению. Это невозможно в принципе — у меня один опыт, у него другой.
Задача то простейшая, но я прошу подумать над определенными вопросами. Дальше, имея реализацию кандидата, с ним можно обсуждать его решения. Почему он решил так, а не иначе, в чем плюсы, в чем минусы.
Вот ты говоришь — сделать switch, этого достаточно. Может быть и да. А если добавится новая команда? А если в одном варианте потребуется поддержать такие команды, в в другом — другие?
Или например — разделит ли кандидат уровень сборки пакета из байт и уровень обработки? Насколько они у него получатся связанными? А если к примеру завтра RS-232 сменится на UDP и структура пакетов на канальном уровне поменяется (вполне реальная задача кстати)? А если потребуется совершенно другой протокол, но с той же логикой формирования пакетов — можно ли будет использовать часть имеющегося кода, или потребуется его переписывание?
Все это вопросы для обсуждения.
M>А к чему тогда фраза про "предусмотрите возможность добавления новых команд"? Она выглядит так, как будто работодатель чего-то хочет, но сам не может объяснить, чего именно.
Ты не поверишь, это самая обычная рабочая ситуация. От меня чего-то хотят, мне надо включать мозг и думать — а если я сделаю вот так и они захотят вот того — как я буду выкручиваться? А если сделать по другому?
Здравствуйте, landerhigh, Вы писали: L>Не вижу никакой разницы. Главное то, что конкретный тип объекта или конкретный удалятор известен. Что в корне меняет суть изначального вопроса. L>вот ты сам и ответил на свой вопрос.
Ну ничего страшного в этом нет. Это не тест, а живое общение. Предположим, меня не так поняли и озвучили мягко говоря странный вариант с кучей dynamic_cast-ов. Начнем разбираться, почему. Поговорим об этом, заодно выясним уровень кандидата в таких вещах.
L>А правильный ответ будет "не надо заниматься ерундой, а надо добавить виртуальный конструктор. Если нельзя (интерфес не наш) — ищи варианты".
Да неужели? Правильный ответ вообще-то зависит от задачи. Возможно этот интерфейс просто не требует удаления
Здравствуйте, Eugeny__, Вы писали:
E__>Ну, в си(++?) качество кода может решать больше, чем в более привычных мне языках(слишком много нюансов). На той же жабе, где "как думается, так и пишется", вполне достаточно оценить общий уровень, смотреть на код не особо есть смысл — там трудно написать как-то по-извращенному. Ну а если человек понимает некоторые важные моменты, то врядли у него плохое качество кода.
Вот тут я не вполне согласен. Часто доводилось видеть на Java нечто подобное:
public int businessLogic() throws Exception()
{
try {
// 100500 строк кода
}
catch (Exception ex) {}
}
В метод func запихнули весь бизнес-процесс. Причем не вчерашний студент писал. А рассуждает вполне логично.
Более того, если писать (непереносимо) скажем под 8-битник, это просто и работает. Задача типичная для нас — положить число в буфер байт и выплюнуть его наружу. Как это лучше сделать и почему мой способ кривой — вполне тема для разговора
