[Development] Don't use Private *d when your class is immutable
thiago.macieira at intel.com
Sat Mar 4 01:23:09 CET 2017
Em sexta-feira, 3 de março de 2017, às 11:02:18 PST, Lars Knoll escreveu:
> > On 3 Mar 2017, at 16:54, Marc Mutz <marc.mutz at kdab.com> wrote:
> > On Friday 03 March 2017 16:11:54 Thiago Macieira wrote:
> >> But we should not add more global tables.
> > Apart from "Thiago says so", are there any reasons for this?
> How about: "Lars agrees with Thiago"? ;-)
> More seriously: constant global tables are perfectly fine.
Right, so let me clarify: if your table is *constant*, then it's fine.
Preferably if your table can be made static read-only, compile-time
constructed, like the one I've done for the metatypes in
I4139d5f93dcb4b429ae9fffd14a33982891e2ac1. Meta type IDs are, after all,
(though for Qt 6 we should consider making them opaque pointers)
> But I fully agree with Thiago that I want to avoid adding more global static
> data (using Q_GLOBAL_STATIC). Reasons are that those are initialised at
> startup with an undefined initialisation order (and usually worse:
> destruction on application shutdown). They thus add overhead for each
> application (in terms of memory usage and startup time), and can cause
> headaches on shutdown if there are cross dependencies between global
> statics (we've had those in the past).
If you have some data that cannot be constructed at compile time, but happens
only once, maybe Q_GLOBAL_STATIC may make sense. The arguments that Lars gave
above need to be taken into account, so we can't make a blanket statement like
you asked to create a global tables. We should make an extra effort to make
read-only memory-sharable tables, even if it means creating code generators to
do the job. (The Qt Project should be the last project to object code
generators *cough* moc *cough* uic *cough* rcc)
But I am particularly concerned if the global table can be changed at runtime.
Then we need to introduce mutexes and read-write locks in order to achieve the
solution. It's trading off one problem (implicit sharing) for another.
The example of a bad design here is QSqlDatabase: there's a global table of
databases. QDBusConnection (because it was designed on QSqlDatabase) suffers
from a similar problem. Worse: QDBusConnection also does ref-counting. Please
don't create more of those.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development