> 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 <annu...@yandex.ru> wrote: > > > 01.11.2017, 18:21, "Thiago Macieira" <thiago.macie...@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@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development