Реинициализировать объект C++ в стеке

struct test {
    test( std::string tt )
    { t = tt; }
    std::string t;
};
...
    test tt("1");
    tt.~test( );
    new (&tt) test("2");

а лучче swap реализовать, да.

Placement new

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

в чём вообще состоит идея «создания объекта на том же месте»?

Чтобы имя переменной было одно и то же.

Чтобы имя переменной было одно и то же.

OMG OMG OMG OMG ты серьезно? вон из профессии!

Так это не профессия, это хобби.

И не понимаю, что тут такого. Если бы объект был в куче, не было бы ничего странного. Мне чисто для интереса интересно, можно ли такое сделать, не прибегая к куче, на которую все жалуются, когда ругают C++.

В общем если тебе понадобилось такое, то в консерватории явно что-то не так.

Давай свой случай, и показывай почему именно нужно именно имя и именно тоже самое.

ну вон в первом ответе есть. Только способ корявый. Если конструктор исключение выбросит, то получишь просто кусок памяти с непонятно чем. Лучше swap завести.

Если конструктор исключение выбросит, то получишь просто кусок памяти с непонятно чем.

И чем это грозит? Конструктор не отработал - значит деструктор вызываться не будет, тут всё ок. Память со стека тоже почистится. Можно, конечно, сам placement new в try/catch завернуть, но зачем так делать?

Ты хочешь переиспользовать туже память или просто обращаться по одному и тому же названию?

Если второе, то можешь завести указатель на этот объект и обращаться к нему.

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

это тем грозит, что по стандарту это UB для нетривиальных конструкторов-деструкторов. а в случае ТСа объект культи точно имеет нетривиальные конструкторы и деструкторы.

кучу ругают либо аристократы, либо дегенераты.

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

да говноед он

Кажется, заработало, спасибо. Но нужно ли в данном случае вызывать delete?

Хотя скорее всего перепишу на кучу.

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

Можно подробнее где именно и откуда возьмётся UB?

дядя, ты дурак? в конце блока вызовется десруктор для десрукторнотого объекта. дабл деструкт, что очень весело как бы, да.

obj = MyClass(param);

В общем случае оно как раз не прокатит, ибо operator= может быть перегружен и делать ничего.

Пересоздание объекта на стеке вообще делается через ручной вызов деструктора и placement_new по адресу объекта. Если это надо, конечно

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

Аффтар, пеши исчо !

Но нужно ли в данном случае вызывать delete?

Разве что для стека. Не нужно, в общем.

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

noncopyable от нефиг делать не делают. и если авторы сделали объект таким, значит, во-первых, там кастомные конструкторы-деструкторы и, во-вторых, не надо выпендриваться, а нужно использовать стандартные методы работы с такими объектами. а все ваши извращения с UB могут не выстрелить при тестировании, но вылезут где-то позже. и будет весело. вы тут дурные идеи нубам подбрасываете, а потом вся эта пионерия с кривыми велосипедами лезет сюда с вопросами «ой, а почему у меня непонятно где программа падает?!».

в конце блока вызовется десруктор для десрукторнотого объекта.

Да, ты прав, это я туплю.

Аффтар, пеши исчо !

Ну протупил, с кем не бывает. В «обычных условиях» всё-таки это правило выполняется.

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

Нет. Это ничего не значит кроме как «в объекте сейчас непонятно что, так как конструктор выкинул исключение».

Кароч. И используй каноничный вариант с кучей

MyClass* obj = new MyClass(param);
....
delete obj;
obj = new MyClass(param1);

Why not? Happy hacking!

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

Тупнякотред

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

Чтобы имя переменной было одно и то же.

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

MyClass obj(param1);
{
  MyClass obj(param2);
  ...
}

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