Согласен. Абстрактную ситуацию представить легко. И не исключаю, что это где-то применимо. Но пока ещё не видел реально хорошего кейса. Всегда код можно было бы порефакторить в лучшую сторону.
Ну я скорее конкретно этот момент прокомментировал. Понятно, что это не единственная проблема. Например ещё код обработки сильно переплетался с бизнес-логикой. И разные другие неприятности.
Очевидно с таким способом можно жить, если немножко сознательности проявлять. В go вот живут.
[[nodiscard]]это C++11. Исключения же проектировались раньше.
По поводу штук вроде __attribute__((warn_unused_result)). Насколько я знаю, это расширения компиляторов -> писать кроссплатформенный код становится гораздо неприятнее.
Непонятно, в чём проблема. Если один разработчик говорит "вещественное число", а второй его понимает (и в данном случае это верно для абсолютного числа адекватных разработчиков из двух любых точек мира), то терминология работает. А что там формальная математика говорит, никого волновать не должно.
Векторы смежности и массивы смежности кмк идиоматически должны быть наоборот: чаще всего в языках программирования массивы статического размера, тогда как векторы динамического.
Вообще векторы смежности и списки смежности почти всегда (на самом деле по опыту всегда, ни разу не слышал разделения на массивы/векторы/списки смежности) называются списками смежности. А как вы их реализуете (через векторы, массивы или списки) уже детали. Структура с оглавлением по факту тот же список смежности, только опять же реализованный неким другим образом.
Кажется, во всех алгоритмических вопросах достаточно понять концепцию, а реализовывать исходя из нужд задачи. Тут же получается, что новичок, прочтя вашу статью, станет пытаться вникнуть во все описанные подходы, что может только запутать из-за их большого количества. Хотя по факту, описав лишь концепции, можно было бы сократить статью вдвое. И это позволило бы накинуть больше информации о том, когда те или иные подходы оказываются полезными, а когда нет.
Можно попробовать каждые операций пересчитывать ответ, чтобы отвечать на запрос за единицу, а неучтённые новые запросы (которых до корня) обрабатывать втупую.
Ух. Когда-то книжка дала базу для олимпиад по информатике. Не то чтобы я сразу научился во все таски, но понял, что даже сложные алгоритмы могут быть простыми и понятными при должном подходе, после чего стал искать для всех непонятных действий такие объяснения. Простые, может даже глупые, но которые работают. И как-то пошло)
Если вы в районе нуля, это хорошая отправная точка. Хотя бы понять зачем это и как.
Хотелось бы отметить два момента: расмотренные аллокаторы всё же называются аллокаторами, более того, это довольно стандартные для мира C++ вещи (хотя местами может даже и для C). Да, это прослойка между стандартной библиотекой и системой, но нельзя же утверждать, что аналогичные методы не применимы в проектировании ваших аллокаторов, но уже более высокоуровнево?)
Задачей стояло пройтись по известным аллокаторам и разобрать их концептуально. С технической точки зрения они разобраны уже во множестве источников, потому повторяться не хотелось бы. Если у вас есть какие-то ссылки на источники про аллокаторы в вашем понимании, можете поделиться. Разберёмся и с ними.
Да. Некоторые аллокаторы (кстати, довольно эффективные) таким и занимаются. Например jemalloc, который хранит информацию о самых больших аллокациях в красно-чёрном дереве.
Тогда понятно. Но какой-то очень странный график, как заметил@WASD1. И непонятно, какую мысль автор хотел донести. Не делать большие пр? Ну наверн надо бы написать это.
Не очень понял табличку про ограничение размера code review. Это какая-то зависимость кол-ва комментариев от кол-ва строк? Почему она обратная?
Ещё немножко критики по поводу ревью по времени. Обычно, приглашая кого-то посмотреть код, ты делаешь это из соображений, что человек знает ситуацию чуть лучше тебя/других в конкретном месте, где делается новый pr. Ну и смена ревьюера в течение дня может негативно повлиять на некоторые комментарии(2й ревьюер банально не поймёт, что имел в виду 1й). Учитывая, что в большинстве систем контроля версий есть block merge или какой-нибудь request changes получается не очень эффективное привлечение коллег. Ещё, во времена удалёнки и свободных графиков, такой подход может привести к неравномерному распределению нагрузки.
Да, есть некоторые проблемы с производительностью owns при выделении нескольких блоков. Возможно, есть какие-то оптимизации, но мне про них не известно.
По поводу mmap. Я, честно говоря, не знаю специфики этого метода, потому не очень понял проблему(не он ли лежит под malloc/new в linux? если так, то не понял проблему ещё больше, ведь c malloc/new таких вопросов не возникает). На мой обывательский взгляд кажется, что он всё ещё вернёт мне какой-то блок, с границами которого и можно делать range-test. Или я всё-таки что-то упускаю? Если это не так, то да, могут возникнуть проблемы при реализации owns. Как это сделать эффективно в случае случайности адресов, не очень понятно.
А почему? Есть профит кроме читаемости?
Не вижу противоречий)
Согласен. Абстрактную ситуацию представить легко. И не исключаю, что это где-то применимо. Но пока ещё не видел реально хорошего кейса. Всегда код можно было бы порефакторить в лучшую сторону.
Ну я скорее конкретно этот момент прокомментировал. Понятно, что это не единственная проблема. Например ещё код обработки сильно переплетался с бизнес-логикой. И разные другие неприятности.
Очевидно с таким способом можно жить, если немножко сознательности проявлять. В go вот живут.
[[nodiscard]]это C++11. Исключения же проектировались раньше.По поводу штук вроде
__attribute__((warn_unused_result)). Насколько я знаю, это расширения компиляторов -> писать кроссплатформенный код становится гораздо неприятнее.Непонятно, в чём проблема.
Если один разработчик говорит "вещественное число", а второй его понимает (и в данном случае это верно для абсолютного числа адекватных разработчиков из двух любых точек мира), то терминология работает. А что там формальная математика говорит, никого волновать не должно.
Что-то вы немного странной инфы накрутили.
Векторы смежности и массивы смежности кмк идиоматически должны быть наоборот: чаще всего в языках программирования массивы статического размера, тогда как векторы динамического.
Вообще векторы смежности и списки смежности почти всегда (на самом деле по опыту всегда, ни разу не слышал разделения на массивы/векторы/списки смежности) называются списками смежности. А как вы их реализуете (через векторы, массивы или списки) уже детали. Структура с оглавлением по факту тот же список смежности, только опять же реализованный неким другим образом.
Кажется, во всех алгоритмических вопросах достаточно понять концепцию, а реализовывать исходя из нужд задачи. Тут же получается, что новичок, прочтя вашу статью, станет пытаться вникнуть во все описанные подходы, что может только запутать из-за их большого количества. Хотя по факту, описав лишь концепции, можно было бы сократить статью вдвое. И это позволило бы накинуть больше информации о том, когда те или иные подходы оказываются полезными, а когда нет.
Можно попробовать каждые
операций пересчитывать ответ, чтобы отвечать на запрос за единицу, а неучтённые новые запросы (которых до корня) обрабатывать втупую.
Держите задачу, где такая концепция является решением: https://codeforces.com/problemset/problem/342/E?locale=ru : )
Вы про получение случайного из множества? Там что-то более умное чем взять рандомный элемент на отрезке [0; n)?
Ух. Когда-то книжка дала базу для олимпиад по информатике. Не то чтобы я сразу научился во все таски, но понял, что даже сложные алгоритмы могут быть простыми и понятными при должном подходе, после чего стал искать для всех непонятных действий такие объяснения. Простые, может даже глупые, но которые работают. И как-то пошло)
Если вы в районе нуля, это хорошая отправная точка. Хотя бы понять зачем это и как.
Надеюсь, когда-нибудь они отключат обучение в течение всего процесса игры во всех молодых проектах..
Хотелось бы отметить два момента: расмотренные аллокаторы всё же называются аллокаторами, более того, это довольно стандартные для мира C++ вещи (хотя местами может даже и для C). Да, это прослойка между стандартной библиотекой и системой, но нельзя же утверждать, что аналогичные методы не применимы в проектировании ваших аллокаторов, но уже более высокоуровнево?)
Задачей стояло пройтись по известным аллокаторам и разобрать их концептуально. С технической точки зрения они разобраны уже во множестве источников, потому повторяться не хотелось бы. Если у вас есть какие-то ссылки на источники про аллокаторы в вашем понимании, можете поделиться. Разберёмся и с ними.
Берега попутал. Спасибо за замечание.
Да. Некоторые аллокаторы (кстати, довольно эффективные) таким и занимаются. Например jemalloc, который хранит информацию о самых больших аллокациях в красно-чёрном дереве.
Тогда понятно. Но какой-то очень странный график, как заметил@WASD1. И непонятно, какую мысль автор хотел донести. Не делать большие пр? Ну наверн надо бы написать это.
Не очень понял табличку про ограничение размера code review. Это какая-то зависимость кол-ва комментариев от кол-ва строк? Почему она обратная?
Ещё немножко критики по поводу ревью по времени. Обычно, приглашая кого-то посмотреть код, ты делаешь это из соображений, что человек знает ситуацию чуть лучше тебя/других в конкретном месте, где делается новый pr. Ну и смена ревьюера в течение дня может негативно повлиять на некоторые комментарии(2й ревьюер банально не поймёт, что имел в виду 1й). Учитывая, что в большинстве систем контроля версий есть block merge или какой-нибудь request changes получается не очень эффективное привлечение коллег. Ещё, во времена удалёнки и свободных графиков, такой подход может привести к неравномерному распределению нагрузки.
Не увидел замечательного блога cppstories.com . Сильнейше рекомендую его.
Да, есть некоторые проблемы с производительностью owns при выделении нескольких блоков. Возможно, есть какие-то оптимизации, но мне про них не известно.
По поводу mmap. Я, честно говоря, не знаю специфики этого метода, потому не очень понял проблему(не он ли лежит под malloc/new в linux? если так, то не понял проблему ещё больше, ведь c malloc/new таких вопросов не возникает). На мой обывательский взгляд кажется, что он всё ещё вернёт мне какой-то блок, с границами которого и можно делать range-test. Или я всё-таки что-то упускаю? Если это не так, то да, могут возникнуть проблемы при реализации owns. Как это сделать эффективно в случае случайности адресов, не очень понятно.