Do you mean that if I declare this: typedef QList<ParsedParameter> ParsedParameterList;
where ParsedParameter is: struct ParsedParameter { bool qPrivateSignal_; QString dataType_; QString name_; QString defaultValue_; ParsedParameter() : qPrivateSignal_(false) { } }; ...it will create each list entry as a QList<ParsedParameter*> even though I told it not to do that? martin ________________________________________ From: giuseppe.dang...@kdab.com <giuseppe.dang...@kdab.com> on behalf of Giuseppe D'Angelo <giuseppe.dang...@kdab.com> Sent: Friday, July 10, 2015 12:05 PM To: Smith Martin; development@qt-project.org Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO 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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development