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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
