Стратегия выделения/освобождения памяти

@просто_спросить · Регистрация: 16.07.2015

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

здравствуйте господа. есть такой вопрос. пусть есть класс например Bitmap - несжатое растровое изображение. Пусть необходимо уметь считывать этот bitmap из файлов различных форматов. пусть за работу с каждым форматом отвечает свой класс. например IoBmp, IoTiff, IoPng. например за считывание битмапа из IoBmp отвечает какой-нибудь статический метод IoBmp::open(const std::string &fileName). вопрос как бы поудобнее это дело организовать. именно, если сделать так:

C++
1
2
3
4
static Bitmap IoBmp::open(/*...*/) {
    //...
    return Bitmap(/*...*/);
}

битмап нельзя будет считать в кучу (Bitmap* bmp = new Bitmap(IoBmp::open(...)) не в счет - не хочется копировать растр. хотя?...). если

C++
1
2
3
4
static Bitmap* IoBmp::open(/*...*/) {
    //...
    return new Bitmap(/*...*/);
}

память под битмап будет динамически выделена внутри этого open и удалить мы его вообще говоря не сможем. конечно, delete bmp; вне метода open сработает, но так делать нельзя.
так и тянет написать что-то вроде

C++
1
2
3
void Bitmap::free() {
    delete this;
}

чтоб получилось

C++
1
2
Bitmap* bmp = IoBmp::open(fileName); //IoBmp знает как выделена память
bmp->free(); //Bitmap знает как ее освободить. внешней программе пофиг,но все равно нехорошо как-то

можно ли так делать?
или так?

C++
1
2
3
4
5
static void IoBmp::free(Bitmap* bmp) {
    delete bmp;
}
Bitmap* bmp = IoBmp::open(fileName);
IoBmp::free(bmp);

ну и как вариант сделать что-то вроде того:

C++
1
2
3
4
5
static size_t IoBmp::getSize(const std::string &fileName);
static void IoBmp::open(Bitmap* bmp, const std::string &fileName);
Bitmap* bmp = new Bitmap(IoBmp::getSize(fileName)); //выделяем память под битмап по данным из файла
IoBmp::open(bmp, fileName); //читаем из файла растр
delete bmp;

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

@просто_спросить · 17.07.2015, 17:57 **[ТС]**

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

если после прочтения этого абзаца вам не понятно

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

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

все поймете позже

@Fallenworld · 17.07.2015, 18:23

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

рецепт, как изготовить сишный говнокод?

кто мешает внутри фабрики сделать список всех созданных обьектов? фабрика часто строится по паттарнеу одиночка, поэтому с удалением фабрики скорее всего и вся часть системы работавшая с обьектами тоже удалится

Добавлено через 7 минут
Прошу прощения, внимательно посмотрел код примера и увидел, что так и сделано.

@ForEveR · 17.07.2015, 19:37

просто_спросить, make_shared использовать лучше. Конструктор shared_ptr был изначально, а учитывая, что раньше не было variadic templates, а boost::make_shared не умел принимать больше 9-10 аргументов (да, это не лучший стиль, но иногда бывает нужно), то использовался конструктор. make_shared безопаснее потому что делает все в себе, а быстрее потому что сует счетчик и созданный объект в одну область динамической памяти, в то время как в конструктор мы уже подаем созданный указатель, поэтому счетчик находится в другой области памяти.
Тут описано лучше, при нормальном знании английского советую почитать: http://stackoverflow.com/quest... d-ptr-in-c

@просто_спросить · 17.07.2015, 20:45 **[ТС]**

угу,там упоминаются ситуации,когда следует использовать конструктор. правда про custom deleter никаких объяснений, но надо будет поподробнее об этом почитать. а так все сводится к вашему ответу о том,что с конструктором имеем две независимые области,а с make_shared одну общую.

Новые блоги и статьи Все статьи Все блоги /
Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .
Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .	Фото: Daniel Greenwood kumehtar 13.11.2025	Расскажи мне о Мире, бродяга kumehtar 12.11.2025 — Расскажи мне о Мире, бродяга, Ты же видел моря и метели. Как сменялись короны и стяги, Как эпохи стрелою летели. - Этот мир — это крылья и горы, Снег и пламя, любовь и тревоги, И бескрайние. . .

@ForEveR В астрале 8049 / 4806 / 655 Регистрация: 24.06.2010 Сообщений: 10,562
	17.07.2015, 19:37
	просто_спросить, make_shared использовать лучше. Конструктор shared_ptr был изначально, а учитывая, что раньше не было variadic templates, а boost::make_shared не умел принимать больше 9-10 аргументов (да, это не лучший стиль, но иногда бывает нужно), то использовался конструктор. make_shared безопаснее потому что делает все в себе, а быстрее потому что сует счетчик и созданный объект в одну область динамической памяти, в то время как в конструктор мы уже подаем созданный указатель, поэтому счетчик находится в другой области памяти. Тут описано лучше, при нормальном знании английского советую почитать: http://stackoverflow.com/quest... d-ptr-in-c 2

@просто_спросить 0 / 0 / 0 Регистрация: 16.07.2015 Сообщений: 7
	17.07.2015, 20:45 [ТС]
	угу,там упоминаются ситуации,когда следует использовать конструктор. правда про custom deleter никаких объяснений, но надо будет поподробнее об этом почитать. а так все сводится к вашему ответу о том,что с конструктором имеем две независимые области,а с make_shared одну общую. 0