Стек или куча: как "правильно" создавать объекты классов?

@JavaFX2 · Регистрация: 21.07.2016

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

У меня несколько странновато-ламерский вопрос, но ведь в том и смысл: чтобы таких вопросов не осталось, на них один фиг сначала нужно где-то получить ответы.

Когда нужно создавать объекты через указатель, а когда - статично? Я по возможности хочу придерживаться одного стиля, но вот проблема - не знаю какого

C++
1
2
3
4
5
MyClass* c1 = new MyClass();
c1->foo();
 
MyClass c2 = MyClass(); // MyClass с2();
c2.foo();

Что известно мне. То, что в первом случае объект размещается в динамической памяти, а во втором - в статической (т.е. на этапе компиляции). Но что это дает мне, как программисту? Какая мне разница, когда и какая выделяется память для моих переменных? К ним обоим есть доступ, с ними обоими можно работать. А что еще для счастья надо?

А если мне эти объекты нужно передавать в качестве аргументов функции, то для второго случая я просто использую передачу по ссылке. Уменьшу себе кол-во стрелочек и звездочек (а заодно и кол-во выстрелов себе в ногу из-за потенциальных проблем с указателями). Получается, что статичная инициализация даже предпочтительнее? Тогда почему именно указатели вижу чаще в коде других людей? Очевидно, я чего-то не знаю, вот и интересно, что именно.

Знаю, что в первом случае для осовобождения памяти применяется delete (ну, по-хорошему). Получается, что для второго случая освобождать память не требуется? Всё потому, что она ~~статична~~ занимается раз и навсегда? Верно?

Также я знаю, что динамическое создание объектов применяется если размер объекта неизвестен. Правда тут во всех примерах упоминают только массивы, и с ними мне как раз всё понятно. Но подобное про класс я ничего нигде не видел. И даже если внутри класса будут те же динамические массивы, почему я все равно могу использовать вторую запись?

Может быть вся "проблема" в этой самой статичной памяти? Перефразируя свой первый вопрос, задам последний вопрос: где, в смысле в какой памяти, предпочтительнее размещать объекты в своих программах, и почему?

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

Байт · 18.02.2017, 12:12

Renji, В общем-то я с вами согласен. Вот у меня есть такая привычка. Все диалоги (модальные) создаю в стеке. Ибо их жизнь ограничивается телом метода, в котором они вызваны. Поговорил - и хватит. Но все их подвиджетики, конечно, в куче. И все остальное, чья жизнь зависит от каприза пользователя, тоже туда же.

@altmax · 18.02.2017, 12:21

Статичные объекты создаются статично, динамичные - через вызов new. Т.е. если объект не изменяется во время рантайма, то можно и просто объявить экземпляр объекта. Если же объект класса изменяется - т.е. удаляется и вместо него генерируется другой объект того же класса - то через new и указатель. Это общее правило, которому я обычно следую.
Но есть нюансы. Иногда в другие классы нужно передать указатель на другие классы - это если они тесно взаимодействуют. Это гораздо проще сделать, если объявлять объекты динамически - мы сразу имеем указатель на объект без лишних телодвижений. Паттерн "Фабричный метод", который применяется почти везде - только через указатели работает. Ну и т.д. Да и вообще Computer Science движется в сторону указателей. В Java всё работает по сути через указатели, интерфейс только чуть другой чем в С++.
Хотя если создается много объектов одного класса - это проще решить через массив объектов, чем через массив указателей - меньше кода писать.
Это всё сугубо мое мнение.

@Undisputed · 18.02.2017, 14:24

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

Если кратко, с помощью них организовывается полиморфное поведение в программе. Правда, его можно организовать и с помощью ссылок, но этот момент мне менее понятен

У указателей в данном контексте есть определенное преимущество. В случае с указателями есть возможность объявить указатель на базовый класс но присвоить ему значение позже. С ссылками такое не прокатит, потому что они должны быть инициализированы в момент объявления.

@Lyosha12 · 18.02.2017, 14:28

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

У указателей в данном контексте есть определенное преимущество. В случае с указателями есть возможность объявить указатель на базовый класс но присвоить ему значение позже. С ссылками такое не прокатит, потому что они должны быть инициализированы в момент объявления.

Тогда отличий, получается, нет? Философия остаётся той же: ссылка есть автоматически разыменованный указатель?

@Undisputed · 18.02.2017, 14:54

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

Тогда отличий, получается, нет?

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <iostream>
 
struct Foo
{
    int n ;
};
 
void foo(Foo &f)
{
    f.n = 300;
}
 
int main()
{
    Foo *f = new Foo();
    f->n = 200;
    foo(*f);
    std::cout << f->n;
}

В общем указатели более функциональны нежели ссылки.

Croessmah · 18.02.2017, 16:45

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

Тогда отличий, получается, нет? Философия остаётся той же: ссылка есть автоматически разыменованный указатель?

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

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

Когда нужно создавать объекты через указатель, а когда - статично?

Введем для этого пояснения такое понятие, как время жизни объекта (object lifetime).
Будем считать, что объект начинает жизнь тогда, когда под
него выделилась память и завершилась его инициализация.
Всякие отводы, тонкости и заковыки рассматривать не будем.

Объект умирает, когда память им занимаемая была освобождена
или деструктор (если он есть и не тривиальный) объекта был вызван.

Итак, для начала рассмотрим коротенько четыре "времени хранения" (storage duration).

Статическое время хранения (static storage duration) - всё статическое живет от момента
создания до самого конца программы.

Потоковое время хранения (thread storage duration) - всё потоковое живет от момента
создания до конца потока в котором создано.

Автоматическое время хранения (automatic storage duration) - всё автоматическое живет от момента
создания до конца блока в котором оно было создано.

Динамическое время хранения (dynamic storage duration) - всё динамическое живет от момента
создания до того момента, пока его явно не прихлопнут.

Соответственно уже отсюда можно сделать вывод что нам необходимо.
A. Если объект должен жить всю программу (ну, почти), то варианта два:
1) Использовать объект с потоковым временем хранения,
ежели у нас имеется один, живущий всю программу поток.
2) Использовать объект с статическим временем хранения.
0) Еще вариант, использовать динамический объект,
но для его корректного уничтожения придется либо
в какой-то из функций его явно уничтожить, что как бы
уже подразумевает, что объект живет меньше чем статические объекты,
либо же в деструкторе одного из статических объектов уничтожить и наш
динамический объект, только вот получается, что нам для этого
нужен статический объект, так что такой вариант не рассматриваем.
Вариант не уничтожать его совсем - система прихлопнет память,
рассматривать не будем, т.к. для объектов не будет вызван деструктор,
а мы рассматриваем общее для всех объектов, а не отдельных их "видов".
Так что для "чистоты эксперимента" подобные варианты мы не рассматриваем.
Также выбросим из повествования временные объекты.

B. С потоковыми объектами, практически также,
как и со статическими, только в масштабах потока,
так что расписывать не буду, ибо и так ясно.

C. Если нам нужен объект, который должен быть уничтожен
после выхода из блока, в котором создался, то варианта два:
1) Использовать автоматический объект.
2) Использовать динамический объект, но при этом
придется вручную его создавать и уничтожать.

D. Если нам необходимо, чтобы объект, созданный в блоке жил
до самого конца программы (или потока),то вариант у нас один:
1) Сделать его статическим объектом, ну или потоковым, если речь о потоке.
0) С динамическим объектом та же фигня, что и в прошлый раз -
до конца такое не доживет, либо уничтожится не правильно (в общем случае).

E. Если нам необходимо, чтобы объект жил после выхода из блока в
котором создан, но мы не знаем до какого времени он нам понадобится и,
жить ему всю программу не нужно, то здесь вариант тоже один:
1) Динамический объект.

Теперь по каждому пункту отдельно.

A. Потоковый или статический?
А смотрим на программу. У нас планируется всего один поток?
Если да, то нефиг пытать потоковый класс памяти.
Если же потоков может быть несколько,
то у каждого потока должна быть своя такая переменная?
Если да, то потоковый берем, если нет - статический.

B. см. предыдущий пункт.

C. Автоматический или динамический?
Объекты маленькие, их количество известно и они точно влезут в стек (без фанатизма)?
Если да то использовать автоматические объекты или динамические
зависит от хотелок разработчика и здравого смысла.
Если не нужна динамика, то нафиг заниматься ручной работой?
Но если очень хочется, то можно хоть каждый int делать динамическим.
Если же объекты тяжелые и не хочется на них тратить стек,
или же нам неизвестно конечное количество одновременно
живущих элементов, то тут только динамические объекты прокатят.
Вариант "создам здоровый массив на все случаи жизни"
здесь не прокатит, т.к. выше оговорено, что конечное количество одновременно
живущих объектов неизвестно и, соответственно, оно всегда будет равно sizeof(mySuperArray)/sizeof(*mySuperArray) + 1.

D. Всё как и прежде - смотрим на потребности в каждом потоке.

E. Без вариантов.

В программах, чаще всего, встречается смесь из всего
высказанного выше в разных пропорциях и сочетаниях.

Вот такая абсолютно бесполезная портянка,
т.к. она всё равно не покрывает всего и вся
и не является истиной в последней инстанции.

@Lyosha12 · 18.02.2017, 16:53

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

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

О, контекст, великий и всемогущий! Да, всё, что Вы сказали - просто описали моё интуитивное поведение при выборе места, куда поместить объект. Я же говорил об отличиях ссылки от указателя при реализации полиморфного поведения

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

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

Также выбросим из повествования временные объекты.

А жаль, про могло бы быть самое интересное чтиво, ведь именно с такого рода объектами мне не до конца всё понятно: это я про и оптимизации, и про std::move()

Croessmah · 18.02.2017, 16:58

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

Я же говорил об отличиях ссылки от указателя

А я отвечал на вопрос ТС

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

Когда нужно создавать объекты через указатель, а когда - статично?

поэтому специально пару лишних строк пропустил.
правда тут явное несоответствие в вопросе.

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

А жаль, про могло бы быть самое интересное чтиво

Оно будет вне заданной тематики.

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

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

это я про и оптимизации, и про std::move()

Про это планируется блог...
Ну, собственно, давно уже планируется,
увы, но времени нет на такую писанину.

Новые блоги и статьи Все статьи Все блоги /
Транскрипция 55-минутного видео через Whisper: WhisperDesktop облажался, спас Google Colab[ anaschu 01.06.2026 Понадобилось получить текст из свежезагруженного видео на YouTube. Казалось бы, задача на пять минут. Заняла полтора часа. Делюсь опытом — может кому пригодится последовательность решений. . . .	21 мат мед. Планы на развитие модели здравоСохранения anaschu 01.06.2026 AnyLogic: план развития симуляционной модели рабочего коллектива — динамический абсентеизм, реальные данные, три сценария сравнения Продолжаю серию постов о дискретно-событийной модели рабочего. . .	20. Мат мед. Абсентеизм как отдельный тип простоя anaschu 29.05.2026 Апдейт модели: исправленные баги, абсентеизм и новые механизмы Продолжаю развивать ранее описанную модель рабочего коллектива на AnyLogic. За последние несколько дней был проведён серьёзный. . .	19. здоровье, усталость и психотип работника влияют на производительность предприятия, и наоборот, производительность на здоровье, усталось и психотип anaschu 28.05.2026 Дискретно-событийная модель рабочего коллектива на AnyLogic: здоровье, выгорание, психотипы и микростимуляция Привет, коллеги. Хочу поделиться итогами нескольких недель работы над симуляционной. . .
"Прокси" для последовательного порта Eddy_Em 28.05.2026 Эту штуку написал я достаточно давно. Но сейчас вот понадобилось настроить датчик грозы, но при этом не отключать его от "метеодемона". Соответственно, надо запустить этот "прокси": метеодемон будет. . .	Рефакторинг программы уравнивания. Massaraksh7 26.05.2026 Пример по предыдущей записи в блоге. Но, надо заметить, что, во-первых, там оптимизация не только математики, но и работы с базой данных, и с графами, а во-вторых, это ещё не всё.	Использование TThread в Lazarus для математических вычислений. Massaraksh7 25.05.2026 Производя рефакторинг своих программ на предмет ускорения их работы, обратил внимание на такой аспект, как сокращение времени матвычислений. Дело в том, что приходится работать с большими матрицами. . .	Модель здравосохранения 18. Чем здоровее работник, тем быстрее выгорает anaschu 24.05.2026 Имитационная модель корпоративного здравоохранения: что показывает математика Сегодня в модели рабочего коллектива на AnyLogic появились три новые механики — выгорание через накопленную усталость,. . .

Байт Диссидент 27714 / 17332 / 3810 Регистрация: 24.12.2010 Сообщений: 38,978
	18.02.2017, 12:12
	Renji, В общем-то я с вами согласен. Вот у меня есть такая привычка. Все диалоги (модальные) создаю в стеке. Ибо их жизнь ограничивается телом метода, в котором они вызваны. Поговорил - и хватит. Но все их подвиджетики, конечно, в куче. И все остальное, чья жизнь зависит от каприза пользователя, тоже туда же. 1

@altmax 187 / 54 / 19 Регистрация: 23.12.2016 Сообщений: 167
	18.02.2017, 12:21
	Статичные объекты создаются статично, динамичные - через вызов new. Т.е. если объект не изменяется во время рантайма, то можно и просто объявить экземпляр объекта. Если же объект класса изменяется - т.е. удаляется и вместо него генерируется другой объект того же класса - то через new и указатель. Это общее правило, которому я обычно следую. Но есть нюансы. Иногда в другие классы нужно передать указатель на другие классы - это если они тесно взаимодействуют. Это гораздо проще сделать, если объявлять объекты динамически - мы сразу имеем указатель на объект без лишних телодвижений. Паттерн "Фабричный метод", который применяется почти везде - только через указатели работает. Ну и т.д. Да и вообще Computer Science движется в сторону указателей. В Java всё работает по сути через указатели, интерфейс только чуть другой чем в С++. Хотя если создается много объектов одного класса - это проще решить через массив объектов, чем через массив указателей - меньше кода писать. Это всё сугубо мое мнение. 0

Стек или куча: как "правильно" создавать объекты классов?

Решение