Re: [Development] Qt XML and Qt Xml Patterns
Hi! > For Qt XML Patterns, the situation is IMO a bit different. The module has > some architectural problems Do you think this is true for all parts of the component? I am asking because I can not imagine using XML without a schema validator, which is part of Qt Xml Pattern. Do you consider it broken? I consider that class fundamental. Using XML without using a schema validator is (or at least should be) a no-go. So even if the Qt XML component should be continued in some way, Qt should also not lack a schema validator. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What's the status of a moved-from object?
On 2019-05-25 17:24, Konstantin Ritt wrote: сб, 25 мая 2019 г., 12:30 Mutz, Marc via Development Repeat after me: default ctors do _not_ establish a valid value. Perhaps you mean "trivial type's default ctors do _not_ establish a valid value"? 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. Thanks, Marc ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Gerrit is back
> There are more tweaks that would be nice to apply to the UI to make it > better. Does the new version make this any easier? What's your advice for > people who'd like to contribute UI tweaks? What's the best way to > proceed? (in the sense of empowering potential contributors instead of > asking you to do all the changes) This is a very very positive way of saying that the new UI is: - less structured - less intuitive The update contains indeed nice new features, but as an occasional contributor I feel less productive because I need to learn where to click every other day. The old gerrit was certainly ugly, but it felt much more tidy. I would be very happy if someone with UI experience could clean up the stylesheet. :) Thanks Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What's the status of a moved-from object?
сб, 25 мая 2019 г., 12:30 Mutz, Marc via Development <
development@qt-project.org>:
> Further to the question about default ctors for such "obvious" stuff as
>
> On 2019-05-21 10:27, Mutz, Marc via Development wrote:
> > class QRect {
> >int x, y, w, h;
> > public:
> >QRect() = default;
> > };
> > QRect r; // partially-formed
> > r.x(); // compilers _already_ warn about this
> > QRect r = {}; // zero-initialized
>
> I've been working with Qt for two decades now. Guess what I just wrote
> and had to debug?
>
> QSize zero;
>
> Anyone spot the bug? Hint: the following /is/ correct:
>
> QPoint origin;
>
> Now, anyone here who wants to defend that as good API design?
>
> Anyone?
>
> Repeat after me: default ctors do _not_ establish a valid value.
>
Perhaps you mean "trivial type's default ctors do _not_ establish a valid
value"?
Konstantin
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] What's the status of a moved-from object?
Further to the question about default ctors for such "obvious" stuff as
On 2019-05-21 10:27, Mutz, Marc via Development wrote:
class QRect {
int x, y, w, h;
public:
QRect() = default;
};
QRect r; // partially-formed
r.x(); // compilers _already_ warn about this
QRect r = {}; // zero-initialized
I've been working with Qt for two decades now. Guess what I just wrote
and had to debug?
QSize zero;
Anyone spot the bug? Hint: the following /is/ correct:
QPoint origin;
Now, anyone here who wants to defend that as good API design?
Anyone?
Repeat after me: default ctors do _not_ establish a valid value.
Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] What's the status of a moved-from object?
Hi,
Il 19/05/19 14:24, Giuseppe D'Angelo via Development ha scritto:
Hence, I'll ask here: what should the status of a moved-from object be?
I'm not really interested in_how_ to achieve such status (although of
course it's very important, and should influence the decision); I'm
interested in what's our contract with our users.
Trying to summarize the discussion so far. It seems to me that there's
some agreement on these points:
1) We want move constructors for pimpled valued classes.
2) They must be noexcept, incl. not allocating memory.
3) At least for Qt 6's lifetime, the documented state of a moved-from
object is "valid, but unspecified", à la stdlib, and NOT
partially-formed. Any function without preconditions can be called on a
moved-from instance; the results are unspecified. ("Unspecified" used in
Standardese jargon here).
4) We will deliberately break source compatibility by adding move
constructors to the classes currently lacking them (and thus copying
instead of moving; leaving the source object in a well-defined state).
Hopefully, in the next years, static and runtime analyzers will be able
to catch more and more usages of use-after-move. If we're really
paranoid about this we could hide the move constructors behind a macro
to avoid the SC break.
===
With these constraints, then we're left with "how do we do it"?
A) Allow for the d pointer to be nullptr; that's what gets set in the
source object. To keep the object valid, this means checking the d
pointer for nullptr in any function without preconditions (... read: in
any member function, better safe than sorry). The cost of these extra
checks is to be determined.
B) Introduce a "shared_null" for every pimpled class, under the form of
a Q_GLOBAL_STATIC or similar. The move constructor resets the source
object's d pointer to that shared_null.
As a by-product, both A) and B) can be used to make the default
constructor not allocate and noexcept.
Am I forgetting anything?
Thank you,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
