Наследование от стандартных контейнеров

Что же, неужели в наследовании от контейнеров может быть смысл?

Если результат наследования является контейнером, т.е. весь унаследованный API std::map имеет смысл для потомка, то все верно. Лучше чем копипастить все методы и пробрасывать 1:1

Суть не в том, что нельзя наследоваться, а в том, чтобы понимать чего нельзя делать в наследующем классе

Хотя бустеры по ходу все-таки облажались, они добавляют поля, в результате при уничтожении объекта по указателю на std::map произйдет утечка ресурсов

Не ожидается, что объекты этого класса будут создаваться динамически.

Класс используется как контейнер для разобранных опций командной строки и обычно создаётся как автоматический объект где-нибудь в main.

при уничтожении объекта по указателю на std::map

Это же шаблонный класс, какой ещё такой «указатель на std::map»?

Я думал что всем будет очевидно, что имеется в виду std::map<std::string, variable_value>

вопрос в целях. для program_options не важна скорость работы. ну не может у тебя быть миллиардов параметров для обработки. поэтому в данном конкретном случае можно использовать вообще что угодно и это не создаст проблем. и даже если будет какая-то утечка при одноразовом вызове - это не так страшно. ну а если дело касается действительно динамического распределения памяти и каких-то больших объёмов, то тут надо тщательно взвешивать каждое решение.

Или boost'еры что-то делают не так (не вообще, а в этом локальном случае)?

Тут ещё выворачивают приватный член интерфейса в паблик

  // private member functions
  virtual const variable_value & get(const std::string &) const;

они просто адаптируют не очень удачно реализованный шаблон под свои нужды. в плюсах нет никаких священных коров и запретов. это просто выбор разработчика, как реализовать ту или иную фичу. реализация справляется с поставленной задачей - значит, она правильная, в данном контексте.

они просто адаптируют не очень удачно реализованный шаблон под свои нужды.

Это ты так std::map называешь или что? Вообще то они его не адаптирутют, а используют особенным образом...

Если присмотреться, то над std::map можно увидеть кучку специальной логики которая ломает семантику контейнера: на оператор [] навешана логика слияния нескольких отображений { option -> value } в одно, а остальные части std::map работают только по текущему отображению.

Это гогнокод и так делать не стоило. В таких случаях определённо нужно прятать контейнер во внутрь и давать к нему доступ отдельным методом, например через оператор * или ->. Тогда было бы ясно, что есть функционал слияния отображений и одно текущее. А сейчас даже с мануалом не понятно какой контракт у методов этого изделия.

С публичным приватным членом мануал обнанул, в коде на самом деле метод get(...) спрятан под private. В общем, в мануале они везде врут с описанием классов в разных деталях, не понятно зачем.

в плюсах нет никаких священных коров и запретов.

Можно эту мысль сформулировать ещё более общно - никто не заставляет не гогнокодить и делать всё не через задницу. Это правило действует в любых ЯП и не тольно. Но...

реализация справляется с поставленной задачей - значит, она правильная, в данном контексте.

Рассуждаешь прямо как эталонный гогнокодер. Такие рассуждения частично верны пока код лежит у тебя под подушкой или с ним не нужно работать другому разработчику.

А как только на сцене появляются другие инженеры, то автор начинает нести некоторые обязательства по качеству. Например, если это библиотека, то она должна иметь простые и понятные интерфейсы, код должен быть корректно реализован. В случае топика эти цели не достигнуты, хотя код кое-как работает (на самом деле я не знаю работает ли он вообще).

у меня достаточно опыта, чтобы отличить говнокод от нормального кода. и в бусте код нормальный. по крайней мере, они его проверяют и он работает. рассуждения про «нужно» непонятно откуда растут. кому нужно? откуда взялись какие-то претензии по интерфейсу? на самом деле, никто и никому ничего не должен. в опенсорце всё просто: не хочешь - не ешь. есть вариант взять и написать свою крутую реализацию, вместо того, чтобы в уютном лорчике поливать говном чужую.

А сейчас даже с мануалом не понятно какой контракт у методов этого изделия.

Мне кажется это тебе отлично объяснит asaw

Который, конечно же, сразу начнёт нелепо отмазываться, что наговнякать можно в любом языке.

Не «сразу», а больше года назад: Boost.Log (комментарий) А ты чего сюда пришел и кукарекаешь? Этой библиотеке больше 10 лет от роду, она работает несмотря на свой страшный вид (и работает хорошо), к ней есть документация.

Бери свой раст и попытайся изобразить на нем хоть что-то полезное, а не бегай за мной по всем темам.

у меня достаточно опыта, чтобы отличить говнокод от нормального кода. и в бусте код нормальный. по крайней мере, они его проверяют и он работает.

Т.е. твоего «достаточного опыта» хватило только лишь на то, чтобы в очередной раз потрясти им на форуме, апеллировать к авторитету проекта и результат применить к частному совершенно не вдаваясь в его особенности? Не стоит с женскими истериками вырваться в технические обсуждения.

Мне кажется это тебе отлично объяснит asaw

Это «не понятно» в основном носит риторический характер.

эта библиотека, к которой вы докопались, именно частное решение. это обработка входных параметров программы. и в данной реализации она работает отлично, без нареканий. если не страдать паранойей и не разводить демагогию, конечно.

Хехе, узнаю тебя, подруга. Хотя буст конечно весьма дерьмо и защищать его не стоит.

ну, мне его приходилось юзать. на безрыбье и рак рыба. если не очень заморачиваться по скорости, то буст для кроссплатформы хорош. хотя, например ACE намного шустрее. однако, у ACE интерфейс ракообразный, стиль кода страшный и документация хреновая, по сравнению с бустом.
к бусту надо привыкнуть. он специфичен, нубы жалуются на плохую документацию буста, но это они плохой документации просто не видели. там есть некоторые вынужденные нарушения «безопасности» классов. опять же, это сделано не просто так, они так обходят некоторые ограничения реализации для разных осей. и смотря что считать «безопасным» кодом. буст описывает все свои особенности в документации. и если не стрелять себе в ногу, то проблем с ним не возникает, как правило.
раньше я больше работала c бустом, следила за рассылкой и даже репортила мелкие баги, если их находила. баги они правят быстро. переписка по бусту очень активная, но я мало пишу на плюсах в последние годы и уже лет десять как не пишу под маздай, так что необходимость в кроссплатформе для меня просто отпала. и я перестала следить за последними обновлениями. хотя иногда из любопытства заглядываю туда, чтобы быть в курсе, что там появилось интересного.