1

C++ namespaces prevent collisions, but what if the name of the namespace itself collides? Example:

#include <cstdlib>

namespace atoi {
    int foo() {return 42;}
}

Question: can I reliably avoid the collision by namespace Atoi? That is, does C++ protect my use of a mixed-case namespace name like Atoi? Or is a mixed-case namespace name like Atoi liable to be trampled by a future C++ standard, technical specification (TS), Boost library, compiler, toolchain, etc.?

Of course, I do not really intend namespace atoi or namespace Atoi for practical code. Those are merely for illustration (since atoi happens to be a name the C standard library uses). What I really intend is namespace my, preferably in lower case but if necessary in mixed case as namespace My. Your answer regarding atoi and Atoi could influence my choice between my and My. This is why I ask.

I notice that Stroustrup prefers mixed-case namespace names. I also notice that examples in sect. 10.3 of the C++17 standard (draft here) avoid lower-case namespace names.

See also this related question.

thb
  • 13,796
  • 3
  • 40
  • 68
  • 1
    Any symbols in c++ are case sensitive, and I don't think this will change in any future standard. – πάντα ῥεῖ Mar 09 '19 at 15:34
  • 1
    Watch this: https://www.youtube.com/watch?v=BWvSSsKCiAw. This video by Titus Winters states what the standards committee reserves the right to and what you should not depend upon in the standard library. – Hemil Mar 09 '19 at 15:40
  • @πάνταῥεῖ Thank you for clarifying the question. A future C standard library (or Boost library, etc.) might introduce `my` into C++'s global namespace. Might a future C standard library (or Boost library, etc.) however *instead* introduce the mixed-case `My` into C++'s global namespace? – thb Mar 09 '19 at 15:41
  • 2
    @Someprogrammerdude standard does not guarantee that `atoi` isn't in the global namespace in addition to `std`. – eerorika Mar 09 '19 at 15:42
  • The only way to reduce amount of collisions or at least to only allow them among entities of the same kind would be to use naming convention that forces different naming schemes for namespaces, types, methods, variables and macros. dealing with stuff like `foo::foo foo{};` is not fun – user7860670 Mar 09 '19 at 15:51
  • 4
    You can dodge the problem with a liberal seasoning of Unicode. `namespace äẗöï {` (Ducks. Runs.) – Eljay Mar 09 '19 at 16:09

2 Answers2

2

Watch this: Standard library compatibility guidelines .This video by Titus Winters states what the standards committee reserves the right to and what you should not depend upon in the standard library.

This must be the official document. I found it in the description of the video. This is the what we care about:

Rights the Standard Library Reserves for ItselfPrimarily, the standard reserves the right to:

●Add new names to namespace ​std

●Add new member functions to types in namespace ​std

●Add new overloads to existing functions

●Add new default arguments to functions and templates

●Change return-types of functions in compatible ways (void to anything, numerictypes in a widening fashion, etc).

●Make changes to existing interfaces in a fashion that will be backwardcompatible, if those interfaces are solely used to instantiate types and invokefunctions. Implementation details (the primary name of a type, theimplementation details for a function callable) may not be depended upon.

○For example, we may change implementation details for standard functiontemplates so that those become callable function objects. If user code onlyinvokes that callable, the behavior is unchanged.

Hemil
  • 916
  • 9
  • 27
1

can I reliably avoid the collision by namespace Atoi?

Fairly reliably. There is no identifier by that name in the C standard library.

Or is a mixed-case namespace name like Atoi liable to be trampled by a future C++ standard, technical specification (TS), Boost library, compiler, toolchain, etc.?

Quite unlikely.

Compiler extensions should use reserved identifiers.

New standard library (including TS) identifiers are added into the std namespace (or a namespace nested inside std). Boost should add its identifiers into the boost namespace.

An exception to this is macros, which do not exist in namespaces. Boost naming convention is to use a BOOST_ prefix. New standard library macros should use reserved identifiers.

C standard library of course doesn't have namespaces. A new version might add a non-reserved macro, although it should be added into a new header which a pre-existing program wouldn't be including.

A bit more problematic is POSIX standard headers, which add quite a few identifiers, which are not reserved by the C standard into the global namespace. It adds quite a few reserved prefixed and suffixes depending on which POSIX headers are included.

Using a capital letter followed by a lower case letter such as your Atoi suggestion you avoid conflicts with most POSIX reservations, and most standard names which strongly follow convention of all lower, or all upper case (usually for macros).

To minimise name collisions, here are my rules of thumb. Some should be definitely followed, others are merely guidelines:

  • Never use identifiers reserved by the standard, even within namespaces.
  • Avoid macros.
    • Use a consistent prefix when naming macros.
  • Declare only one namespace globally, and no other global identifiers.
    • Declare everything else inside that namespace.
  • Share the same global namespace across all your projects.
    • Not necessarily appropriate for generic, reusable libraries.
    • Use sub-namespaces to avoid collisions across your projects.
    • Use sub-sub-namespaces to avoid collisions within your projects.
  • When naming a global identifier (i.e. the global namespace or a macro), avoid names reserved by the POSIX standard.
eerorika
  • 232,697
  • 12
  • 197
  • 326