Нужен материал для статьи про управление памятью в С++

Добрый день всем, хотел бы написать статью. О управлении памятью С++. Скорее всего речь пойдет о оператов new и delete.
Скажите пожалуйста откуда можно взять такой богатый материал?

0

Renji, make_shared для кого придумали?

Добавлено через 2 минуты
Nick Alte, дождались таки mak_unique. Я был удивлен, когда не обнаружил его в C++11 )))

0

Сообщение от Renji Код C++ 1 2 3 4 5 6 struct my_abstract_class { public: virtual void method()=0; }; std::vector<my_abstract_class>test;

Нельзя создать экземпляр абстрактного класса, но не его потомка, а если сюда сложить указатели, то для создания объекта опять понадобится new. проблему не решит, так как std::vector<my_abstract_class> ни куда не делся и ни одного элемента не имеет. Но контейнер экземпляров абстрактного класса может понадобиться. Ни один стандартный контейнер от new/delete в пользовательском коде не спасает, соответственно не допустим, так как new/delete должны быть только в членах контейнеров.

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

Сообщение от Nick Alte Однако же если с детским задором бросаться разрабатывать свой контейнер на каждый чих, при этом искренне полагая себя во всём мудрее и опытнее разработчиков стандартных контейнеров, это станет источником как ненужных трудозатрат, так и несовместимости, уменьшенной читаемости кода и потенциальным источником дополнительных ошибок.

1. О каждом чихе речи не было.
2. При чём здесь мудрость? Передо мной стоит конкретная задача, которую стандартисты в глаза не видели. Ну и как они смогут угадать, что мне нужно? Они что инопланетяне? Тогда да, не мне тягаться со сверхцивилизацией, она уже прошла всё, что недоразвитые могут взяться решать, соответственно все комитетчики знают все задачи из истории. Или может они вообще боги? Тогда на их сверхмудрость и абсолютное знание тоже можно положиться. Только вот беда: они такие же земные программисты. Ну а тогда откуда такие претензии? Соберите в ГАК сколько угодно профессоров, академиков и дважды членкоров, они хором будут дипломный проект знать хуже, чем всего лишь студент, данный диплом защищающий. Просто потому, что он по этой теме работал, а они нет.

0

Сообщение от taras atavin А ничего, что они основаны на опыте реальной работы?

Конечно "ничего".


Кто-то сам постоянно явно вызывает new. Новички например, в своих хэлловорлдах.

Кто-то не делает то, что за них может сделать надежный и проверенный механизм.
А кто-то создает эти самые механизмы.

Всякое бывает.

Но называть бредом стремление не делать то, что с тем же успехом можно было бы и не делать - это наивно.
По меньшей мере.
А вообще это просто глупо.

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

Сообщение от taras atavin Нельзя создать экземпляр абстрактного класса, но не его потомка, а если сюда сложить указатели, то для создания объекта опять понадобится new.

смартпоинтеры? Не, не слышал.

0

Сообщение от hoggy смартпоинтеры? Не, не слышал.

А нафиг усугублять то?

0

Сообщение от Renji А чтобы получить эти указатели нужен new.

Возможно вы упустили момент подобный следующему?

0

Сообщение от Ilot C++ 1 2 std::vector<a*> vec; vec.push_back(&a);

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

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

Сообщение от hoggy Кто-то не делает то, что за них может сделать надежный и проверенный механизм. А кто-то создает эти самые механизмы. Всякое бывает. Но называть бредом стремление не делать то, что с тем же успехом можно было бы и не

Я ни где не призывал из принципа делать свои контейнеры. Если есть подходящий стандартный, то его надо использовать. Бред является совет всегда упираться в стандарт.

0

Пока не изобрёл свой велосипед, чужим не пользовался.

0

taras atavin, на выдерайте слова из контекста. Я писал о совершенно другом и совсем не вам.

0

Сообщение от taras atavin Я ни где не призывал из принципа делать свои контейнеры. Если есть подходящий стандартный, то его надо использовать. Бред является совет всегда упираться в стандарт.

Упираться куда то там никто и не предлагал, если чо.

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


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

0

Стандартные контейнеры должны появляться так:
1. Прикладник решает задачу, ему нужен контейнер, он читает стандарт, нужного контейнера не находит, пишет свой, потом он решает другие задачи, нужны контейнеры, читает стандарт и свои записки, требуемый контейнер часто находит у себя, причём, один и тот же в разных задачах, публикует своё решение, комитетчики читают, решают ввести данный контейнер в новую версию стандарта.
2. Прикладник решает задачу, ему нужен контейнер, он читает стандарт, нужного контейнера не находит, пишет свой, потом он решает другие задачи, нужны контейнеры, читает стандарт и свои записки, требуемый контейнер часто находит у себя, причём, один и тот же в разных задачах, набравшись опыта сам входит в состав комитета, предлагает свой контейнер остальным комитетчикам, комитетчики совместно решают ввести данный контейнер в новую версию стандарта.
3. Комитетчик, сам выступая в роли прикладника, решает задачу, ему нужен контейнер, он читает стандарт, нужного контейнера не находит, пишет свой, потом он, также выступая в роли прикладника, решает другие задачи, нужны контейнеры, читает стандарт и свои записки, требуемый контейнер часто находит у себя, причём, один и тот же в разных задачах, предлагает свой контейнер остальным комитетчикам, комитетчики совместно решают ввести данный контейнер в новую версию стандарта.
Тогда стандартный контейнер часто будет востребован во многих программах. И вот в тех случаях, когда опять встретилась задача, требующая снова того же контейнера, надо использовать именно его. Ведь он отлажен. Но если подходящего вдруг не нашлось в стандарте, то писать новый. А при разработке действительно нового контейнера, а не оболочки над std::vector и не комбинации существующих контейнеров new/delete приходится использовать явно. Но new/delete должны быть всегда инкапсулированы в контейнеры. Свои, или чужие - это уже вопрос отдельный и решаться должен в каждом конкретном случае.

0

Сообщение от Croessmah дождались таки mak_unique. Я был удивлен, когда не обнаружил его в C++11

Видимо, сначала решили "ну зачем нам такая тривиальная функция", а потом одумались.

0

А при разработке действительно нового контейнера, а не оболочки над std::vector и не комбинации существующих контейнеров new/delete приходится использовать явно.

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

0

Сообщение от Nick Alte Видимо, сначала решили "ну зачем нам такая тривиальная функция", а потом одумались.

все намного проще: тупо профакапили.
А том, когда обнаружилась пропажа сказали: "да и фик бы с нею! В следующем выпуске запилим".

Добавлено через 53 секунды

Сообщение от taras atavin Но new/delete должны быть всегда инкапсулированы в контейнеры.

Если чо, то стандартные контейнера сами явно new/delete не зовут.
За это отвечает аллокатор.

0

0

0

0

Сообщение от hoggy Если чо, то стандартные контейнера сами явно new/delete не зовут. За это отвечает аллокатор.

Вот malloc как раз - ещё тот атавизм. Начнём с того, что он вообще не знает типов и не умеет вызывать конструкторы.

Добавлено через 2 минуты
Вообще не важно, где, почему и зачем понадобилось выделять и освобождать память. Это всегда можно снести в подзадачу хранения некой составной сущности и при правильной декомпозиции все операции с памятью окажутся спрятаны в неё.

0

Сообщение от taras atavin Вот malloc как раз - ещё тот атавизм. Начнём с того, что он вообще не знает типов и не умеет вызывать конструкторы.

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

Может быть вы просто не в курсе,
что подразуменвается под "аллокатором стандартного контейнера".

Посмотрите, как выглядит шапка шаблона:

http://www.cplusplus.com/reference/vector/vector/
Видите там такой параметр, который по дефолту есть std::allocator<T> ?
Это и есть аллокатор, с которым по дефолту работает любой стандартный контейнер.

Соответственно, пользователь всегда может указать свой собственный, если ему так приспичит.

Казалось бы - и при чем тут маллок вообще?

Когда вы пишите свои ответы, вы вообще думаете на что именно вы отвечаете?

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

Сообщение от taras atavin Вообще не важно, где, почему и зачем понадобилось выделять и освобождать память. Это всегда можно снести в подзадачу хранения некой составной сущности и при правильной декомпозиции все операции с памятью окажутся спрятаны в неё.

А теперь заново перечитайте тезис #10

0

Сообщение от hoggy Вот смотрите, я вам сообщил, что в стандартные контейнеры не сами занимаются выделением/освобождением памяти. А за это отвечает аллокатор. Может быть вы просто не в курсе, что подразуменвается под "аллокатором стандартного контейнера".

Оператор выше уровнем, чем malloc/calloc/realloc. И вообще сам выделяет память только менеджер памяти, а это часть операционной системы, в остальных случаях вопрос лишь в том, что и как вызывать.

0

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

0