Является ли использование карты со значением std::shared_ptr хорошим выбором дизайна для мультииндексированных списков классов?

проблема проста: у нас есть класс, в котором есть члены a, b, c, d... Мы хотим иметь возможность быстро искать (ключ является значением одного члена) и обновлять список классов с новым значением, предоставляя текущее значение для или b или c... Я думал о том, чтобы иметь кучу
std::map<decltype(MyClass.a/*b,c,d*/),shared_ptr<MyClass>>.

1) Это хорошая идея?

2) Во всех отношениях превосходит ли boost multi index это решение, созданное вручную?

PS SQL не может быть и речи по причинам простоты/производительности.


c++ shared-ptr c++11 stdmap boost-multi-index
person NoSenseEtAl    schedule 26.09.2012    source источник
comment
Превосходство мультииндекса boost по сравнению с этим созданным вручную решением во всех отношениях? MultiIndex еще не поддерживает семантику перемещения. :-[   -  person ildjarn    schedule 26.09.2012

Ответы (2)


arrow_upward
7
arrow_downward

  1. У Boost MultiIndex может быть явный недостаток, заключающийся в том, что он будет пытаться поддерживать все индексы в актуальном состоянии после каждой модификации коллекции. Это может привести к значительному снижению производительности, если у вас есть фаза загрузки данных со многими отдельными операциями записи.

  2. Шаблоны использования Boost Multi Index могут не соответствовать стилю кодирования (и вкусу...) проекта (участников). Это должно быть незначительным недостатком, но я подумал, что упомяну об этом.

  3. Как уже упоминалось ildjarn, Boost MI пока не поддерживает семантику перемещения.

В противном случае я бы посчитал, что Boost MultiIndex лучше в большинстве случаев, поскольку вы вряд ли достигнете количества тестов, которые он получил.

person sehe    schedule 26.09.2012
comment
что касается объема тестирования.... это сложное сравнение, поскольку решение, созданное вручную, требует гораздо меньше тестов, но и намного меньше LOC. - person NoSenseEtAl; 27.09.2012
comment
Хорошо, что это только мое мнение :) - По крайней мере, Boost LOC был проверен большим количеством пар глаз, чем может себе позволить большинство внутренних команд. - person sehe; 27.09.2012

arrow_upward
1
arrow_downward

Вы хотите рассмотреть возможность содержания всех ваших карт в одном классе, произвольно выбрав один из контейнеров как тот, в котором хранятся «настоящие» объекты, а затем просто используйте std::map с сопоставленным типом необработанных указателей на элементы класса. первый std::map.

Однако это будет немного сложнее, если вам когда-нибудь понадобится сделать копии этих карт.

person David Stone    schedule 27.09.2012
comment
Или просто итераторы в первую карту вместо необработанных указателей на ее элементы. - person Christian Rau; 27.09.2012
comment
я ошибаюсь, думая, что sizeof shared_ptr по сравнению с sizeof iterator не такая уж большая проблема, особенно, поскольку карта iirc имеет 3 указателя на элемент - person NoSenseEtAl; 27.09.2012
comment
@ChristianRau Итераторы на первой карте, я думаю, были бы неправильным способом для большинства приложений. Они потребуют, чтобы вы сделали что-то вроде map.find(key)->second->second, а не просто map.find(key)->second. Вы добавляете дополнительный уровень косвенности без всякой пользы. - person David Stone; 28.09.2012
comment
@NoSenseEtAl Проблема не в размере. Размер итератора должен быть равен необработанному указателю, а размер shared_ptr ненамного больше, поэтому для большинства приложений это не имеет большого значения (если только вы не отображаете множество мелких объектов). Однако использование подсчета ссылок снижает производительность, и вам это не нужно. Использование карты с необработанными указателями на элемент для всех карт, кроме одной, даст вам одинаковое использование с превосходной производительностью. Другими словами, постарайтесь не платить за функциональность, которая вам не нужна. - person David Stone; 28.09.2012
comment
boost shared_ptr (с отключенным потокобезопасным подсчетом ссылок) это так. :) но серьезно, атомарный подсчет ссылок обходится дорого по сравнению с обычным подсчетом ссылок, но я думаю, что большая часть стоимости в контейнерах на основе дерева RB прыгает через память... если (и это большое, если) у меня будет немного времени на выходных, я мог бы попробовать чтобы увидеть разницу между вашим оптимизированным и наивным решением. - person NoSenseEtAl; 28.09.2012