[Development] Don't use Private *d when your class is immutable

[Thiago Macieira]

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, 
simple integers.

(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