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 | [email protected] | 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 [email protected] https://lists.qt-project.org/listinfo/development
