[Development] QHash iteration vs std::unordered_map

[Marc Mutz]

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.mutz at 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