However, you need to know this: Most Qt classes already store their internal data on the heap.

Example:
@
QString longString = largeTextFile.readAll();
@

Let's say that longString contains 2 MB of text. The longString object itself is stored on the stack, but it only takes a few bytes of stack space. That's because the text is stored in the heap, which takes 2 MB of heap space. The stack holds a pointer to the heap data.

So, you can treat Qt objects as "small objects".

[quote author="Chris Kawa" date="1401491792"]Since Qt uses implicit sharing[/quote]Here is an article about "implicit sharing":http://qt-project.org/doc/qt-5/implicit-sharing.html

As for what is short and long lived - if it goes "out" from scope it was created in it's long lived and should be managed manually (either smart pointers or naked new/delete). If you don't pass it or only pass it "in" eg. as function params in the same scope then it's considered to be short-lived(or local) and you should use RAII and automatic variables.

Note that it gets complicated with multithreading but that's another story.

Then it depends on your objects, whether they are big, use lots of memories etc...

In your example, QUiLoad and QFile are being placed on the stack.

@QWidget *LoadUi::createForm(const QString url, QWidget *parent)
{
QUiLoader loader;
QFile file(url);
file.open(QFile::ReadOnly); // add check here unless you did before
QWidget *widget = loader.load(&file, parent);
file.close();
return widget;
}@

Also, why are you using const QString * ? Just use a const reference, theres no need to allocate QString on the heap.

Can you explain why do you want to use unique_ptr in that case ? It's no really useful

@/Class load .ui files cpp/

#include "LoadUi.hpp"

LoadUi::LoadUi()
{
}

LoadUi::~LoadUi()
{
}

QWidget *LoadUi::createForm(const QString *url, QWidget *parent)
{
unique_ptr<QUiLoader> loader ( new QUiLoader());
unique_ptr<QFile> ui_file (new QFile("Forms/MainWindow.ui"));

return loader->load(ui_file, parent);

}

@