A>Такие разговоры надо вести предметно, чётко давая понять собеседнику до какой степени сам лично освоил STL. A>Например, довелось ли писать кастомные аллокаторы со своим вариантом дефрагментации кучи — задолбало то-то и то-то в этом вашем STL, а потому считаю его УГ... ну или типа того.
а есть хорошая статья или книжка как писать кастомные алокаторы
а то мне на собеседовании сказали написать а я не осилил
Здравствуйте, smeeld, Вы писали:
S>С++11. Причём, чуваки до меня написали в проекте многое, что есть сейчас в C++11 (лямбды, мувинг, emplace-ы) ещё во времена C++98 (начало 2000-ых). И их варианты удачней, чем то, что сейчас есть в STL.
Интересно было бы посмотреть, как выглядят самодельные лямбды для C++98, которые при этом удобнее, чем лямбды из C++11.
Но у вас есть привычка избегать хоть какой-либо конкретики, поэтому надежд увидеть пример не остается.
Здравствуйте, sergey2b, Вы писали:
S>а есть хорошая статья или книжка как писать кастомные алокаторы S>а то мне на собеседовании сказали написать а я не осилил
У аллокатора есть 2 основных метода: память дать и память забрать себе обратно. Тут ничего сложного. Вот откуда самому аллокатору брать память вопрос и простой, и нет. Можно монотонно выделять из заранее аллоцированного буфера: супер быстро, время аллокации постоянно, а в минусе фиксированный размер. Можно развить идею и динамически выделять дополнительные буфера: все еще быстро, но время аллокации уже недетерменированно. Затем можно захотеть возвращенную память переиспользовать, а это за собой потянет еще массу вопросов и скоро все уже станет совсем непросто. Можно открыть исходники malloc и посмотреть как он устроен: всякие арены для блоков памяти разного размера и т.д., очень познавательно.
N>>>Я один раз работал в Яндексе, но собеседований не проходил, кроме как личной беседы с Воложем. Возможно могу ещё раз устроиться, и тоже без собеседований, т.к. судя по тому, что слышал — врядли их пройду. B>>Программистом? N>Ага.
При этом уже много лет тут рассказываешь, какой ты крутой ПМ. Не сходятся концы.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, %, Вы писали:
A>Подавляющую массу С++ кода можно переписать на Go, упростив и развёртывание и снизив плотность багов. Однако это дорого и не нужно: «работает — не трогай».
Так в Go до сих пор GC без поколений, разве нет? То есть если
есть куча объектов одновременно, то будет тормозить.
Плюс обработка ошибок не лучше чем исключения, в плане того что всегда можно пропустить
или забыть это вечно `err != nil` по-моему даже std::variant<OkType, ErrType> лучше,
он заставит пользователя подумать о том, чтобы оба варианта обработать
Здравствуйте, Lexey, Вы писали:
DI>>Так они же (вторая секция) на студентов и рассчитаны
L>Нет, конечно.
Да, конечно. Во-первых, свежая голова не замутненная ненужными размышлениями, во-вторых, только-только закончился курс по алгоритмам, в-третьих, достаточно времени и мотивации для того что-бы потренироваться на хакеррранк и подобном.
Здравствуйте, a7d3, Вы писали:
A>Т.е. людям начхать на технический долг, на высокую связность и хрупкость архитектуры.
Или не начхать.
A>Именно так и приходится работать с олимпиадниками и другими «ковбоями». Которые не умеют в ООА, ООД, а различные паттерны ну никак не могут связать с тем же SOLID.
Здравствуйте, Denis Ivlev, Вы писали:
DI>Да, конечно. Во-первых, свежая голова не замутненная ненужными размышлениями, во-вторых, только-только закончился курс по алгоритмам, в-третьих, достаточно времени и мотивации для того что-бы потренироваться на хакеррранк и подобном.
Нет, конечно. Кроме знания базовых алгоритмов, как минимум, оценивается еще умение писать качественный код, находить ошибки в собственном коде и задавать правильные вопросы. И тут у студентов, обычно, все хуже, чем у опытных разработчиков.
Здравствуйте, sergey2b, Вы писали:
S>во последних двух конторах были запрещены к использованию S>исключения S>темплейты S>stl
S>а теперь расскажи плиз как мне делать контейнеры для новых типов
Создавай абстрактные классы-интерфейсы, наследуй любой реальный новый тип от них, разрабатывай структуры-контейнеры для управления упомянутыми базовыми классами, помещай туда наследованные от них "реальные" новые типы.
В итоге получится: читабельней, чем с темплейтами. Исключения-это для исключительных ситуаций, если их использовать на каждом шагу в коде-это снизит производительность, так как throw-это дорогая операция. Также для обработки исключений, генерируется куча бинарного кода.
Здравствуйте, Lexey, Вы писали:
L>Нет, конечно. Кроме знания базовых алгоритмов, как минимум, оценивается еще умение писать качественный код, находить ошибки в собственном коде и задавать правильные вопросы. И тут у студентов, обычно, все хуже, чем у опытных разработчиков.
Да, конечно. Качественный код — это код с хорошим тестовым покрытием, понятный и простой в модификации. Ни того, ни другого на бумажке в задаче типа "заполнить матрицу неким значением по спирали" не продемонстрировать. Причем таких задачек надо решить как я понял не менее 3 за час. А находить ошибки должен компьютер, разработчик должен просто написать адекватные тесты и для эксплуатации осмысленные логи и метрики, что опять продемонстрировать возможности нет.
Здравствуйте, sergey2b, Вы писали:
S>а есть хорошая статья или книжка как писать кастомные алокаторы S>а то мне на собеседовании сказали написать а я не осилил
В STL, так называемый, кастомный аллокатор-это класс, предоставляющий несколько предопределённых методов. Накидать определение класса-это пять минут. А вот расписать саму логику управления памятью-это точно не для собеседования, и не для тестового задания. Сама задача управления памятью-это обширная проблема. Об этом не написано книг, статей, букварей, кроме или простейших, касающихся только поверхностно некоторых вещей из темы, или слишком обобщённых. Для погружения в тему советую почитать исходники реализаций менеджера памяти в libc, например (то, что стоит за фасадом malloc-а), а ещё лучше, поизучать реализацию менеджеров пямятив ядрах OS, linux-а, например.
DI>Да, конечно. Качественный код — это код с хорошим тестовым покрытием, понятный и простой в модификации. Ни того, ни другого на бумажке в задаче типа "заполнить матрицу неким значением по спирали" не продемонстрировать. Причем таких задачек надо решить как я понял не менее 3 за час. А находить ошибки должен компьютер, разработчик должен просто написать адекватные тесты и для эксплуатации осмысленные логи и метрики, что опять продемонстрировать возможности нет.
а какого рода задача не оскорбляет профессиональное достоинство опытного разработчика? вариант — спросить про предыдущие проекты и глубокомысленно качать головой — не вариант
Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, a7d3, Вы писали:
A>>Т.е. людям начхать на технический долг, на высокую связность и хрупкость архитектуры.
L> Или не начхать.
A>>Именно так и приходится работать с олимпиадниками и другими «ковбоями». Которые не умеют в ООА, ООД, а различные паттерны ну никак не могут связать с тем же SOLID.
L>Нет, ты просто "не умеешь их готовить".
Конечно не умею, и ваш CTO тоже не умеет. О чём сам и говорит, что собеседования они проходить умеют замечательно, но вот работать у них получается хреново или вообще не получается.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, Denis Ivlev, Вы писали:
DI>>Да, конечно. Качественный код — это код с хорошим тестовым покрытием, понятный и простой в модификации. Ни того, ни другого на бумажке в задаче типа "заполнить матрицу неким значением по спирали" не продемонстрировать. Причем таких задачек надо решить как я понял не менее 3 за час. А находить ошибки должен компьютер, разработчик должен просто написать адекватные тесты и для эксплуатации осмысленные логи и метрики, что опять продемонстрировать возможности нет.
CK>а какого рода задача не оскорбляет профессиональное достоинство опытного разработчика? вариант — спросить про предыдущие проекты и глубокомысленно качать головой — не вариант
Например, поговорить о проблематики создания спецификаций кода отдельных подсистем, в рамках подготовки к использованию формальных методов валидации.
Так понимаю, что любители задачек на таком вопросе начнут мило хлопать глазками сидя на попе ровно.
Здравствуйте, Zhendos, Вы писали:
Z>Здравствуйте, a7d3, Вы писали:
A>>Здравствуйте, %, Вы писали:
A>>Подавляющую массу С++ кода можно переписать на Go, упростив и развёртывание и снизив плотность багов. Однако это дорого и не нужно: «работает — не трогай».
Z>Так в Go до сих пор GC без поколений, разве нет? То есть если Z>есть куча объектов одновременно, то будет тормозить.
Z>Плюс обработка ошибок не лучше чем исключения, в плане того что всегда можно пропустить Z>или забыть это вечно `err != nil` по-моему даже std::variant<OkType, ErrType> лучше, Z>он заставит пользователя подумать о том, чтобы оба варианта обработать
Не в курсе, без поколений или же их там два с половиной, как в дотнетах. Но вроде и не было никогда обоснования математического, что обязательно нужны во избежание пауз мира при большом количестве объектов. Т.е. не факт, что поколения обоснованно нужны для реализации сборщика мусора без эпизодических фризов. Если где-то есть обоснование, пусть даже сродни CAP-теоремы, то хотелось бы на него посмотреть.
Обработка ошибок и подходы к таковой всегда являются предметом острых баталий. Писать транзакционный код, соблюдая exception safety, способны далеко немногие, а реально научилось это делать так и гораздо меньшее количество «С++ пользователей».
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
A>>Такие разговоры надо вести предметно, чётко давая понять собеседнику до какой степени сам лично освоил STL. A>>Например, довелось ли писать кастомные аллокаторы со своим вариантом дефрагментации кучи — задолбало то-то и то-то в этом вашем STL, а потому считаю его УГ... ну или типа того.
S>а есть хорошая статья или книжка как писать кастомные алокаторы S>а то мне на собеседовании сказали написать а я не осилил
Начинать лучше всего вот с таких вещей https://www.youtube.com/watch?v=QDuXvJSMefA
Саша достаточно чётко расписывает спецификацию требований к аллокатору. В том числе и такие вещи как выедание ассоциативности кэша.
Это не так уж просто, ведь не только кэш-данных и кэш-кода в ЦПУ, но и надо помнить про TLB-кэш. Учитывая не только нюансы использования N-входов частично-ассоциативного кэша ЦПУ, но и нюансы работы механизмов виртуальной памяти на конкретной архитектуре.
Здравствуйте, a7d3, Вы писали:
A>Саша достаточно чётко расписывает спецификацию требований к аллокатору. В том числе и такие вещи как выедание ассоциативности кэша. A>Это не так уж просто, ведь не только кэш-данных и кэш-кода в ЦПУ, но и надо помнить про TLB-кэш. Учитывая не только нюансы использования N-входов частично-ассоциативного кэша ЦПУ, но и нюансы работы механизмов виртуальной памяти на конкретной архитектуре.
Это всё праздное симпозиумное балабольство. Когда у тебя под ногами несколько систем, занимающихся выделением тебе памяти, и всё что ты можешь-это как-то распорядиться выделенными тебе кусками, то учитывать нужно не только TLB или механизмы отображения выртуальных адресов в адреса страниц физической памяти, но и особенносьти реализации этих самых подсистем под ногами. Тут же получаются рассуждения о скорости бега, сидя в инвалидном кресле-твоя скорость в любом случае будет определяться скоростью того самого кресла.
Или не начхать.
