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

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

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

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

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

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

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

0

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

1

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

0

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

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

1

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

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

0

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

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

1

Сообщение от 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. Без вариантов.


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


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

9

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

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

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

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

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

0

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

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

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

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

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

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

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

Сообщение от Lyosha12 это я про и оптимизации, и про std::move()

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

1