Le mar. 21 mai 2019 à 10:32, Mutz, Marc via Development
<[email protected]> a écrit :
> It is, however, be an acceptable stop-gap measure, and here a compromise
> may emerge, for keeping old code working while preparing for a
> fully-implemented partially-formed state. This would mean we do assign
> meaning to a nullptr d consistent with the documented default value in
> Qt 5, but deprecate the use of the default ctor for establishing said
> value in the docs and warn about the use of a default-constructed object
> other than for destruction and assignment at runtime, even in release
> mode. In Qt 7, we then crash, as we do for some moved-from objects
> already.
Hi, I'm just a bystander, but I'm curious about this, and I wonder if
I misunderstood.
Are you saying that in modern C++, the recommendation is that the
default constructor of classes should leave the object in an
uninitialized state, where most member functions called will crash or
lead to undefined behavior? Do you have any links on the subject?
Are you suggesting that in Qt 7, we will have the following :
QRect r;
qDebug() << r.width(); // random value
QVector<int> v;
qDebug() << v.size(); // crash
QString s;
qDebug() << s.indexOf("foo"); // crash
What about std::string and std::vector ?
--
Julien Cugnière
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
