Более, того, что-то мне кажется что коль уж мы с вами тут за 5 минут придумали 18 «сравнительно честных» способов передачи этого одного бита, то уж те, кто зарабатывает на этом деле по 600 млн придумали их 100 лет назад, в 100 раз больше и значительно более интересных.
Так Вы же сами ниже приводили пример с MD5. Важно ли, в каком порядке они хранятся внутри контейнера? Нет. Нужно ли иметь возможность проитерироваться от одного значения до другого? Да.
Понятное дело, что произвольную метрику придумать можно, если есть нужда, но если такой нужды нет и можно повысить производительность, эту метрику не вводя — то почему бы и нет?
Диаграмма, конечно, хуже полного понимания особенностей всех типов контейнеров, но всё же, мне кажется, лучше, чем ничего. Для проектов малой и средней нагруженности вполне пойдёт. По поводу Ваших замечаний — всё правда. Но как это оформить в виде понятной схемы? На ум приходит что-то типа набора критериев, для каждого из которых пользователь может установить его «вес», и по этим весам в итоге будет выбран нужный контейнер. Но, во-первых, тоже не идеально, а во-вторых, в виде статичной картинки — не реализуемо.
Даёшь демократию!
Вот ссылка на диаграмку в онлайн-сервисе, где она делалась: www.gliffy.com/go/publish/4907293
Там же её можно и поправить, и опубликовать свою версию. Вполне можно собрать в этом топике различные варианты «мировозрения», а голоса за комментарии покажут поддержку народа.
При небольшом размере контейнеров по барабану вообще всё, если у вас 10 чисел, к которым вы доступаетесь раз в минуту — можно их хранить в строках вида «один», «два», «три» — и пофиг будет. Но мир ведь не стоит на месте, объёмы данных растут, сложность моделей растёт, выигрыш от реализации типа вектор благодаря быстрым операциям на смежных диапазонах рано или поздно проиграет общей теории сложности для разных типов контейнеров.
Эти понятия не имеют смысла. Но ведь «некоторые операции не нужны» — это не повод выбирать другой контейнер. Поводом может быть либо меньшее потребление памяти, либо более высокая скорость определённых операций.
На счёт строк — ну диаграмма ведь для универсальных контейнеров, если нужны строки — конечно, нужно юзать строки.
На счёт массива байтов — а почему в конкретной реализации STL не может быть отдельной реализации вектора байт, который бы копировал одним махом весь массив? Для вектора булов ведь делают кастомную версию.
>пишутся слитно std::multiset и std::multimap
ошибка в оригинале, а я не заметил. Поправлю, спасибо
То что «ключи не уникальные» ещё не признак лажи в архитектуре, если у вас есть 1000 000 людей и есть необходимость быстро выбрать всех Вась, почему бы и не иметь мультимеп по именам?
Ну, это же Хабра, давайте решим куда добавить — и добавим.
unordered-контейнеры, я так понимаю, дают выигрыш в скорости доступа к отдельному элементу, но уступают по скорости полного прохода по контейнеру. Я так понимаю что они логично Находятся по пути «Порядок важен? — Нет, Надо искать по ключу? Да», и вот тут надо задать вопрос типа «Скорость доступа к отдельному элементу важнее скорости прохода по всему контейнеру?» и, если нет — стрелку на блок «Допустимы дубликаты?», а если да — на блок выбора между unordered_map и unordered_set. Есть другие идеи?
forward_list — блок перед list, вопрос «Нужно итерировать из конца в начало?»
array — блок перед вектором, вопрос «Размер константный?»
Можете предложить более корректные формулировки — прошу, высказывайтесь.
Вот ссылка на диаграмку в онлайн-сервисе, где она делалась: www.gliffy.com/go/publish/4907293
Там же её можно и поправить, и опубликовать свою версию. Вполне можно собрать в этом топике различные варианты «мировозрения», а голоса за комментарии покажут поддержку народа.
На счёт массива байтов — а почему в конкретной реализации STL не может быть отдельной реализации вектора байт, который бы копировал одним махом весь массив? Для вектора булов ведь делают кастомную версию.
>пишутся слитно std::multiset и std::multimap
ошибка в оригинале, а я не заметил. Поправлю, спасибо
То что «ключи не уникальные» ещё не признак лажи в архитектуре, если у вас есть 1000 000 людей и есть необходимость быстро выбрать всех Вась, почему бы и не иметь мультимеп по именам?
unordered-контейнеры, я так понимаю, дают выигрыш в скорости доступа к отдельному элементу, но уступают по скорости полного прохода по контейнеру. Я так понимаю что они логично Находятся по пути «Порядок важен? — Нет, Надо искать по ключу? Да», и вот тут надо задать вопрос типа «Скорость доступа к отдельному элементу важнее скорости прохода по всему контейнеру?» и, если нет — стрелку на блок «Допустимы дубликаты?», а если да — на блок выбора между unordered_map и unordered_set. Есть другие идеи?
forward_list — блок перед list, вопрос «Нужно итерировать из конца в начало?»
array — блок перед вектором, вопрос «Размер константный?»
Можете предложить более корректные формулировки — прошу, высказывайтесь.