[Development] QtCS 2017 QtCore sessions

[Philippe]

> Using unsigned for size types is crucial in preventing signed overflow in
> pathological cases.

During this interactive conference of "C++ gurus" (Herb Sutter, Bjarne
Stroustrup, Andrei Alexandrescu, Stephan T. Lavavej, Chandler Carruth,
Sean Parent, Scott Meyers, Michael Wong), it is clearly stated that it's
generally a mistake to use unsigned...
Check these extracts!
https://www.youtube.com/watch?v=Puio5dly9N8#t=12m12s
https://www.youtube.com/watch?v=Puio5dly9N8#t=42m40s
https://www.youtube.com/watch?v=Puio5dly9N8#t=1h2m50s

Philippe

On Wed, 01 Nov 2017 18:25:01 +0300
Konstantin Tokarev <annulen at yandex.ru> wrote:

> 
> 
> 01.11.2017, 18:21, "Thiago Macieira" <thiago.macieira at intel.com>:
> > On quarta-feira, 1 de novembro de 2017 05:23:04 PDT ???? ?????????? wrote:
> >>  Sorry for digging the thread, but how is
> >>  * use qssize_t
> >>  and
> >>  ** Wrapping std::{unordered_}map may be acceptable
> >>   combines?
> >>  std::*map uses size_t in it's API (size, max_size, count, reserve,
> >>  begin(size_type), end(size_type))
> >
> > Our wrapper API can still use qssize_t.
> >
> > "Won't that limit the actual maximum size?"
> >
> > No, not really, since it's already limited to half the full VM space. No
> > object can be larger than that. Using unsigned is unnecessary.
> 
> Using unsigned for size types is crucial in preventing signed overflow in
> pathological cases.
> 
> >
> >>  And offtop - what about allocators? They would be accesibble for wrappers,
> >>  but not accesible for QVector/QString?
> >
> > They wouldn't be accessible for wrappers either.
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >   Software Architect - Intel Open Source Technology Center
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> -- 
> Regards,
> Konstantin
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development