> 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 <annu...@yandex.ru> wrote: > > > 01.11.2017, 15:30, "Philippe" <philw...@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 > > ???? ?????????? <abba...@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@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
