[Development] What's the status of a moved-from object?

[Giuseppe D'Angelo]

Hi,

Il 24/05/19 15:24, Simon Hausmann ha scritto:
> Hi,
> 
> 
> I don't think our users should have to use a build of Qt that has its 
> internal Q_ASSERTs enabled. IMHO Q_ASSERT should be used by developers 
> in Qt to express invariants that, if violated, represent a bug in Qt 
> that needs fixing. I don't think we should use Q_ASSERT to communicate 
> anything to our users - it's a poor interface because it either isn't 
> reliable (-release build not enabling it) or hard to understand 
> (debugger usage).
> 
> 

I disagree. Although we don't have a distinction between "internal" 
asserts (due to bugs in Qt) and "external" asserts (users misusing the 
APIs), as of now, Q_ASSERT is *also* used to enforce external asserts. 
Following your reasoning, all the assertions Qt has when e.g. checking 
for out of bounds access in a container should be removed or replaced by 
Qt-internal asserts, never firing in user code.

And, there is already everything in place to keep assertions enabled in 
release builds. The bottom problem here IMHO is the challenge at 
educating users (and/or providing builds in the SDK) that they have all 
these knobs they can tune: debug vs. release, asserts enabled vs. 
disabled, with or without debug prints, etc.

My 2c,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190524/ef6f62ad/attachment.bin>