On 2016-01-19 05:51, Marc Mutz wrote: > So... is realloc actually the optimisation everyone (incl. me) expected it to > be?
It really *ought* to be, at least in the right cases. Let's say I have a type that stores a buffer, which, for whatever reason, is not movable (i.e. no move-ctor or swap¹), but *is* relocatable. Resizing a vector of such types involves allocating the new block, doing a single block memcpy, and releasing the old block. Resizing if they were *not* relocatable involves a copy ctor for each, which involves allocating a new memory block, copying the data, and releasing the old block *per item*, plus the two memory operations If 2*N heap operations plus N block copies of "large" blocks are comparably expensive to a single block copy of N*sizeof(void*), I would be very surprised :-). (¹ Keep in mind also that the move/swap quite possibly must also be noexcept or it can't be used anyway.) Maybe we're looking at bad examples, or there are fewer such instances than expected where it is significantly better. (In particular, I suspect neither string nor QByteArray are "good examples". Try with a type that always allocates memory?) -- Matthew _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development