Namespaces, file names,...
jralls at ceridwen.us
Mon Sep 8 15:38:14 EDT 2014
On Sep 8, 2014, at 11:22 AM, Christian Stimming <christian at cstimming.de> wrote:
> Am Sonntag, 7. September 2014, 15:10:13 schrieb John Ralls:
>>> I strongly prefer namespaces in all-lowercase. I have somewhat a
>>> for "gnc" as namespace name, but we are an application anyway and not a
>>> library, so we're basically free to choose whatever we want as interface
>>> naming schemes.
>> Any particular reason for the all lowercase preference? Not that it matters,
>> gnucash and GnuCash are equally unique.
> I think one relationship wasn't mentioned so far: The filenames and the
> corresponding namespace and class names. I think both should be as identical
> as possible - similar to Qt, different from glib.
> Namespaces in lowercase gives also directory names in lowercase. Class names,
> well, should appear in the file names IMHO as unchanged as possible. I prefer
> both with the first letter in capital, but I know this causes occasionally
> some hassles on windows systems, as those colleagues notoriously forget to add
> their include directives with the correct case sensitivity. Other people argue
> that file names should be all lowercase in general. Both views exist.
I agree that filenames should reflect the class that they implement, when they do so, and I’ll add that in general a file should implement only one class. Capitalization is OK as long as one keeps in mind that the Mac file system is normally case-preserving but case-insensitive, so e.g. Account.h and account.h will map to the same file.
I don’t think we want to give each directory its own namespace. I’m not even sure that we want any namespaces inside ‘gnucash’.
>> I don't mind tagging member variables, and I find m_varName to be clearer
>> than just sticking an underscore at the end. One can go one step further
>> and tag static members with a c_ or an s_, while being aware that static
>> members, just like any other static or global variable, require extra
>> synchronization and so should be avoided as much as possible.
> Ok for the prefix. However, "static class members" are not at all evil.
> They're a normal part of the language and needed for modelling certain aspects
> of a program. What is evil are global variables. But static class variables
> are just fine - they are fixed into their scope and have access rules. They
> are simply needed occasionally. Nothing that necessarily has to be avoided.
Static member variables, a.k.a. class variables, are indeed a core feature of the language. When using them one just has to be aware that access must be synchronized; fortunately C++11 added some nice sync functions to the standard library that make that reasonably easy. However, synchronization is a bit expensive and so it’s better to avoid it if possible.
There are times when regular member variables need to be synchronized too — any time one has a shared_ptr or naked pointer running around all access to its members must be synchronized.
The same is true of file-scope statics, which aren’t globals, but their existence seldom reflects good C++ design. In general a file-scope static should be a member variable; in some cases a class variable.
More information about the gnucash-devel