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

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

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

Здравствуйте, я начал изучать С++. Есть определенный план обучения. Например: сначала изучить синтаксис, принцип ООП, контейнеры 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++
1
2
3
4
5
6
7
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

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

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

Новые блоги и статьи Все статьи Все блоги /
Запрет пометки на удаление и отмены проведения Maks 16.07.2026 Алгоритм из решения ниже реализован на нетиповом документе "ПутевойЛист" разработанного в КА2. Задача: запретить помечать на удаление и отменять проведения путевого листа при условии, если он сдан. . .	Как надо было делать правильно - вообще не слушать ИИ, его дело - текст. Hrethgir 15.07.2026 А вообще надо было делать не так, чтобы не исправлять ошибку https:/ / www. cyberforum. ru/ blogs/ 223907/ 10996. html , правильно было : удалил кнопку, а потом добавил её. Всё это стресс конечно. Почему?. . .	Знаете, от чего появляется стресс? kumehtar 15.07.2026 Стресс появляется оттого, что вы, зная как поступить правильно, делаете наоборот. Ларри Уингет	Нас бьют, а мы крепчаем? Какая чушь! kumehtar 15.07.2026 Вот это вот бытующее мнение, что человек меняется только под действием проблем, всегда считал вредоносным. Поверь, от проблем у людей появляются не изменения, а нервное расстройство и ПТСР. А. . .
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .

@Tenarius 0 / 0 / 0 Регистрация: 04.12.2016 Сообщений: 43

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

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

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

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