Здравствуйте, landerhigh, Вы писали:
L>>>Что касается структур данных, то тут можно вспомнить классическое "правило" 80/20: >80% кейсов покрываются именно векторами, хеш-мапами и упорядоченными мапами. S>>Золотые слова. Вот прям спасибо.
Просто состим и ты нихрена не понимаете в алгоритмах. А потом ещё обижаетесь на мою формулировку "не понимают в алгоритмах, но мастурбируют на шаблоны".
L>Кстати, добавлю — недавно понадобилось иметь std::map или std::set, который заполняются лишь однажды и потом почти никогда не модифицируются, но в котором нужно очень иногда искать по ключу, но постоянно приходится просто итерировать. L>В закромах буста обнаружился flat_map и flat_set. Вот прям что надо было.
flat_map is similar to std::map but it's implemented like an ordered vector.
Здравствуйте, landerhigh, Вы писали:
SVZ>>Делается легко и непринуждённо.
+1
L>Но раз велосипед уже изобретен в бусте, то почему бы его и не использовать?
Потому, что бинарный поиск нужно знать, чтоб от зубов отскакивало. Даже в STL есть lower/upper bound, и оно работает даже без всяких векторов.
Здравствуйте, so5team, Вы писали:
Тё>>sentinel иницировать в конструкторе: Тё>>sentinel.next = sentinel.prev = sentinel.
S>За такие инициализации в конструкторе в C++ со времен 1990-х по рукам бъют. Но откуда вам знать-то.
Хм, это почему же? Где ещё такую инициализацию делать, как не в конструкторе списка?
Здравствуйте, so5team, Вы писали:
S>Кроме того, приведенный выше код можно считать документально зафиксированным подтверждением того, что местный Тёмчик говнокодер, неспособный в простейшие структуры данных. Ибо такая наивная реализация изъятия элемента из двусвязного списка без проверки на null значений node.prev/node.next -- это про*б сравнимый с неспособностью развернуть строку. Тёмчик, почему меня не удивляет факт того, что вы говнокодер?
А вы нечитатель, после того, как слово "sentinel node" промелькнуло в этой подветке минимум пять раз. Тут про*б ваш, а не его.
(В основном согласен с остатком письма. В целом в тред не хочу глубоко влезать, слишком много бессмысленных метаний с обеих сторон.)
Здравствуйте, netch80, Вы писали:
Тё>>>sentinel иницировать в конструкторе: Тё>>>sentinel.next = sentinel.prev = sentinel.
S>>За такие инициализации в конструкторе в C++ со времен 1990-х по рукам бъют. Но откуда вам знать-то.
N>Хм, это почему же? Где ещё такую инициализацию делать, как не в конструкторе списка?
В списке инициализации конструктора, а не в теле конструктора. Т.е.
Здравствуйте, netch80, Вы писали:
N>А вы нечитатель, после того, как слово "sentinel node" промелькнуло в этой подветке минимум пять раз. Тут про*б ваш, а не его.
100% мой. По ссылке Тёмчика не ходил, а в самой ссылке обратил внимание только на финальную часть, которая про linked-list-implementation.
Здравствуйте, so5team, Вы писали:
Тё>>>>sentinel иницировать в конструкторе: Тё>>>>sentinel.next = sentinel.prev = sentinel. S>>>За такие инициализации в конструкторе в C++ со времен 1990-х по рукам бъют. Но откуда вам знать-то. N>>Хм, это почему же? Где ещё такую инициализацию делать, как не в конструкторе списка? S>В списке инициализации конструктора, а не в теле конструктора. Т.е.
[...] S>Надеюсь, почему атрибутам следует присваивать значения в списке инициализации, а не в теле конструктора, объяснять не нужно.
Ну в данном случае откровенно без разницы. Разве что чтобы "не сбивать руку".
Здравствуйте, netch80, Вы писали:
N>Ну в данном случае откровенно без разницы.
Это отличный индикатор уровня владения инструментом. Такие вещи должны быть доведены до автоматизма, как и расстановка const-ов и nodiscard в должных местах.
Здравствуйте, so5team, Вы писали:
N>>Ну в данном случае откровенно без разницы.
S>Это отличный индикатор уровня владения инструментом. Такие вещи должны быть доведены до автоматизма, как и расстановка const-ов и nodiscard в должных местах.
Безотносительно уровня владения инструментом, утечки памяти в связи с исключением в конструкторе, там быть не может. Вы ведь помните, из-за чего все эти прыжки со скакалкой в C++, правда?
Здравствуйте, Тёмчик, Вы писали:
S>>Это отличный индикатор уровня владения инструментом. Такие вещи должны быть доведены до автоматизма, как и расстановка const-ов и nodiscard в должных местах.
Тё>Безотносительно уровня владения инструментом,
В данном конкретном вашем случае нет "безотносительно". Вы откровенно не владеете инструментом, о возможностях и перспективах которых здесь делаете столь громкие заявления.
Тё>утечки памяти в связи с исключением в конструкторе, там быть не может. Вы ведь помните, из-за чего все эти прыжки со скакалкой в C++, правда?
Продолжаете расписываться в непонимании C++? Верной дорогой.
Списки инициализации важны не только для обеспечения exception safety (как и exception safety важна не только для предотвращения утечек памяти). Но и для того, чтобы в теле конструктора не задействовать случайно неинициализированные должным образом поля объекта. Что запросто может произойти по мере эволюции кодовой базы. Поэтому тот, кто не использует в C++ списки инициализации, тот, скорее всего, просто еще не осознал, что "уставы пишутся кровью". Вот как вы.
Возможно, имей вы опыт развития продукта в течении долгого времени, то не несли бы такой откровенной херни. Но ведь вы же как попрыгунья-стрекоза: "интересно делать новые проекты, изучать новые технолигии, (старые) алгоритмы, и т.д."
S>Списки инициализации важны не только для обеспечения exception safety (как и exception safety важна не только для предотвращения утечек памяти). Но и для того, чтобы в теле конструктора не задействовать случайно неинициализированные должным образом поля объекта. Что запросто может произойти по мере эволюции кодовой базы. Поэтому тот, кто не использует в C++ списки инициализации, тот, скорее всего, просто еще не осознал, что "уставы пишутся кровью".
В С++ считается хорошем стилем все поля класса инициализировать через списки инициализации? Добавил поле — автоматически добавил : m_value(a_value) во все конструкторы? Просто присваивания в теле конструктора считаются более error prone?
Здравствуйте, so5team, Вы писали:
S>В данном конкретном вашем случае нет "безотносительно". Вы откровенно не владеете инструментом, о возможностях и перспективах которых здесь делаете столь громкие заявления.
Тё>>утечки памяти в связи с исключением в конструкторе, там быть не может. Вы ведь помните, из-за чего все эти прыжки со скакалкой в C++, правда?
S>Продолжаете расписываться в непонимании C++? Верной дорогой.
S>Списки инициализации важны не только для обеспечения exception safety (как и exception safety важна не только для предотвращения утечек памяти). Но и для того, чтобы в теле конструктора не задействовать случайно неинициализированные должным образом поля объекта. Что запросто может произойти по мере эволюции кодовой базы. Поэтому тот, кто не использует в C++ списки инициализации, тот, скорее всего, просто еще не осознал, что "уставы пишутся кровью". Вот как вы.
Не вижу в том коде возможности "задействовать случайно неинициализированные должным образом поля объекта". У вас профессиональная деформация, наверное. Учите лучше алгоритмы, ну там, хоть строку чтоб могли развернуть, это всё.
S>Возможно, имей вы опыт развития продукта в течении долгого времени, то не несли бы такой откровенной херни. Но ведь вы же как попрыгунья-стрекоза: "интересно делать новые проекты, изучать новые технолигии, (старые) алгоритмы, и т.д."
Предпочитаю брать самую сложную фичу "если не я, то кто", и выполнять её. Потом можно оставить состимам на суппорт.
Здравствуйте, so5team, Вы писали:
S> Но ведь вы же как попрыгунья-стрекоза: "интересно делать новые проекты, изучать новые технолигии, (старые) алгоритмы, и т.д."
А вот тут обидно было (вспоминая портянку языков с которыми работал последние 10 лет )
Здравствуйте, Максим, Вы писали:
М>В С++ считается хорошем стилем все поля класса инициализировать через списки инициализации? Добавил поле — автоматически добавил : m_value(a_value) во все конструкторы?
Да. К счастью, начиная с C++11 дефолтными значениями можно инициализировать прямо по месту объявления поля. И в C++11 делегирующие конструкторы позволяют уменьшить количество мест в самих конструкторах, где нужно что-то инициализировать явно.
Неинициализированные поля можно оставлять только по показаниям профайлера.
М>Просто присваивания в теле конструктора считаются более error prone?
Здравствуйте, kaa.python, Вы писали:
S>> Но ведь вы же как попрыгунья-стрекоза: "интересно делать новые проекты, изучать новые технолигии, (старые) алгоритмы, и т.д."
KP>А вот тут обидно было (вспоминая порядку языков с которыми работал последние 10 лет )
Так ведь некоторые за год умудряются вобрать в себя больше, чем иные за три. Так что тут все индивидуально.
Здравствуйте, so5team, Вы писали:
S>Так ведь некоторые за год умудряются вобрать в себя больше, чем иные за три. Так что тут все индивидуально.
Самокритично.
