C++ – Using a domain name as C++ namespace

cnamespace

What would be a good system to use domain names as C++ namespaces in order to avoid name clashes between developers? The idea appears to be popular in the Java world.

We cannot use namespace example.com { ... }, since dots are not allowed.

A practical, but as I find not very elegant, workaround would be to replace each dot by a character that usually is not part of any domain, such as an underscore (I read somewhere that domains may theoretically also contain underscored, but I do not see this is widely used). That would make it: namespace example_com { ... }.

We could use nested namespaces, thereby effectively replacing the dot by the namespace separator ::, so that would be: namespace example { namespace com { ... }} and we would refer to it by example::com. The drawback of this is that it suggests that com is a part of example. But I would like to treat the domain as one unit. Otherwise, reverse domain notation would be fine: com::example. But my impression is that the relaxed way that domains can be registered has made this hierarchy meaningless for the most part. What would namespace com (the outer namespace) stand for? Answer: for code written by anyone with a .com domain, and that can be almost anyone. What would namespaces net or info stand for? It does not look useful to me.

Anyone got a better idea or can rebut my critique regarding the meaning of top level domains?

Update: here is some background to my question. I am supervising a small team of developers. In some part, they work on libraries with competing functionality (this is intended, since we are experimenting with different ways to do things). So we had name clashes already (imagine libraries called libmatrix or even libmisc). The easy solution would be one namespace per developer, and I keep track of which names are used. However, I would prefer something more built-to-last. Moreover, it is conceivable that we cooperate with other groups of a similar structure, and then we need something global.

Best Answer

The easy solution would be one namespace per developer, and I keep track of which names are used. However, I would prefer something more built-to-last.

In what way is your suggested solution not "built-to-last"?

The thing about namespaces is that it is very easy to move things from one namespace to another. Boost does this all the time. The primary definition of something can live in one namespace, while the name exposed to the user comes from a different one.

If you're just experimenting around to find ways to implement things, then each developer should have their own namespace playground. When you want to evaluate a particular experiment, you use the specific namespace they used. When it comes time to integrate one of the variations into the main project, you can use using declarations to bring those symbols into the project namespace.

Indeed, C++11's inline namespace syntax is particularly useful for this, as it can cause one namespace to effectively live within a containing one. This way, the inner namespace still has all of the ADL rules and so forth as if it lived in the outer one.

All of your developers would develop under the root namespace for your project, but they would each have their own sub-namespaces. When it comes time to select which math library (for example) you want to actually use, you simply declare it inline in your primary namespace. This is also good for versioning; you pick the current version to be inlined, while earlier versions can still be made available without the inline keyword.

That's "built-to-last".

Moreover, it is conceivable that we cooperate with other groups of a similar structure, and then we need something global.

And how would a domain name be in any way different from an arbitrary name you pick? Either someone picked a name unilaterally as your root namespace or you all agreed to work under a specific root namespace. Either way, someone had to pick some sequence of characters.

What does it matter if that sequence of characters is a domain name or not? I don't see how inkscape, for example, would be more likely to be selected by a random person by accident than inskcape.org.

Using a domain name as the agreed-upon namespace name will not make it easier to collaborate. So what purpose does it serve to use a domain name as a namespace name?

1) It is very unlikely that someone will use a domain that is not registered to them as namespace.

For a professional project, maybe. For an indie project where the owner is relying on the facilities of GitHub for their stuff? No. Why use a huge domain name like projname.github.io.com for a namespace? The only useful characters in that name are projname; everything else is pointless noise.

Even for a professional project, is cairo really so likely to conflict with someone that cairographics.org is a better alternative? That's 5 useful characters and 12 characters of noise. And sure, IDEs make it easier to write them thanks to tab completion, but that doesn't make it any easier to read.

Names of such length would encourage someone to do namespace projname = projname.github.io.com;, if not flat out using namespace projname.github.io;. So what do you gain?

That's the difference between C++ and Java. If you do import projname.github.io.com.*, that stays in your single .java file. C++ has headers, which don't belong to a single translation unit. And lots of code gets written in headers.

In C++, you are far more likely to have to use a fully-qualified name for a type than in Java.

2) If it happens that someone uses a domain actually registered to us, then it is pretty obvious that they will have to move, not us.

Why do they "have to move" at all? Because it's registered to you? If they got their first, and their project is more popular than yours, who exactly would expect them to change and break lots of people's code?

The point of namespaces is not to guarantee universal distinction between projects. Otherwise, we'd use UUIDs or SHA hashes or something for root namespaces.

Related Solutions

C# Naming Conventions – Same Class and Namespace Name Issues

You're right that you shouldn't name the namespace the same as a type it contains. I think there are several approaches you can use:

Pluralize: Model.DataSources.DataSource

This works especially well if the primary purpose of the namespace is to contain types that inherit from the same base type or implement the same interface.
Shorten: Model.QueryStorage

If a namespace contains only a small number of types, maybe you don't need that namespace at all.
Make enterprisey: Model.ProjectSystem.Project

This can work especially for features that are important part of your product, so they deserve their own name.

Two of them are interfaces so I could consider prefixing them with I but I really don't like this convention.

You really should, if your code is used by others (i.e. it's a library) or if you don't want to confuse newcomers to your code.

C++ – Should class names reflect namespace name

The problem is that your example is vague and your names are anemic. If we make them good robust names doesn't the choice become obvious?

namespace ImageFilter
{
     class BasicFace ...
     class HappyFace ...
     class SadFace ...
}

verses

namespace ImageFilter
{
     class BasicFaceImageFilter ...
     class HappyFaceImageFilter ...
     class SadFaceImageFilter ...
}

This smurf naming anti pattern has tempted me in the past as well. I've come to feel it's the result of trying to keep anemic names on life support. Rethink all the names and try again. It's a pain to do but it makes for better code.

Best Answer

Related Solutions

C# Naming Conventions – Same Class and Namespace Name Issues

C++ – Should class names reflect namespace name

Related Topic