[Solved] Requirement of default constructors and validity of class instances
-
I have been in a habit of disabling construction of objects in an empty or invalid/incomplete state. However, if I want to use signal slot mechanism, I am forced to have a default constructor, for which I have to throw my habit out of the window. it means that my objects could be constructed in an invalid state.
I am wondering how to get around this.Also, say, if a method is called on an invalid object, how to handle that situation? I used to throw exceptions in C#. In Qt, I find the usage rather uncommon, or at least awkward, given the issues of handling uncatched exceptions.
-
Hi,
First of all the exception handling is discussed in length in the forum. Take a look there and ask it in a separate post.
On your first issue:
For Signal/Slot to work you do not need a default constructor! Only a constructor will be enough if you subclass QObject and use the Q_OBJECT macro in your class definition.
You may have eg:
@
explicit void MyClass(quint32 MyId, QObject * parent = 0);
@
as constructor and make the default constructor private so an empty class may not be constructed.
I do this all the time, because like you said, it's a bad thing to have a "uninitialized" class waiting for a crash. -
I had to face the issue of the default constructor when I had wanted to register a class in qRegisterMetaType.
And, regarding a custom constructor, how should an invalid argument - say, a nullptr or an essential, but empty QString? If I create an object from such arguments, it will still be invalid (specially a nullptr gives me creeps).
Forgive me if I am being silly, but I am baffled as to how to handle such situations in Qt.[quote author="Jeroentje@home" date="1376579245"]Hi,
First of all the exception handling is discussed in length in the forum. Take a look there and ask it in a separate post.
On your first issue:
For Signal/Slot to work you do not need a default constructor! Only a constructor will be enough if you subclass QObject and use the Q_OBJECT macro in your class definition.
You may have eg:
@
explicit void MyClass(quint32 MyId, QObject * parent = 0);
@
as constructor and make the default constructor private so an empty class may not be constructed.
I do this all the time, because like you said, it's a bad thing to have a "uninitialized" class waiting for a crash.[/quote] -
Hi,
If you take a look at i.e. QDateTime and similar classes or QModelIndex, you'll see that their default construction state is invalid and they provide the isValid() method to check that.
It's pretty common through Qt to handle that case like that:
@
{
if (!myVariable.isValid())
return;// standard code path is the index is valid
}
@ -
OK. That looks good. It also seems that documenting the API is as important as safeguarding the code.
[quote author="SGaist" date="1376598226"]Hi,
If you take a look at i.e. QDateTime and similar classes or QModelIndex, you'll see that their default construction state is invalid and they provide the isValid() method to check that.
It's pretty common through Qt to handle that case like that:
@
{
if (!myVariable.isValid())
return;// standard code path is the index is valid
}
@[/quote] -
Indeed, without good documentation, an API gets hard to use and looses interest.
Just have a look at Qt's documentation, pretty much complete and clean. One of the best you can find.
