I guess it depends on your architecture.

You can do it without namespaces, the old-school way, with prefixing everything. But if one day you decide to move to namespaces, then whether you'll keep the names with the prefixes and thus have some kind of redundancy, plus obliging the client to type more characters for no real uses (ie like Qt), or whether you'll have to remove the prefixes but then the clients will loose their habits (where is that pref1prefix2Class ?)

Or you can do it with namespaces. You can do it the C++ standard way, with only a single prefix (or another nested one for their experimental things). Or you can do it with several namespaces. But then you'll certainly want a main namespace to keep things logically ordered (otherwise the client will wonder if two classes of different namespaces belong to the same project/API or not). And then an issue for the client will be to wonder from which namespace a tool belong to...

I tend to agree with most in terms that 'it depends'.  Take your path example, oddly enough that is exactly a case I run into very often.  IO::Path:* can be appropriate given that you might also have AI::Path::* or DAG::Path::*.  Yes, I could rely on prefixing such as "IOPath", "AIPath" or "DAGPath" and avoiding the namespace but to me the purpose of the namespace here is to allow each API to use the most appropriate and obvious names without stomping on each other.    Once out of headers and in the CPP's where you use such things, simply typing in 'using namespace IO/AI/DAG' generally takes care of the extra typing involved.  The rare exceptions where you need combinations, serialization comes to mind, those are the only places you usually need to continue typing in the prefixes.

As to the depth of the namespaces.  I tend to believe 2-3 deep is appropriate with the only exceptions usually being things like an internal namespace that pushes into the 4+ range.  2-3 may seem a bit much but it all comes out of usability needs.  Probably the most common header name in nearly any library you get: '#include "Math.h[pp]"'.  This is a common problem if you are using 3rd party libraries: who's math file are you including with that?  So, in order to make sure I don't have that problem, there is *always* a prefix directory in my libraries: '#include "LIB/Math.hpp"' which guarantee's I get *my* math header file.  Out of this flows the rule I use that including a file should be as close to namespace of the object it provides as possible.  I.e. '#include "LIB/IO/Path.hpp"' gives me LIB::IO::Path ready for use.

While my rules don't work for everyone and are a bit excessive for normal everyday work, there is one rule I suggest anyone follow: "Be Consistent".  If you adopt a set of rules and styles, apply it everywhere with as few exceptions as possible.  Consistency trumps individual decisions folks may dislike pretty much every time.

Namespaces are part of the interface.  Used well they help tremendously.  Used poorly they are nothing more than extra typing.

Designing efficient interfaces, including bundling into namespaces, is a difficult task generally requiring refinement over time.

It is also highly dependent on context.  Namespaces are a powerful organizational feature, and the types of organization depend on the nature of the code.

At first glance your example of my::system::io::path::ExtractFileName() seems an example of the poorly-executed variety, although it if the system happens to be rather complex with many systems and subsystems regarding the system, and many subsystems with in IO, and many operations and systems within path management, then it may be executed well.

On 17.11.2017 at 12:48 PM, Finalspace said:

I am talking about nested namespaces in C++. For example:

Note that in C++17, there is a feature actually called "nested namespaces", which can make such code way easier to read/write:

// might be worth a discussion if this is actually better when there are multiple nested namespaces in one file
namespace my::paths {
   const char *ExtractFileName(const char *path);
namespace my::strings {
   size_t GetAnsiStringLength(const char *str);
};

// could instead look like this:
namespace my {
  namespace system::io::path {
     const char *ExtractFileName(const char *path);
  };
  namespace strings {
    size_t GetAnsiLength(const char *str);
  };
};

On 17.11.2017 at 8:18 AM, Finalspace said:

I personally think that C++ namespaces are there to prevent conflicts between other api´s and for nothing else. But for medium to large size api´s one nested level is fine.

They are also a better alternative for "smurf naming convention". I worked at a project where every class was prefixed with proj_module_nested_ ... you could argue that this is already an iditiotic naming scheme, but in multi-million line projects, its important to be able to quickly see to which module a certain method/class belongs.

On 17.11.2017 at 8:18 AM, Finalspace said:

Too long: my::IO::Path::Combine(my::IO::Path::GetHome(), my::IO::Path::ExtractFileName(...));

Fine: my::Paths::CombinePath(my::Paths::GetHomePath(), my::Paths::ExtractFileName(...));

Better (using namespace my): Paths::CombinePath(Paths::GetHomePath(), Paths::ExtractFileName(...));

I'd actually prefer IO::Paths::GetHome() etc... I tend to group my global methods in a static class instead of a namespace, so I'm just used to seeing multiple levels of nested :: without a problem. I also tend to not using namespace, but instead put all implementations in their respective namespace as well:

namespace my::strings
{
	const char* something(const char* path)
	{
		IO::Paths::GetHomePath(); // my is implicitely available, as well as my::strings. 
    }
}

But thats just my sense, in case you want to get some different ideas.