Error with unique_ptr
-
I can not find my mistake in using unique_ptr
@/Class Load .ui files hpp/
#ifndef LOADUI_H //if LoadUi.hpp not includ
#define LOADUI_H //include LoadUi.hpp#include <QWidget>
#include <QUiLoader>
#include <QFile>
#include <QString>
#include <memory>using namespace std;
class LoadUi : public QObject
{
public:
explicit LoadUi();
~LoadUi();
QWidget createForm(const QString, QWidget* = 0);private:
unique_ptr<QUiLoader> loader;
unique_ptr<QFile> ui_file;
};#endif@
@/Class load .ui files cpp/
#include "LoadUi.hpp"
LoadUi::LoadUi()
{
}LoadUi::~LoadUi()
{
}QWidget *LoadUi::createForm(const QString *url, QWidget *parent)
{
ui_file (new QFile("Forms/MainWindow.ui"));
loader ( new QUiLoader());
ui_file->open(QIODevice::ReadOnly);return loader->load(ui_file, parent);
}@
-
I found the error. the definition of the pointers were arrested in CreateForm method. I moved from global to local.
@/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);}
@
-
Hi,
Can you explain why do you want to use unique_ptr in that case ? It's no really useful
-
The intention is to avoid manual delete. How would you do in this case?
-
Like in the example:
@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.
-
Always allocate on the stack?
Someone told me that is not a good practice to place objects on the stack. -
I didn't say to always allocate on the stack far from it. I'm just talking about your usage of QString, have a look at the code examples of Qt and the how it is used.
-
understand, correct me if I'm wrong.
In your example, QUiLoad and QFile are being placed on the stack.
-
Yes they are and it's completely fine, why ?
-
I still make confusion concerning the use of stack and heap. Usually I leave the stack primitive types, and put each and every object in the heap. In the style of JAVA.
The theory of using heap says, "Large objects and long lasting." But how to judge it? -
In you example, both QUiLoader and QFile are short lived.
Then it depends on your objects, whether they are big, use lots of memories etc...
-
Since Qt uses implicit sharing and pimpl, the rule of thumb is (with very few exceptions): consider Qt objects small and cheap to pass around and copy(where copyable).
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.
-
[quote author="Exotic_Devel" date="1401309899"]The theory of using heap says, "Large objects and long lasting." But how to judge it?[/quote]That theory is good.
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
