CODEWITHSUNDEEP
c++namespacesheader-fileslibraries
Krazy Glew
Krazy Glew

Reputation: 7534

Best Known Method for naming namespaces in C++ // what to do when names collide?

OK, so I know that I should embed my code in namespaces to handle name collisions. E.g.

My-Header-Only-Library.hpp

    namespace AG {
    namespace My_Header_Only_Library {

    class Foo {
        ...
    };

    }
    }

So I have AG::My_Header_Only_Library::Foo.

Yes, I often use two levels - the first, variously AG, AFG, libAG, etc. - for "my" stuff (I have maintained some of these libraries for decades, e.g. Valid<T>).

And I often have sub-namespaces for various modules.

PROBLEM #1: namespace names sometimes collide.

Yes: I have found collisions for all of the namespace names AG, AFG, libAG. Yes, I have run into companies that have the same initials as me.

(For a while I used GLEW, thinking that this is a fairly unique last name. Back then I was the only Glew on the internet, and only the 48th person with the initials AG on ARPAnet. (AG48). But since then, OpenGL Extensions Wrangler has pretty much taken that away from me.)

I suppose that "namespace AG_some_random_stuff_675567" is less likely to collide. Is that what people do? Use some long namespace name, and then a 

using AG_lib = AG_some_random_stuff_675567

Or do you ever try to play tricks like #defining the name of the namespace to something else.

E.g.

#define AG something_more_unique

PROBLEM #2: I sometimes give, loan, allow companies to use my libraries. Bit I ask that they give changes back, i.e. that they do not fork.

Their coding conventions may not be the same.

I don't want them to change the namespace names, because that makes pulling their changes back harder.

Q: What to do? Have them do

using Their_Name = AG_some_random_stuff_675567

Upvotes: 3

Views: 211

Answers (3)

Ben Voigt
Ben Voigt

Reputation: 283624

Don't use initials, use a namespace that's already allocated. For example, the Java practice of reversing your fully-qualified-domain-name works quite well. With my code I can safely use

namespace com {
    namespace benvoigt {
    }
}

and know it will not conflict with an external entity, since it's impossible for anyone else to have ownership of the domain benvoigt.com.

Upvotes: 0

Potatoswatter
Potatoswatter

Reputation: 137770

You're on damage control mode. The company who received your library in a state that collided with their internal names will need to revise their client code to disambiguate the collided libraries.

AG_some_random_stuff_675567 is clearly overkill and AG is clearly (maybe just in retrospect) too likely to collide. Pick something reasonably unique, so future clients can use it without a using alias. For example all_good. (Although, if requiring clients to add their own using alias won't cause marketing or support issues, a namespace with random_stuff would be completely safe.)

Then, you can add using namespace AG = all_good; inside your own code, and direct older clients to do the same as a means of backward compatibility.

Perhaps use preprocessor flags to help migrate clients by selecting who gets using directives in the global namespace, but no way you should use preprocessor macros to rename namespaces! And with a name like AG that's already proven to collide.

Upvotes: 0

Jerry Coffin
Jerry Coffin

Reputation: 490048

I usually start with something about what the namespace contains, my full name, and the creation date -- in theory this isn't 100% immune to collisions either, but it's pretty close1. If you really want something a lot closer to immune, you can generate a GUID and use that instead.

Then, of course yes, there's a much shorter alias for most normal use. Unfortunately, you can't always use an alias in place of the full namespace name, but such is life.

  1. At least for me it's pretty close -- a more common name would provide a lot less protection though.

Upvotes: 1

Related Questions