Опытным программистам С++

@Tenarius · Регистрация: 04.12.2016

Author24 — интернет-сервис помощи студентам

Здравствуйте, я начал изучать С++. Есть определенный план обучения. Например: сначала изучить синтаксис, принцип ООП, контейнеры STL, стандарты С++11/C++14. Вопрос звучит так: что можно еще добавить в список для изучения? Я еще не определился в какой сфере хочу использовать язык, что нужно знать вообще не привязанная к определенной области?

@lArtl · 28.01.2018, 22:59

Сообщение от Renji

Потому как есть такая штука как "выравнивание".

alignof? Или я чего то не понимаю...

@Fulcrum_013 · 28.01.2018, 23:05

Сообщение от _stanislav

кстати, причина по которой stl не убрали из стандартной библиотеки

Причины известны. Должна быть обратная совместимость. Ну если это легаси будет там где то в отдельной папке лежать пусть себе лежит мне от этого ни холодно не жарко. А вот то что вместо внесения в язык насущных средств на уровень ядра толкают какие то библиотечные костыли вот это как раз давно пора прекращать, а то коммитетовский С++ сам рискует превратится в легаси. К примеру нативные свойства и нативные делегаты гораздо эффективнее как в плане удобства синтаксиса так и в плане отсутствия оверхеда нежели костыли на основе шаблонов. При этом многие из этих средств в компиляторах ведущих производителей живут уже более 20 лет только у всех по разному.

Добавлено через 4 минуты

Сообщение от Renji

И делать char знаковым или беззнаковым в зависимости от платформы, это вредительство. Хотя, это уже не вина STL.

ну там где это важно можно кастить в unsigned __int8;

@Renji · 28.01.2018, 23:15

Сообщение от lArtl

alignof? Или я чего то не понимаю...

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

C++

1 2	std::size_t align=std::max(alignof(void),alignof(value_type)); std::size_t size=(sizeof(void)*2+sizeof(value_type)+align-1)&~(align-1);

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

Сообщение от Fulcrum_013

ну там где это важно можно кастить в unsigned __int8;

Так это важно везде, где с char делается что-то помимо копирования. Например, в лексикографическом сравнении utf-8 строк.

@lArtl · 28.01.2018, 23:30

Сообщение от Renji

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

std::list отвечает требованиям Container, AllocatorAwareContainer, SequenceContainer и ReversibleContainer.
AllocatorAwareContainer - контейнером, который содержит экземпляр Allocator и использует этот экземпляр во всех своих функциях-членах для выделения и освобождения памяти, а также для создания и уничтожения объектов в этой памяти (такими объектами могут быть элементы контейнера, узлы). Тобишь он будет хранить не T, а _List_node<T>.

Добавлено через 2 минуты

Сообщение от Renji

Так это важно везде, где с char делается что-то помимо копирования. Например, в лексикографическом сравнении utf-8 строк.

Компилятор на этапе компиляции знает, с какими типами он будет работать.

@Fulcrum_013 · 28.01.2018, 23:32

Сообщение от Renji

Так это важно везде, где с char делается что-то помимо копирования. Например, в лексикографическом сравнении utf-8 строк.

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

@Renji · 28.01.2018, 23:36

Сообщение от lArtl

Компилятор на этапе компиляции знает, с какими типами он будет работать.

Ага, компилятор на этапе компиляции знает что будет работать с char, как с числом со знаком. Поэтому он знает что char(128+64) (первый октет двубайтового utf-8 символа) меньше чем char(0). Тогда как для utf8 символов должно быть с точностью до наоборот.

Сообщение от lArtl

Тобишь он будет хранить не T, а _List_node<T>.

Я и написал формулу считающую размер List_node<T> вида:

C++

template<typename T>
struct List_node
{
    List_node*next;
    List_node*prev;
    T value;
};

А можно было вместо этого написать sizeof(std::list<double>::List_node) и не парить себе мозг.

@Undisputed · 28.01.2018, 23:42

Renji,
Пишу с мобилы не удобно цитировать...
Список по определению является динамической структурой данных, что вам даст знание размера ноды на этапе компиляции, и как вы без маллока выделите память для динамической структуры данных, причём на этапе компиляции, зная просто размер этой самой ноды?

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

а оператор [] есть не у всех просто потому что его наличие зависит от данных. Скажем в том же листе он ни к чему. А в векторе например очень даже кстати...
Всему своё место

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

@lArtl · 28.01.2018, 23:51

Сообщение от Renji

А можно было вместо этого написать sizeof(std::list<double>::List_node) и не парить себе мозг.

std::list сделает это за вас используя rebind и вы не будете парить себе мозг о том, как там List_node устроен и не выводя при этом формулы размеров и выравнивания. И чет приведенный вами аллокатор какой то странный. Allocator

@Renji · 29.01.2018, 00:04

Сообщение от lArtl

std::list сделает это за вас используя rebind

Ну и как вы используя rebind создадите отдельный пул объектов, для каждого экземпляра списка? Вот создать пул общий для всех std::list<double> да, можно. Но если в пул лезет неизвестное число объектов, то нельзя проконтролировать и верхний лимит расходов памяти в этом пуле. И теряется смысл в подобных оптимизациях - все равно придется куда-то впихивать malloc для расширения пула.

В этом собственно и проблема STL-аллокаторов - они писались как обертка вокруг глобального malloc. На "каждый объект сидит в своей песочнице размером в сто элементов" они не рассчитывались.

Сообщение от Undisputed

Список по определению является динамической структурой данных, что вам даст знание размера ноды на этапе компиляции, и как вы без маллока выделите память для динамической структуры данных, причём на этапе компиляции, зная просто размер этой самой ноды?

А я заранее знаю максимальное число элементов в этой структуре. Скажем, если это список фигур на доске, то больше 64 элементов там появиться ну никак не может.

Да, в стринге теоретически можно задать тип используемого символа. Но всякие там std::to_string с подобными кастомными строками работать не умеют. И я может быть что-то пропустил, но std::basic_string::find работать с итераторами вроде бы пока не научили.

@Undisputed · 29.01.2018, 00:26

Renji,
Вот вам ещё один вариант для аллокации, и даже с определением размера ноды на этапе компиляции:
Аллокаторы имеют шаблонный параметр T, который по идее должен быть выведен как тип ноды (если подсунуть листу свой аллокатор).
Что мешает в конструкторе аллокатора выделить память, размер которой будет равен sizeof(T) * fixed_elements_count, и при аллокации использовать выделенный буфер? Вроде то что вы хотели...

Добавлено через 1 минуту
Я конечно не проверял но вроде должно сработать

@Renji · 29.01.2018, 00:41

Сообщение от Undisputed

Что мешает в конструкторе аллокатора выделить память, размер которой будет равен sizeof(T) * fixed_elements_count, и при аллокации использовать выделенный буфер?

Мешает этот чертов rebind, позволяющий конструкции вида:

C++

1	double*array=std::allocator<void>::rebind<double>::other().allocate(10);

В этом случае аллокатор конструируется и разрушается постоянно, что делает невозможным что либо там выделять.
Впрочем, в C++17 rebind стал deprecated. Может, в C++20 эту гадость удалят окончательно.

@lArtl · 29.01.2018, 00:51

Сообщение от Renji

Ну и как вы используя rebind создадите отдельный пул объектов, для каждого экземпляра списка?

Сделать пул свойством аллокатора?

Сообщение от Renji

Но если в пул лезет неизвестное число объектов, то нельзя проконтролировать и верхний лимит расходов памяти в этом пуле. И теряется смысл в подобных оптимизациях - все равно придется куда-то впихивать malloc для расширения пула.

Это не проблема stl.

Сообщение от Renji

Да, в стринге теоретически можно задать тип используемого символа. Но всякие там std::to_string с подобными кастомными строками работать не умеют. И я может быть что-то пропустил, но std::basic_string::find работать с итераторами вроде бы пока не научили.

std::string = std::basic_string<char>.

@Renji · 29.01.2018, 00:57

Сообщение от lArtl

Сделать пул свойством аллокатора?

Того аллокатора который второй аргумент в template < class T, class Alloc = allocator<T> > class list? Так он про ListNode ничего не знает, ему T в качестве аргумента сунули.
Того аллокатора который получился от rebind? Это временный объект, который через три наносекунды помрет вместе с пулом в нем.

Сообщение от lArtl

Это не проблема stl.

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

Сообщение от lArtl

std::string = std::basic_string<char>.

А мне надо std::basic_string<unsigned char>.

@lArtl · 29.01.2018, 01:30

Сообщение от Renji

Того аллокатора который второй аргумент в template < class T, class Alloc = allocator<T> > class list? Так он про ListNode ничего не знает, ему T в качестве аргумента сунули.
Того аллокатора который получился от rebind? Это временный объект, который через три наносекунды помрет вместе с пулом в нем.

Поэтому std::list будет хранить не allocator<T>, а тот, который мы получим от rebind.

Сообщение от Renji

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

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

Добавлено через 1 минуту

Сообщение от Renji

А мне надо std::basic_string<unsigned char>.

А что вы скажите насчет std::u16string?

Добавлено через 6 минут
А вообще работать с локалью и кодировками в stl тот еще гемор, всякие там codecvt и тд

@Renji · 29.01.2018, 01:48

Сообщение от lArtl

Поэтому std::list будет хранить не allocator<T>, а тот, который мы получим от rebind.

Где конкретно это написано? std::list::get_allocator возвращает allocator<T>, конструктор листа принимает опять же allocator<T>. Мы конечно можем прикинуть что по уму то надо хранить аллокатор полученный от rebind, но вот гарантий этого я не вижу. А раз нет гарантий, то и полагаться на такие умозаключения нельзя.

Сообщение от lArtl

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

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

Сообщение от lArtl

А что вы скажите насчет std::u16string?

Так разговор то был о char. А так да, можно просто выкинуть из программы все char и использовать wchar_t.

@Fulcrum_013 · 29.01.2018, 01:50

Сообщение от Renji

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

Вот в том то и проблема. Причем она не столько в самой STL которую можно в случае необходимости просто допиливать, а в крайнем (ну или сходу) заменить на что то годное. Проблема в том что коммитет уже 20 лет 2/3 стандарта описывает инструменты точное назначение которых на этапе их псевдоуниверсальной разработки известно быть не может, но при этом неумение самостоятельно пилить такие инструменты канает на отчисление после первого семестра в любом толковом ликбезе.
А вот те средства которые нужно добавлять в ядро языка ии которые не могут быть созданы программистом в рамках решения его конкретной задачи в результате всего этого остаются за кадром.

@lArtl · 29.01.2018, 02:03

Сообщение от Renji

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

Имелось виду size_t, который будет показывать, сколько все аллокаторы выделили память.

Сообщение от lArtl

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

Еще раз, это не проблема stl. Это проблема пула, который что то там не может предсказать.

@Fulcrum_013 · 29.01.2018, 02:05

Сообщение от Renji

Скажем, если это список фигур на доске, то больше 64 элементов там появиться ну никак не может.

так. а зачем там тогда вообще список если их количество заранее известно? Может вектор указателей удобнее и быстрее будет в конечном итоге?

@lArtl · 29.01.2018, 02:20

Вот единственное, что аллокатор влияет на тип контейнера...

@Fulcrum_013 · 29.01.2018, 02:22

Сообщение от lArtl

Вот единственное, что аллокатор влияет на тип контейнера...

Вопрос в том что пулы константной аллокации для объектов классов давно пора иметь под капотом штатного менеджера кучи а не спорить как их прикручивать библиотечными средствами.

@lArtl 322 / 174 / 78 Регистрация: 09.10.2014 Сообщений: 809
	28.01.2018, 22:59	61
	Сообщение от Renji Потому как есть такая штука как "выравнивание". alignof? Или я чего то не понимаю... 0

@Fulcrum_013 2082 / 1573 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	28.01.2018, 23:05	62
	Сообщение от _stanislav кстати, причина по которой stl не убрали из стандартной библиотеки Причины известны. Должна быть обратная совместимость. Ну если это легаси будет там где то в отдельной папке лежать пусть себе лежит мне от этого ни холодно не жарко. А вот то что вместо внесения в язык насущных средств на уровень ядра толкают какие то библиотечные костыли вот это как раз давно пора прекращать, а то коммитетовский С++ сам рискует превратится в легаси. К примеру нативные свойства и нативные делегаты гораздо эффективнее как в плане удобства синтаксиса так и в плане отсутствия оверхеда нежели костыли на основе шаблонов. При этом многие из этих средств в компиляторах ведущих производителей живут уже более 20 лет только у всех по разному. Добавлено через 4 минуты Сообщение от Renji И делать char знаковым или беззнаковым в зависимости от платформы, это вредительство. Хотя, это уже не вина STL. ну там где это важно можно кастить в unsigned __int8; 0

@Fulcrum_013 2082 / 1573 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	28.01.2018, 23:32	65
	Сообщение от Renji Так это важно везде, где с char делается что-то помимо копирования. Например, в лексикографическом сравнении utf-8 строк. Оно важно разве что в табличном лексере в котором очередной поступивший на вход символ используется как индекс в массиве правил переходов. 0

@Undisputed 900 / 477 / 93 Регистрация: 10.06.2014 Сообщений: 2,698
	28.01.2018, 23:42	67
	Renji, Пишу с мобилы не удобно цитировать... Список по определению является динамической структурой данных, что вам даст знание размера ноды на этапе компиляции, и как вы без маллока выделите память для динамической структуры данных, причём на этапе компиляции, зная просто размер этой самой ноды? Насчёт чара в стринге, можно же передавать явно тот тип который нужно, если "зависит от реализации" не подходит под ваши требования? Насчёт итераторов - у строк они тоже имеются а оператор [] есть не у всех просто потому что его наличие зависит от данных. Скажем в том же листе он ни к чему. А в векторе например очень даже кстати... Всему своё место Насчёт регулярок тут уже надо обращаться к разрабам, что бы добавили то чего нет... В крайнем случае можно пока можно дергать для этих дел какой нибудь скриптовый язык (если сильно надо), системные вызовы ведь никто не отменял... Да, не удобно, но и не безвыходно... 0

@lArtl 322 / 174 / 78 Регистрация: 09.10.2014 Сообщений: 809
	28.01.2018, 23:51	68
	Сообщение от Renji А можно было вместо этого написать sizeof(std::list<double>::List_node) и не парить себе мозг. std::list сделает это за вас используя rebind и вы не будете парить себе мозг о том, как там List_node устроен и не выводя при этом формулы размеров и выравнивания. И чет приведенный вами аллокатор какой то странный. Allocator 0

@Tenarius 0 / 0 / 0 Регистрация: 04.12.2016 Сообщений: 43
		1
	Опытным программистам С++ 25.01.2018, 16:56. Показов 7780. Ответов 254 Метки нет (Все метки) Здравствуйте, я начал изучать С++. Есть определенный план обучения. Например: сначала изучить синтаксис, принцип ООП, контейнеры STL, стандарты С++11/C++14. Вопрос звучит так: что можно еще добавить в список для изучения? Я еще не определился в какой сфере хочу использовать язык, что нужно знать вообще не привязанная к определенной области? 0

@lArtl 322 / 174 / 78 Регистрация: 09.10.2014 Сообщений: 809
	28.01.2018, 23:30	64
	Сообщение от Renji И в итоге у нас получается монструозная конструкция вида: std::list отвечает требованиям Container, AllocatorAwareContainer, SequenceContainer и ReversibleContainer. AllocatorAwareContainer - контейнером, который содержит экземпляр Allocator и использует этот экземпляр во всех своих функциях-членах для выделения и освобождения памяти, а также для создания и уничтожения объектов в этой памяти (такими объектами могут быть элементы контейнера, узлы). Тобишь он будет хранить не T, а _List_node<T>. Добавлено через 2 минуты Сообщение от Renji Так это важно везде, где с char делается что-то помимо копирования. Например, в лексикографическом сравнении utf-8 строк. Компилятор на этапе компиляции знает, с какими типами он будет работать. 0

@Renji 2784 / 1937 / 570 Регистрация: 05.06.2014 Сообщений: 5,602
	29.01.2018, 00:04	69
	Сообщение от lArtl std::list сделает это за вас используя rebind Ну и как вы используя rebind создадите отдельный пул объектов, для каждого экземпляра списка? Вот создать пул общий для всех std::list<double> да, можно. Но если в пул лезет неизвестное число объектов, то нельзя проконтролировать и верхний лимит расходов памяти в этом пуле. И теряется смысл в подобных оптимизациях - все равно придется куда-то впихивать malloc для расширения пула. В этом собственно и проблема STL-аллокаторов - они писались как обертка вокруг глобального malloc. На "каждый объект сидит в своей песочнице размером в сто элементов" они не рассчитывались. Сообщение от Undisputed Список по определению является динамической структурой данных, что вам даст знание размера ноды на этапе компиляции, и как вы без маллока выделите память для динамической структуры данных, причём на этапе компиляции, зная просто размер этой самой ноды? А я заранее знаю максимальное число элементов в этой структуре. Скажем, если это список фигур на доске, то больше 64 элементов там появиться ну никак не может. Да, в стринге теоретически можно задать тип используемого символа. Но всякие там std::to_string с подобными кастомными строками работать не умеют. И я может быть что-то пропустил, но std::basic_string::find работать с итераторами вроде бы пока не научили. 0

@Undisputed 900 / 477 / 93 Регистрация: 10.06.2014 Сообщений: 2,698
	29.01.2018, 00:26	70
	Renji, Вот вам ещё один вариант для аллокации, и даже с определением размера ноды на этапе компиляции: Аллокаторы имеют шаблонный параметр T, который по идее должен быть выведен как тип ноды (если подсунуть листу свой аллокатор). Что мешает в конструкторе аллокатора выделить память, размер которой будет равен sizeof(T) * fixed_elements_count, и при аллокации использовать выделенный буфер? Вроде то что вы хотели... Добавлено через 1 минуту Я конечно не проверял но вроде должно сработать 0

@lArtl 322 / 174 / 78 Регистрация: 09.10.2014 Сообщений: 809
	29.01.2018, 00:51	72
	Сообщение от Renji Ну и как вы используя rebind создадите отдельный пул объектов, для каждого экземпляра списка? Сделать пул свойством аллокатора? Сообщение от Renji Но если в пул лезет неизвестное число объектов, то нельзя проконтролировать и верхний лимит расходов памяти в этом пуле. И теряется смысл в подобных оптимизациях - все равно придется куда-то впихивать malloc для расширения пула. Это не проблема stl. Сообщение от Renji Да, в стринге теоретически можно задать тип используемого символа. Но всякие там std::to_string с подобными кастомными строками работать не умеют. И я может быть что-то пропустил, но std::basic_string::find работать с итераторами вроде бы пока не научили. std::string = std::basic_string<char>. 0

@Renji 2784 / 1937 / 570 Регистрация: 05.06.2014 Сообщений: 5,602
	29.01.2018, 00:57	73
	Сообщение от lArtl Сделать пул свойством аллокатора? Того аллокатора который второй аргумент в template < class T, class Alloc = allocator<T> > class list? Так он про ListNode ничего не знает, ему T в качестве аргумента сунули. Того аллокатора который получился от rebind? Это временный объект, который через три наносекунды помрет вместе с пулом в нем. Сообщение от lArtl Это не проблема stl. Ага, ага. В нашей библиотеке нет нужного вам функционала? Не наши проблемы. Но возвращаемся к исходному - для нужного функционала придется пилить свой контейнер. Сообщение от lArtl std::string = std::basic_string<char>. А мне надо std::basic_string<unsigned char>. 0

@lArtl 322 / 174 / 78 Регистрация: 09.10.2014 Сообщений: 809
	29.01.2018, 01:30	74
	Сообщение от Renji Того аллокатора который второй аргумент в template < class T, class Alloc = allocator<T> > class list? Так он про ListNode ничего не знает, ему T в качестве аргумента сунули. Того аллокатора который получился от rebind? Это временный объект, который через три наносекунды помрет вместе с пулом в нем. Поэтому std::list будет хранить не allocator<T>, а тот, который мы получим от rebind. Сообщение от Renji Ага, ага. В нашей библиотеке нет нужного вам функционала? Не наши проблемы. Но возвращаемся к исходному - для нужного функционала придется пилить свой контейнер. Если в лоб, то сделать статический член класса равный размеру выделенной памяти в них. Причем тут stl не понимаю. Добавлено через 1 минуту Сообщение от Renji А мне надо std::basic_string<unsigned char>. А что вы скажите насчет std::u16string? Добавлено через 6 минут А вообще работать с локалью и кодировками в stl тот еще гемор, всякие там codecvt и тд 0

@Renji 2784 / 1937 / 570 Регистрация: 05.06.2014 Сообщений: 5,602
	29.01.2018, 01:48	75
	Сообщение от lArtl Поэтому std::list будет хранить не allocator<T>, а тот, который мы получим от rebind. Где конкретно это написано? std::list::get_allocator возвращает allocator<T>, конструктор листа принимает опять же allocator<T>. Мы конечно можем прикинуть что по уму то надо хранить аллокатор полученный от rebind, но вот гарантий этого я не вижу. А раз нет гарантий, то и полагаться на такие умозаключения нельзя. Сообщение от lArtl Если в лоб, то сделать статический член класса равный размеру выделенной памяти в них. Причем тут stl не понимаю.Если в лоб, то сделать статический член класса равный размеру выделенной памяти в них. Причем тут stl не понимаю. Статический член будет один на все экземпляры списка. А нужно чтоб каждому экземпляру свой пул. Сообщение от lArtl А что вы скажите насчет std::u16string? Так разговор то был о char. А так да, можно просто выкинуть из программы все char и использовать wchar_t. 0

@Fulcrum_013 2082 / 1573 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	29.01.2018, 01:50	76
	Сообщение от Renji Ага, ага. В нашей библиотеке нет нужного вам функционала? Не наши проблемы. Но возвращаемся к исходному - для нужного функционала придется пилить свой контейнер. Вот в том то и проблема. Причем она не столько в самой STL которую можно в случае необходимости просто допиливать, а в крайнем (ну или сходу) заменить на что то годное. Проблема в том что коммитет уже 20 лет 2/3 стандарта описывает инструменты точное назначение которых на этапе их псевдоуниверсальной разработки известно быть не может, но при этом неумение самостоятельно пилить такие инструменты канает на отчисление после первого семестра в любом толковом ликбезе. А вот те средства которые нужно добавлять в ядро языка ии которые не могут быть созданы программистом в рамках решения его конкретной задачи в результате всего этого остаются за кадром. 0

@lArtl 322 / 174 / 78 Регистрация: 09.10.2014 Сообщений: 809
	29.01.2018, 02:03	77
	Сообщение от Renji Статический член будет один на все экземпляры списка. А нужно чтоб каждому экземпляру свой пул. Имелось виду size_t, который будет показывать, сколько все аллокаторы выделили память. Сообщение от lArtl Ага, ага. В нашей библиотеке нет нужного вам функционала? Не наши проблемы. Но возвращаемся к исходному - для нужного функционала придется пилить свой контейнер. Еще раз, это не проблема stl. Это проблема пула, который что то там не может предсказать. 0

@Fulcrum_013 2082 / 1573 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	29.01.2018, 02:05	78
	Сообщение от Renji Скажем, если это список фигур на доске, то больше 64 элементов там появиться ну никак не может. так. а зачем там тогда вообще список если их количество заранее известно? Может вектор указателей удобнее и быстрее будет в конечном итоге? 0

@lArtl 322 / 174 / 78 Регистрация: 09.10.2014 Сообщений: 809
	29.01.2018, 02:20	79
	Вот единственное, что аллокатор влияет на тип контейнера... 0

@Fulcrum_013 2082 / 1573 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	29.01.2018, 02:22	80
	Сообщение от lArtl Вот единственное, что аллокатор влияет на тип контейнера... Вопрос в том что пулы константной аллокации для объектов классов давно пора иметь под капотом штатного менеджера кучи а не спорить как их прикручивать библиотечными средствами. 0