сб, 25 мая 2019 г., 12:30 Mutz, Marc via Development >>>> Repeat after me: default ctors do _not_ establish a valid value.
As an aged C programmer I can respect that ;^> On 2019-05-25 17:24, Konstantin Ritt wrote: >>> Perhaps you mean "trivial type's default ctors do _not_ establish a >>> valid value"? сб, 25 мая 2019 г., 20:42 Mutz, Marc via Development <[email protected]<mailto:[email protected]>>: >> No, I actually meant default ctor. What should the default value be? >> _Obviously_ zero-initialisation. But oh, no, QSize is different. So >> maybe it's not _quite_ so obvious what the default value is. Why is >> pen's default value a black solid line instead of NoPen? Why is >> QBrush's default ctor not solid black, but NoBrush? See? It's just >> nonsense to try to pick a default value, so this is to say: Don't >> try. >> >> There's exactly one exception: containers. _Clearly_ no-one would >> _ever_ expect a container to start out anything but empty. Indeed. Konstantin Ritt (26 May 2019 10:51) replied: > Sure we should force a no-op default ctor where possible, and provide > some helper code that returns a valid default/specialized value of > that type where {0} isn't enough or non-intuitive > (i.e. QQuaternion::identity(), QRect::empty(), QSize::invalid()). (I can't help but wonder whether QRect::empty() should take a point at which to place its empty rectangle. An animated rectangle that shrinks and expands repeatedly [0] shouldn't forget its location at the moment when it is transiently empty, so empty rectangles at distinct locations are distinct. But I'm unfamiliar with QRect, so maybe not.) [0] example (in SVG), remembering position and orientation while empty: http://www.chaos.org.uk/~eddy/img/geom/transpyth.svg > There could [be] more exceptions when we're talking about non-trivial > types, at least some of them could be resolved by providing > convenience/helper initializers. Many types need an invalid value (this is the current default for QDate, QTime, QDateTime and QTimeZone). But not all. For arithmetic types, up to and including QQuaternion and matrices, you'll need a zero-value; many (including square matrices) shall also need a unit value. While zero is a natural default, being explicit is good; and standard integral/floating types don't default to it. Various others are (at present) constructed with default values. In the case of QLocale, that can be controlled by calling a static method, QLocale::setDefault(), and we'd need to add (as someone tried to do a little while ago) a QLocale::defaultLocale() or QLocale::getDefault() to get that (note that we can't use the name QLocale::default() as it's a reserved word) if we stopped making the default constructor produce it. Note that QLocale's default isn't the same thing as QLocale::system(), although it starts out so, until setDefault() is called. We're not particularly consistent about what default construction produces; sometimes undefined, sometimes defined but invalid, sometimes a zero, sometimes a "reasonable" default. Which, as Marc tripped over, is a source of confusion for authors of client code. Having static methods to return invalid, zero, unit, default values could be made a consistent pattern, with consistent naming, to reduce confusion. We can, of course, do that without changing what the default-constructed objects are, but changing that also to a consistent pattern - the same as the moved-from state - would make matters clearer (for any choice of what moved-from state to consistently use). But it'd be SiC. Eddy. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
