Modern C++ and Qt

– ’cause raw new’s are bad.

16 comments on “Modern C++ and Qt
  1. Bugfinger says:

    Missin paren? :D

  2. Boud says:

    You must’ve missed a bracket there.

  3. Toka says:

    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:

    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 (–>!

    Just worth noting. Using new features is not always the best way to go.

  4. alberto says:

    I can’t tell the difference. Is it ironic?

  5. Kcris says:

    Irony, right?

  6. Kevin Kofler says:

    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.

    • Kevin Kofler says:

      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).

  7. Your mom says:

    From an educational point of view, this post is utterly worthless. Why is this better?

  8. Karl says:

    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++.

    • Gunnar Roth says:

      Where do you see any problem?
      Where does Qt __block__ the use of modern C++?

      • Karl says:

        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.

        • Allan Jensen says:

          Nothing is compatible with GSL. It requires things not supported by even the latest C++ standards. Just ignore most of it.

  9. Gunnar Roth says:

    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.


    you could also add a static_assert, so that T must have a base QWidget using std::is_base_of