[Development] QtCS 2017 QtCore sessions

[Philippe]

> Using virtual functions for allocation/deallocation doesn't seem like a bright idea

If you speak about performances, then you are wrong. The impact is
neglictable compared to the rest of the allocations. This has been
proved by the guys that pushed that C++17 feature, with extensive
benchmarks.
You can find a very complete study here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0089r1.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0213r0.pdf

And if you like some videos on the topic, here the latest one from John
Lakos:
https://www.youtube.com/watch?v=nZNd5FjSquk
https://www.youtube.com/watch?v=CFzuFNSpycI&t=8s

Personnaly (and with a long experience with custom memory allocation), I
am convinced about this new C+++17 approach.

Philippe

On Wed, 01 Nov 2017 15:32:23 +0300
Konstantin Tokarev <annulen at yandex.ru> wrote:

> 
> 
> 01.11.2017, 15:30, "Philippe" <philwave at gmail.com>:
> > And offtop - what about allocators? They would be accesibble for wrappers, but not accesible for QVector/QString?
> >
> > Something sure, a Qt6 feature such as std::pmr::memory_resource (cf. https://www.youtube.com/watch?v=v3dz-AKOVL8) would be more than welcome for Qt containers and strings.
> 
> Using virtual functions for allocation/deallocation doesn't seem like a bright idea
> 
> >
> > Philippe
> >
> > On Wed, 1 Nov 2017 15:23:04 +0300
> > ???? ?????????? <abbapoh at gmail.com> 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))
> >>
> >> And offtop - what about allocators? They would be accesibble for wrappers, but not accesible for QVector/QString?
> >
> > ,
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> -- 
> Regards,
> Konstantin