On Tuesday 18 April 2017 10:52:47 Olivier Goffart wrote: > On Montag, 17. April 2017 18:48:26 CEST Marc Mutz wrote: > > On Monday 17 April 2017 18:08:20 Thiago Macieira wrote: > > > Em segunda-feira, 17 de abril de 2017, às 00:30:23 PDT, Marc Mutz > > escreveu: > > > > The problem with QT_STRICT_ITERATORS is _not_ that they are changing > > > > begin() and end(), > > > > > > Actually, it was. You can't use QT_STRICT_ITERATORS in one TU and not > > > in other, regardless of exporting or not. > > > > Why? > > ODR violation is an undefined behaviour. > (Technically, this is also the case across library boundaries)
If QT_STRICT_ITERATORS (as-is) is an ODR violation, and technically, it is, then so is #ifdef Q_COMPILER_... over member functions, or QT_NO_CAST_FROM_ASCII. However, we'd be screwed if any compiler started to exploit that particular UB. So, there's nothing out of the ordinary with QT_STRICT_ITERATORS itself. Maybe there was in the past, but not in its current state. In its current state, the problems with QT_STRICT_ITERATORS are _solely_ the two I mentioned, and they affect all member-function-ifdef'ery, be it about iterators, conversions, or c++ features, in the same way. Just try to compile QtCore with QT_NO_CAST_FROM_ASCII and watch the carnage that surely ensues. We can turn a blind eye on the issue, but this wholesale exporting of non- polymophic classes will bite us over and over again, until the naysayers will have learned, too. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development