[Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
Smith Martin
Martin.Smith at theqtcompany.com
Fri Jul 10 12:18:04 CEST 2015
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.dangelo at kdab.com <giuseppe.dangelo at kdab.com> on behalf of Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>
Sent: Friday, July 10, 2015 12:05 PM
To: Smith Martin; development at 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.dangelo at kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts
More information about the Development
mailing list