- Дискуссия начинается с того, что Хоакин пытается вычеркнуть из библиотеки имя "миска" -

Размышляя об этом, объединяющий принцип MISC-контейнеров, возможно, вводит в заблуждение: конечно, все ошибки используют мультииндексирование внутри, но это мало отражается во внешнем интерфейсе (как и должно быть, OTOH). Так, с точки зрения пользователя, миксы — это совершенно разнородные звери. Более того, в вашем предложении нет какого-либо глобального объекта, общего для всех неудачников. А как насчет того, чтобы отказаться от принципа микса и работать над каждым контейнером как отдельной библиотекой? У вас будет импульс::bimap, boost::mru и т. Д., И нет общего введения к ним. Это также открывает возможность добавить в пакет другие контейнеры, которые не основаны на B.MI. Какова ваша позиция по этому поводу? Видите ли вы ценность в концептуальном объединении ошибок?

Поскольку в первоначальном предложении говорится только о двух контейнерах (бимап и набор mru), оба из которых основаны на B.MI, было прямолинейно сгруппировать их вместе. Когда я писал предложение SoC, у меня было похожее чувство, когда две семьи начали расти. Единственным общим знаменателем является их внутренняя реализация. Я немного подумал о более общей структуре, чтобы присоединиться к этим двум семьям (и другим внутренне связанным) и, наконец, придумал идею: Boost.MultiIndex! Поэтому я думаю, что это не очень хорошая идея, чтобы попытаться объединить две семьи, и я проголосовал за то, чтобы избавиться от мик-части повышения::misc::bimap и повышения:::misc:::mru. В любом случае, для моего приложения SoC кажется нормальным поместить две семьи в один и тот же проект, потому что, хотя извне они совершенно не связаны, работа, которую мне придется сделать, чтобы построить библиотеки, будет последовательной, и то, что я изучу кодирование семьи бимап, будет использоваться, когда я начну кодировать семью mru. Когда семья mru будет на месте, я, конечно, узнал другие вещи, чтобы улучшить группу бимапов.

С другой стороны, я думаю, что для общего пользователя будет полезно иметь по крайней мере некоторый документ, связанный с документацией B.MI, которая перечисляет наиболее распространенные случаи использования (например, бимап и набор mru) и пункты, где можно найти чистую реализацию для этих полезных контейнеров. На данный момент достаточно ссылки для повышения::bimap и другой, чтобы повысить::mru. Если вы подумаете о названии такого документа, вы, вероятно, придумаете что-то вроде: Common Multi Index Specialized Containers. Итак, чтобы заказать некоторые идеи:

- Будет создано новое семейство контейнеров, к которым можно получить доступ по обоим ключам. (буст::bimap)

- Новое семейство контейнеров времени увидит свет. (буст::мру)

- Страница может быть добавлена в документацию B.MI под названием misc, которая связывает эти новые библиотеки.

Это более четкая структура для пользователя. Они могут использовать контейнер mru, не слыша о Boost. МультиИндекс вообще. И пользователи B.MI получат некоторые из своих общих контейнеров, уже реализованных с дружественным интерфейсом STL в других библиотеках. И, как вы сказали, это более расширяемо, потому что открывает двери для использования других библиотек в бимап и mru семьях, чем просто Boost. MultiIndex без ущерба для более общей основы повышения. Слово «миск» исчезнет из кода и документации бимапа и мру. Отныне единственным его использованием будет определение нашего проекта SoC. Я думаю в названии для бимап библиотеки. А как же Boost? двунаправленный Карта? Идеи?

Да, Boost.Bimap. На мой взгляд, бимап — это хорошо известное имя в Boost и даже в сообществе C++. Звучит и очень коротко. Почему бы не оправдать себя как владельца этого имени?

Теперь этот рост. Бимап обретает некоторую форму, я вижу, что, как вы мне сказали, мы должны предложить в библиотеке «one_to_many_map» и «multi_bimap». Фреймворк, над которым я работаю, позволяет создавать двунаправленные карты, и это легко понять со стороны пользователя.

Хорошо, я рад, что мы согласны по этому вопросу.

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

- до - от

- до - b

- 0 - 1

- слева - справа

На мой взгляд, это вопрос вкуса, но левое/правое звучит более симметрично, чем другие.

Мне очень нравится левая/правая нотация, ее очень легко запомнить и она гораздо более симметрична, чем к/от.

112Сначала моя идея заключалась в том, чтобы получить простоту использования, скрывая ядро B.MI, делая его более интуитивным. Тем не менее, я понял, что B.MI гораздо более связный и простой в использовании, чем я себе представлял. Это заставляет меня снова задуматься над проблемой. В дизайне, который я сейчас кодирую, bimap- этоmulti_index_container, который специализируется на типе данных, очень удобном под названием bipair, который можно увидеть как любую из двух карт, которые интегрируют его с использованием просмотров карт. Эта схема имеет большие преимущества для пользователей:

- Если пользователь уже знает B.MI, он может воспользоваться инструментами, которые он предоставляет и которые отсутствуют в контейнерах STL. Кроме того, в некоторых случаях использование индексов для просмотра данных может быть очень полезным.

- Если пользователь ничего не знает о B.MI, но имеет STL-фреймворк, кривая обучения сводится к пониманию инстанциации бимапа и того, как получен желаемый вид карты.

Еще одно очень важное преимущество: Все алгоритмы, созданные для B.MI, продолжают работать с Boost. Бимап и, если ИМТ продолжает расти, бимап растет автоматически.

Умм... Это интересное дизайнерское решение, но спорное, на мой взгляд. В основном вы решаете разоблачить реализацию бимапа; у этого есть преимущества, как вы заявили, но и немалый недостаток: один раз.вы задокументировалиреализацию, изменить ее уже невозможно. Это брак с B.MI без возможности развода. Другая возможность, чтобы скрыть реализацию и дублировать и документировать предоставленную функциональность, явно или неявно из-за тех же характеристик реализации, конечно, тяжелее поддерживать, но это дает степень свободы, чтобы изменить кишки вашего программного обеспечения, если вам нужно. Не воспринимайте это как фронтальное возражение, но я думаю, что это достаточно важное дизайнерское решение не только в контексте бимапа, но и в целом.

Ты прямо здесь. Я думаю, что мы должны выбрать самый трудный путь и скрыть ядро B.MI от пользователя. Я посылаю вам первый черновик бимапа вместе с некоторой документацией.

Я должен признаться, что мне начинает нравиться то, что я вижу. Я математик по призванию, и когда я вижу симметрию в формулировке, я считаю, что она находится в правильном направлении.

Мы два математика по призванию.

Я думаю, что часть теории std::set очень ясна. Для меня несколько странно рассматривать ранг карты (значения X) как std::set, но, конечно, формулировка последовательна. 176

Мне это очень нравится, поначалу это может быть немного странно, но теперь, когда я привык к этому, очень легко выразить в коде мои ограничения на данные, и я считаю, что если кто-то прочитает код и увидит моментализацию бимапа, у него не будет проблем с его пониманием. Возможно, это легче понять, если мы используем вашу нотацию: order_nonunique, unordered_unique, но это идет вразрез с нашим STL-фасадом. По моему мнению, пользователь, который приходит из STL, должен учиться как можно меньше.

Рассматривая отношение какструктураслева,справа]является чистым и ясным. Если я хорошо понимаю это, одно отношение имеет вид пары{сначала,второй}, правильно ли это?

Да, я считаю, что левое/правое обозначение для выражения симметрии велико. Я верю, что людям это понравится.

Хорошо, отлично. Мне это очень нравится:

- bm.left совместим с std::map

- bm.right совместим с std::map

- bm совместим с std::set>

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

Отлично!

Двигаясь дальше, поддержку N-1, N-N и хешированного индекса очень легко понять, и он хорошо вписывается в рамки. Тем не менее, я не заканчиваю, чтобы очень хорошо понять раздел «установка и отношения». Придумаете ли вы какие-то примеры, в которых смысл различных случаев, которые вы перечисляете?

Да, я имею ввиду:

— на основе левого

— по правую сторону

Ядро бимапа должно быть основано на некотором индексе мультииндекса. Если индекс слева имеет тип хэша, то фактически основным видом будет неупорядоченный_set>. Возможно, это не то, что предпочитает пользователь, и он хочет основывать свое основное мнение на правильном индексе.

— set_of_relation

- multiset_of_relation

— unordered_set_of_relation

— unordered_multiset_of_relation

Однако, если оба они являются хеш-индексами, пользователь может захотеть, чтобы основной вид был заказан. Поскольку у нас есть ядро B.MI, его очень легко поддерживать, нам просто нужно добавить к нему еще один индекс.

Теперь я понимаю это. Хорошо, я не знаю, нужно ли включать это в первую версию, будет лавина функциональности!

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

Существуют ограничения между типами левого и правого множеств и возможными типами множеств основного вида. Например, если какой-то из индексов имеет уникальный тип, то основной вид не может быть типа multiset_of_relation. К обратному, если основной вид имеет тип set_of_relation, левый и правый индекс не могут быть мульти-множеством типов. Вся эта тема сужения единства и возникающих взаимодействий между индексами является одним из тонких предметов ИМТ.

Это можно проверить во время компиляции и сообщить как ошибку во времени компиляции.

Это может быть интересно.

У меня есть кое-что похуже в отношении мутанта, это очень хорошо спроектированный и управляемый класс, к сожалению, C++ практически ни в коем случае не гарантирует совместимость с макетом. Например, стандарт C++ не гарантирует, что классыstruct{T1a;T2b;}иstruct{b;T2a;]являются компоново-совместимыми, и поэтому трюк переосмысления_cast является неопределенным поведением. Я с вами, в котором в 100% случаев эта схема действительно будет работать, но стандарт есть стандарт. Если вы можете посмотреть тему совместимости макета в нем (http://www.kuzbass.ru/docs/isocpp/). Как видите, иногда стандарт жесток. Хотя мутант кажется потерянным случаем, пожалуйста, не спешите его устранять. Посмотрим, что можно для этого сделать.

Я прочитал стандарт, и вы были правы. Мутант был деталью реализации. Жаль, потому что я уверен, что он будет работать идеально в любом компиляторе. Возможно, когда-нибудь стандарт станет более строгим, и мутант вернется к жизни. Затем мы можем попробовать обертку вокруг отношения, которые имеют две ссылки, названные первой и второй, которые связываются с A и B, или B и A.

Нетрудно кодировать класс отношений таким образом, но при каждом доступе инициализируются две ссылки и использованиеpba.первыйбудет медленнее, чемr.оставленв большинстве компиляторов. Очень сложно оптимизировать такого рода ссылки.

Этот обходной путь невозможен из-за технических проблем с ожидаемым поведением итераторов. Если итераторы bm.left имеют двунаправленный тип, то в стандарте указано, что они должны возвращать объект типа const value_type&. Вам придется вернуть пару const_reference_pair, созданную в полете, что сделает невозможным возврат ссылки.

Я понимаю... У меня есть обходной путь для этого, но, безусловно, стандарт снова нападет на меня! Мы должны создать классовое отношение, которое реагирует так, как мы хотим, остальная часть кода будет исходить из этой точки. Это четкое разделение между классом отношений и остальной библиотекой поможет нам отделить проблемы и лучше атаковать их.

Какой обходной путь? Я посвятил этому предмету много времени и не нахожу никакого решения, кроме того, что мы позволяем классу отношений занимать больше памяти.

Мы должны добиться того, чтобы соотношениеразмер равнялся пареразмер, если мы хотим, чтобы эта библиотека была действительно полезной. Я собирался написать свой обходной путь и понял, что он не работает. Посмотрите на это: http://www.boost.org/libs/iterator/doc/new-iter-concepts.html В основном проблема, с которой мы имеем дело, решается, если мы основываем наши итераторы на этом предложении. Настоящие стандартные силы, которые двунаправленные итераторы также имеют тип ввода и вывода. Используя новые концепции, нет ничего неудобного в создании наших итераторов «Readable Writable Swappable Bidirectional Traversal». Таким образом, const_reference_pair возвращается в силу. 454

Это правильно в том смысле, что вы просто говорите, что ваши итераторы менее мощные, чем у std::map. Дело не в том, что это неправильно, просто вместо того, чтобы решить проблему, вы признаетесь в этом.

Хорошо, но в нашем конкретном случае: каковы преимущества предложения итератора LValue против итератора Read Write? Мне не кажется, что в данном случае он менее мощный.

Основная проблема с ReadWrite заключается в том, что следующее:значение_типа*p= & [*он;выходит из строя или сохраняет преходящее направление в p. Это важно в реальной жизни? Я не знаю. Как часто вы сохраняете направление элементов карты? Возможно, это не очень часто, так как логично хранить итераторы вместо направлений элементов. Давайте рассмотрим наши варианты:

1.Мы использовали мутант, зная, что это не стандартно, но, конечно, это поддерживается в 100% случаев.

2.Мы использовали const_reference_pair и объявили итераторы не LValue.

3.Мы нашли какой-то трюк, о котором до сих пор не знаем. Таким образом, я играл с профсоюзами и другими вещами без особого везения.

4.Мы используем ограничение, которое взгляды должны поддерживать первую, вторую нотацию. Если мы приняли это решение, то есть несколько вариантов:

а. Левая карта имеет стандартную семантику первый/второй, в то время как правая карта имеет обратную семантику.

б. Вместо первого и второго мы предоставляем первый () и второй (), с которыми проблема является тривиальной.

с. Вид карты не поддерживает первый/второй, но левый/правый как отношение отца

5.Мы решаем проблему, используя больше памяти, чем размер (pair).

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

Отлично!

1.Я хочу, чтобы в библиотеке была этикетка "соответствующая стандартам".

2.Это естественный выбор, но знать, что есть другой вариант, который всегда работает и более эффективен, ужасно.

3.Я также пытался играть с профсоюзами, проблема в том, что члены профсоюза должны быть типами POD.

4. Этот вариант подразумевает большую потерю для библиотеки.

5. Полностью согласен.

Я хочу добавить еще один вариант в этот список. Используя метапрограммирование, класс отношений проверяет, поддерживает ли компилятор мутантную идиому. Если он поддерживает его, то он использует его и получает нулевые накладные расходы плюс итераторы LValue, но если он не поддерживает его, то использует const_reference_pair и получает минимальные накладные расходы с итераторами ReadWrite. Это может быть спорным, но преимущества, которые предлагает мутант, очень велики, и правда в том, что я не верю, что в любом реальном компиляторе эта идиома не поддерживается. Эта схема идеально подошла бы под нынешний стандарт, поскольку мы ничего не предполагаем. Единственным недостатком здесь является то, что, хотя мутантный подход позволяет сделать итераторы LValue, мы должны ухудшить их, чтобы читать и писать в обоих случаях, потому что мы хотим, чтобы один и тот же код мог быть скомпилирован в любом стандартном компиляторе.

Сменив тему, я считаю, что общая концепция подцепки данных хороша, но мне не нравится, как вы ее реализуете. Это должно быть легко мигрировать в B.MI, чтобы предвидеть случай в этом росте. Бимапа становится недостаточно. Для пользователя B.MI более естественно, что доступ к данным осуществляется без опосредования.. Я не знаю, как это может быть сформулировано в ваших рамках.

У меня есть техническая проблема для реализации data_hook таким образом. Если стандарт позволит нам использовать мутантную идиому напрямую, я смогу реализовать ее с помощью множественного наследования. Но так как мы должны использовать const_reference_pair, Мне становится невозможно его поддержать. У нас есть три варианта:

1) отношение {левое, правое, данные } и pair_view {первое, второе, данные }

— Это более интуитивно понятно в рамках бимапа, поскольку он не смешивает данные с индексом, как это делает таблица в базе данных, а придает индексу большее значение.

- Необязательно, чтобы пользователь помещал переменное ключевое слово в каждый член класса данных.

— Это немного отходит от ИМТ, потому что модель его похожа на таблицу, но продолжает существовать четкий путь миграции.

2) отношение {слева, справа, d1,d2... dn } и pair_view {первый, второй, данные }

— Путь к ИМТ — тот, который вы предложили.

— Это очень асимметрично. Необходимо объяснить, что взгляды трактуются иначе, чем отношение.

- Пользователь должен поместить изменяемые клавиатуры в класс данных.

3) Только отношение {слева, справа, d1,d2... dn }

- Простой путь миграции к ИМТ

- Вы не можете получить доступ к зацепленным данным из просмотров.

Мой голос идет за первое предложение.

Да, первым вариантом является тот, который меньше удивляет пользователя. Я тоже голосую за 1.

Есть еще одна проблема, которую я должен решить. Мне нужно знать, нужно ли создавать карту_view, связанную ни с чем. При необходимости есть два варианта: что он ведет себя как пустой контейнер или что он бросает исключение или утверждает при попытке его использования. Если в этом нет необходимости, map_view будет содержать ссылку вместо указателя. Для меня просмотр карты всегда должен быть просмотром чего-то. В случае, если итераторы могут создавать их пустыми, это делает их простыми в использовании в контекстах, которые по умолчанию требуют конструкторов, таких как значение_тип контейнера.

Как будет полезна пустая карта_view? Моя интуиция похожа на вашу, Map_view всегда должен быть связан с чем-то. Если мы хотим получить семантику «связана или нет», мы можем использовать указатель на map_view.

Хорошо, тогда вы согласны с тем, что map_views хранит ссылку вместо указателя?

Это зависит от семантики, которую вы хотите дать map_views, и конкретно от копии map_views.

Что же делать с этой последней строкой?

1. Восстановление x, то есть x точек в том же контейнере, что и y.

2. Копия базового контейнера.

Если вы хотите реализовать 1, вы не можете использовать ссылки внутри. Если вы хотите реализовать 2, это почти то же самое, чтобы использовать ссылку или указатель.

Если я хочу, чтобы они вели себя точно так же, как std::maps, тогда я должен пойти на 2. Но если я думаю, что они как «виды» чего-то, мне нравится 1. Вопрос сложный. Еще один вариант:

3. Ошибка: оператор = объявляется приватным в бустере::bimap::map_view std_container

Что происходит сstd_container=view;? и сview=std_container;?