Оператор new Опции

[haiflive]

Прошу разъяснить мне давно волнующую меня тему..
Вопрос про оператор new, в чём разница между этими двумя функциями?. какой вариант предпочтительней и почему?.

Функция 1:

void myFunction()
{
    myObject* obj = new myObject;
    /*...*/
    delete obj;
}

Функция 2:

void myFunction2()
{
    myObject obj;
    /*...*/
}

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

[Алексей1153]

первое - создание переменной в куче, второе - на стеке. Куча - "неудобная, но резиновая", стек - "удобный, не резиновый". Хотя, всё зависит от опыта использования )

>>Почему я сплошь и рядом наблюдаю первый вариант?
покажи пример

[Iron Bug]

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

[Litkevich Yuriy]

А ни всё ли равно?

нет, т.к. во-втором случае, как только выйдешь из функции - объект умрёт, а в-первом случае - останется жить. И, если ты сохранишь указатель на объект в-первом случае, то сможешь к этому объекту обращаться в будущем.

Насчёт скорости ничего сказать не могу..

объекты созданные на стеке (второй вариант), создаются "сразу", скорость дальнейшей их работы одинакова с первым вариантом.

Почему я сплошь и рядом наблюдаю первый вариант?

Если для примера взять Qt и его QObject, то в этом классе не предусмотрены операторы присваивания и конструкторы копирования, т.к. это не тривиальные операции для данного (навороченого) класса и его наследников. Это и является причиной создания объектов в куче и работа с ними через указатель.

П.С.
По-этому всюду в функциях библиотеки предусмотрен в качестве входного аргумента указатель на QObject.

[haiflive]

Спасибо всем за исчерпывающие ответы.

стек - "удобный, не резиновый"

Насколько он не резиновый?. или это зависит от компилятора?. Компилятор MinGW напритмер?

>>Почему я сплошь и рядом наблюдаю первый вариант?
покажи пример

Наверное я слишком часто читал книги по QT, вот там просто пистрит подобными примерами..

#include <QtGUI>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    
    QSplitter   spl(Qt::Vertical);
    QTextEdit*  ptxt1 = new QTextEdit;
    QTextEdit*  ptxt2 = new QTextEdit;
    spl.addWidget(ptxt1);
    spl.addWidget(ptxt2);
    
    ptxt1->setPlainText("Line1\n"
                        "Line2\n"
                        "Line3\n"
                        "Line4\n"
                        "Line5\n"
                        "Line6\n"
                        "Line7\n"
                        );
    ptxt2->setPlainText(ptxt1->toPlainText());
    spl.resize(200,200);
    spl.show();
    
    return a.exec();
}

нет, т.к. во-втором случае, как только выйдешь из функции - объект умрёт, а в-первом случае - останется жить. И, если ты сохранишь указатель на объект в-первом случае, то сможешь к этому объекту обращаться в будущем.

Это я понимаю, но рассматривается случай(как любаят писать при доказателствах теорем: "в том и только в том случае"), когда обект создан в начале и удалён в конце функции. Хотя является плохим тоном переносить обязанность удаления обекта на клиента, стараюсь избегать этого..

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

Знаю про "умные указатели", но не использую их так как пока пишу только для десктопа.. просто голова кругом идёт когда начинаешь использовать эти умные казатели, а вот про пулы переменных почитаю.. что-то не слышал.

[haiflive]

Вот нагуглил такое правило, думаю его и буду придерживаться:

для локальных данных функции лучше подходит стэк для всего остального куча.
Если объем данных превышает некое пороговое значение (начиная с 4КБ) или размер данных динамический то можно начинать думать о размешении их в куче.

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

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

Всем спасибо за ответы.

[Litkevich Yuriy]

haiflive, тут всё просто: Если объект должен жить за пределами функции в которой он создан - без new никуда.
И если объект сложный, обычно со скрытыми оператором присваивания и конструктором копирования - без new никуда.

[Iron Bug]

Знаю про "умные указатели", но не использую их так как пока пишу только для десктопа.

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