With some optimizations turned on (already with -O1), GCC and Clang optimize that down to basically using new directly.
But, (!) MSVC creates does not optimize that away. Even not with -O2 (–> https://godbolt.org/g/JWR8Pu)!
Just worth noting. Using new features is not always the best way to go.
PS: In addition, a QWidget that is not a top-level window has a natural parent that is also the QObject parent and thus owns the object. Hence, it is outright dangerous to use smart pointers of any kind (other than those Qt ones that are explicitly designed for QObject) on them because of the potential for double-free bugs (though your particular code snippet is safe because the smart pointer is really just abused to perform a trivial new).
Just limiting myself to GSL’s recommended approach to memory management to stay in scope of Sune’s post:
* Qt’s parent-child hierarchy is fundamentally incompatible with the GSL’s proposed model of ownership.
* Qt data types do not support move-only types.
* Qt’s multithreading is based on Qt types (e.g. QFuture), so that those do not support move-only types either.
I am moving more and more code away from Qt-types to corresponding std-types with move semantics. They are so much safer to work with.
We are moving towards a coding standard that forbids Qt types anywhere where the Qt APIs do not require it.
Another huge pain point is the useless conversion from utf-8 to utf-16 for Qt. All our data is in utf-8 encoding, yet Qt needs utf-16 to display it in its UI.
I would love to get rid of that, as this conversion overhead is observable in the profiles and in critical places of the application.
We started to look into Copperspice over all the problems we have with Qt. They are way ahead in C++11 and later friendliness and they have native utf-8 support, too.
I also think, a new should be avoided, but not like this. This is a misuse of make_unique and unique_ptr. Why not create a template function
template addWidget(QLayout & l) {
l.addWidget(new T());
}
?
Then the code will look this.
addWidget(layout);
you could also add a static_assert, so that T must have a base QWidget using std::is_base_of
Missin paren? :D
You must’ve missed a bracket there.
fixed
Interesting. Did you had already a look at the actual affects of this pattern?
Without any optimizations (i.e. debug mode) this generates – as expected – a lot of additional instructions:
https://godbolt.org/g/nivVj9
With some optimizations turned on (already with -O1), GCC and Clang optimize that down to basically using
newdirectly.But, (!) MSVC creates does not optimize that away. Even not with -O2 (–> https://godbolt.org/g/JWR8Pu)!
Just worth noting. Using new features is not always the best way to go.
I can’t tell the difference. Is it ironic?
Irony, right?
This is just pointless syntactic sugar that makes the code less readable, not more, and that may or may not hurt efficiency depending on the compiler.
PS: In addition, a QWidget that is not a top-level window has a natural parent that is also the QObject parent and thus owns the object. Hence, it is outright dangerous to use smart pointers of any kind (other than those Qt ones that are explicitly designed for QObject) on them because of the potential for double-free bugs (though your particular code snippet is safe because the smart pointer is really just abused to perform a trivial new).
From an educational point of view, this post is utterly worthless. Why is this better?
It is pretty depressing that we have not yet developed an idea on how to make Qt and modern C++ work together:-(
I am now less and less able to use Qt since it blocks so much of modern C++.
Where do you see any problem?
Where does Qt __block__ the use of modern C++?
Just limiting myself to GSL’s recommended approach to memory management to stay in scope of Sune’s post:
* Qt’s parent-child hierarchy is fundamentally incompatible with the GSL’s proposed model of ownership.
* Qt data types do not support move-only types.
* Qt’s multithreading is based on Qt types (e.g. QFuture), so that those do not support move-only types either.
I am moving more and more code away from Qt-types to corresponding std-types with move semantics. They are so much safer to work with.
We are moving towards a coding standard that forbids Qt types anywhere where the Qt APIs do not require it.
Another huge pain point is the useless conversion from utf-8 to utf-16 for Qt. All our data is in utf-8 encoding, yet Qt needs utf-16 to display it in its UI.
I would love to get rid of that, as this conversion overhead is observable in the profiles and in critical places of the application.
We started to look into Copperspice over all the problems we have with Qt. They are way ahead in C++11 and later friendliness and they have native utf-8 support, too.
Nothing is compatible with GSL. It requires things not supported by even the latest C++ standards. Just ignore most of it.
I also think, a new should be avoided, but not like this. This is a misuse of make_unique and unique_ptr. Why not create a template function
template addWidget(QLayout & l) {
l.addWidget(new T());
}
?
Then the code will look this.
addWidget(layout);
you could also add a static_assert, so that T must have a base QWidget using std::is_base_of
Somehow less and greater is swallowed .
Then the code will look this.
addWidget\(layout);
Ok I give up.