01.11.2017, 18:50, "Philippe" <philw...@gmail.com>:
>> 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
I've listened and I think I buy this. Their main argument is about mixing
unsigned and
signed, and Qt is a framework for a wide audience, and many people seem to
pass negative numbers to APIs accepting unsigned without second thought
(it's just a compiler warning, who looks at them after all), so using unsigned
may
increase number of bugs on user side.
>
> 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
--
Regards,
Konstantin
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
