Il 10/07/2015 11:54, Smith Martin ha scritto:
Then I don't see why it is so inherently inefficient. The QList entry is allocated on 
the heap anyway. Doesn't QList<C> just allocate a bigger entry? And if I don't 
have the C object stored anywhere else, it has to be somewhere, so why not keep it in 
the QList entry?

Because for a "wrong" type C (*) QList will allocate an array of pointers to C (not an array of Cs!), then proceed to allocate on the heap every single C object you put in it (by new'ing them); the array will then store the pointer to the allocated object.

In other words:

struct C {};
QList<C> list;
for (auto i = 0; i < 100; ++i)
        list << C{};

Calls operator new at least 101 times.

(*) not movable, or bigger than a void*. And user-defined types are not movable by default (they're complex). And if we forget Q_DECLARE_TYPEINFO on public types, we can't add it back because it's binary incompatible.

Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

Attachment: smime.p7s
Description: Firma crittografica S/MIME

_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to