ну это не то

в бусте есть small_vector is a vector-like container optimized for the case when it contains few elements. It contains some preallocated elements in-place, which allows it to avoid the use of dynamic storage allocation when the actual number of elements is below that preallocated threshold. ... capacity can grow beyond the initial preallocated capacity.

фиксированный capacity, динамический size.

фиксированный capacity, динамический size.

Мне казалось, std::array только fixed size

то, что я написал - мне нужно

Есть max_size, который говорит о максимальной вместимости в зависисомсти от реализации.

перечитай мои сообщения, std::array здесь не в тему. у него capacity = size и он не может залезть в кучу при size > capacity (хотя бы из-за того, что size фиксированный)

но так как это невозможно реализовать на аллокаторах со стандартными контейнерами, то нужны какие-то другие решения, типа boost::small_vector

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

У всех разное мнение о том, какой размер надо на стеке держать, а какой уже в куче. Особенно это мнение различается для серверных приложений и для embedded

поискал small_map/small_set - не нашёл

впрочем, есть подозрение, что map/set на небольших объемах будут тупо медленнее vector'а с линейным поиском по нему

Кто-нибудь работал с Boost.Multiprecision? Там довольно интересная штука - cpp_int_backend. Как Вы думаете, важно ли для длинной арифметики иметь ручку для настройки вида "если размер меньше чем X, аллоцируем на стеке. Если больше, то на кучу"?

Я еще раз подумал: на случай динамической аллокации класс должен хранить size, data, capacity. На 64 битной платформе это значит что можно хранить как минимум 2^128 без динамических аллокаций используя SSO. Возможно что дополнительные шаблонные параметры могут усложнить класс, не давая особых преимуществ в большинстве случаев

Так если sso, то размер на стеке будет регулироваться имплементацией, а не пользователем

да, но там будет размер как минимум в два раза большей long long стоит ли заморачиваться?

Я еще раз подумал: на случай динамической аллокации класс должен хранить size, data, capacity. На 64 битной платформе это значит что можно хранить как минимум 2^128 без динамических аллокаций используя SSO. Возможно что дополнительные шаблонные параметры могут усложнить класс, не давая особых преимуществ в большинстве случаев

Даже на 64-битной платформе никто не заставляет хранить 64-битные size и capacity. Часто ли нужно больше четырёх ярдов элементов? Я в паре 64-битных проектов полностью заменил контейнеры на 32-битные индексы и размеры, написав отдельно контейнер "большой байтовый кусок, если вдруг захотелось весь блюрей в память засунуть". Так вот, выигрыш по памяти и скорости был существенным.

Даже на 64-битной платформе никто не заставляет хранить 64-битные size и capacity. Часто ли нужно больше четырёх ярдов элементов? Я в паре 64-битных проектов полностью заменил контейнеры на 32-битные индексы и размеры, написав отдельно контейнер "большой байтовый кусок, если вдруг захотелось весь блюрей в память засунуть". Так вот, выигрыш по памяти и скорости был существенным.

Вы это делали, подставляя стандартному контейнеру спец аллокатор или писали контейнеры с нуля?

А можно в числовом эквиваленте «существенный» выразить? ;)

Всем привет. Снова дурацкий вопрос, не получается указать версию, с которой слинковать приложение. На ubuntu, сначала скомпилил Boost версии 1.60, потом поставил из пакетов 1.58... и при компиляции почему-то он линкуется с 1.60. Как правильно в cmake указать, что бы использовался 1.58?

Почему первый вариант метода get() работает, а второй дает ошибку компиляции? 1. https://ideone.com/OzKEtR 2. https://ideone.com/pHFIKP

у make_shared нет доступа к приватному конструктору

Запишу себе как-нибудь забацать статейку. На конкретной задаче (компилятор) там был выигрыш по памяти в десятки процентов (много-много маленьких векторов). Другое дело, что в 21 веке, когда люди даже на Питоне писать не брезгуют, для оптимизации контейнеров нужна сильная мотивация.

Почему первый вариант метода get() работает, а второй дает ошибку компиляции? 1. https://ideone.com/OzKEtR 2. https://ideone.com/pHFIKP

может потому, что ты возвращаешь ссылку на темпорари объект?

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

но я не запускал, и что там компилятор говорит не видел

Ну тогда сначала почитай, в чем вопрос был

или это просто такое излюбленное упражнение по заталкиванию всё в шаблоны?

есть линк на стандарт, гарантирующий такое поведение? я вот такого не помню

а как ему его обеспечить?

Какое такое? Ты возвращаешь ссылку на существующий обьект, он НЕ временный. Почему она должна не работать?

никак

Переписать и не ибаццо с шаблонами?

вообще странно, что std не предоставляет какого-нибудь класса shared_creator, которому можно прописать friend class shared_creator