Beyond 2.8 - some design thoughts

Christian Stimming christian at cstimming.de
Mon Dec 25 11:34:22 EST 2017


Hi Geert,

just two bits of thoughts from my side:

Am Sonntag, 24. Dezember 2017, 17:34:51 schrieb Geert Janssens:
> 1. Use of namespaces.
> ... nested namespaces ...

Yes, absolutely. I have quite some experience with C++ libraries and 
applications and I made very positive experience with this scheme. In our case 
this means we put all of our code in a "gnc::" namespace (at least). 

For me, the nicest way to write this was indeed to wrap the content of every 
file by "namespace gnc {" and "}" (except for the #include directives and 
such). There are some examples - but very few - where some other code requires 
us to put code from us in other namespaces, such as some io modifiers, or 
operators for std classes, but this is then clearly visible. 

Nevertheless "using namespace gnc" should rather not be used, as it makes the 
point of namespaces quite moot, as John already said.

Also, if there is some sort of "modules" that are used in some places but not 
everywhere, it is also useful to add another level of sub-namespace. Such as 
"gnc::import::", but maybe not quite the "engine", as it is used throughout 
everywhere of our code anyway.

If there are any nested namespaces, I would strongly recommend to match the 
namespace structure also in the directory names, at least the topmost ones. In 
our case this implies to match this also in the gnc-modules structure.

Apart from this, and for the project of our size, we might very well not need 
more than two levels of namespaces.

As for the namespace aliases such as "namespace gia = gnc::import::aqbanking", 
those must not appear in header files, but may appear in cpp files. However, I 
didn't like those in general, as it makes readability for other people much 
harder. In terms of mutual readability of code, I would rather stick to the 
plain namespace names and that's it.

> 2. Versioning.
> Here's my proposal:
> After the 2.8 lifecycle let's drop one number and stick with major.minor[-
> build] instead.
> Major releases would increment the first number. Bugfix releases the second.

+1 from me.

Regards,

Christian



More information about the gnucash-devel mailing list