global integral constants

Often in a project, there is a need for some global integral constants (which may be used as array sizes).

For example, in a recent project, I was working on a hardware emulator which has a fixed number of analog inputs. so in Globals.h I had

Code:

---

namespace NSP // platform name
{

    static const unsigned int NUM_INPUTS = 20;

} // namespace NSP

---

but it was mentioned to me that static used in this fashion is deprecated, and the preferable solution is to use an unnamed namespace. so then we have

Code:

---

namespace NSP // platform name
{

    namespace // anon
    {
        const unsigned int NUM_INPUTS = 20;
    } // namespace anon
} // namespace NSP

---

and ye standard gods were appeased.

but after a bit of unrelated research today, I've discovered that unnamed namespaces in headers are a no-no as they can violate ODR.

so what's the correct way? I don't like the "enum-hack" (for one thing, you can't take the address of it if you need to).

Quote:

---

but after a bit of unrelated research today, I've discovered that unnamed namespaces in headers are a no-no as they can violate ODR.

---

Where was that? I don't think it would be a problem if you had inclusion guards.

Why do you need static or an unnamed namepsace for that use? Usually static is for constants put into a source file (and similarly the unnamed namespace). For those you want to be global, wouldn't you add an extern declaration in the header and a non-static definition in the source?

>> I don't think it would be a problem if you had inclusion guards.
A separate constant would be created for each compilation unit that includes that header.

Quote:

---

Originally Posted by Daved

Why do you need static or an unnamed namepsace for that use? Usually static is for constants put into a source file (and similarly the unnamed namespace). For those you want to be global, wouldn't you add an extern declaration in the header and a non-static definition in the source?

---

if you have an extern you can't use the constant as an array size attribute.

It can happen if there is little care in the definition of those unamed namespaces. Names defined inside a unamed namespace are local to the file only. We cannot span unamed namespaces across files as we do with regular names.

Consider somefile.h:

Code:

---

namespace {
    int a;
}

---

and anotherfile.h

Code:

---

namespace {
    int a;
}

---

now... consider source.cpp

Code:

---

#include "somefile.h"
#include "anotherfile.h"
int main() {
  // which int a?
}

---

The solution can be one of two, from what I can see:

Declare unamed namespaces within named namespaces taking advantage of the fact we can nest namespaces.

Or remember that namespaces expect object definitions. Not necessarily declarations. It is at the object definition time that the object will be associated with the namespace. So it's possible to declare the object somewhere and define it somewhere else inside a namespace. This basically means, creating the unamed namespace in source files.

EDIT: Hmm... at second thought I'm not that sure of this second option.

Quote:

---

Originally Posted by Mario F.

Declare unamed namespaces within named namespaces taking advantage of the fact we can nest namespaces.

---

That's what ChaosEngine is doing. So does that mean that the code as given doesn't violate ODR?

Code:

---

namespace NSP // platform name
{

    namespace // anon
    {
        const unsigned int NUM_INPUTS = 20;
    } // namespace anon
} // namespace NSP

---

Well, no. Because you are in control of the namespace. It's yours. You should know your namespace members. As such you can know if you have already defined an object with the same name inside that namespace and that is within scope of the redefinition.

>> if you have an extern you can't use the constant as an array size attribute.

I see. I don't know the answer. However, doesn't a static const in a header violate ODR just as much as the constant in the unnamed namespace in a header? I don't know if there is a way to do it that doesn't create multiple definitions. Otherwise, how would the compiler know the size of the array in the different compilation units?

Perhaps create an enum and an extern const in the header, then use the enum for array sizes and define the const equal to the enum in a source file so you can take its address.

> I don't know if there is a way to do it that doesn't create multiple definitions.

There is nothing wrong with namespaces, Daved.

So ChaosEngine's anonymous namespace code is correct? [edit] Assuming there isn't another variable in the namespace called NUM_INPUTS. [/edit]

Yes. That's my opinion. Assuming he owns the NSP namespace (he is the implementator of that namespace).

If he does, he controls what names are declared and when. The unamed namespace is controled by an outer named namespace. Named namespaces can span across several files (unamed ones can't). It's that simple. It is thus safe to declare that namespace in an header file. Of course, ChaosEngine just needs to make sure he's only defining the variable once within the NSP namespace. But he can create as many unamed namespaces with that same variable exactly as he wants in other files. They don't span across files.

cheers, guys. that pretty much confirms what I thought, just wanted to get a few other opinions on it.

Quote:

---

but after a bit of unrelated research today, I've discovered that unnamed namespaces in headers are a no-no as they can violate ODR.

---

So I guess this meant to not use anonymous namespaces in the global namespace?

Code:

---

// header.h
#ifndef HEADER_H
#define HEADER_H 1

namespace {
    const int x = 0;
};

#endif

---

>> There is nothing wrong with namespaces, Daved.
Falcons have no teeth, Mario F.

If you use an unnamed namespace there will be multiple definitions of the constant in the program. It will compile and link correctly, but different compilation units will get different results if they take the address of the constant. I was under the impression that this is what was trying to be avoided.

Putting the unnamed namespace inside of a named namespace has no effect on the situation, it is irrelevent to the issue.

Using the enum and extern does work, and provides a single address for each compilation unit.

>> So I guess this meant to not use anonymous namespaces in the global namespace?
No, unnamed namespaces in header files generally defeats the purpose of them. Unnamed namespaces in the global namespace are the normal way of using them.

Yup. That is bad. Because unnamed namesapces defined globally basically put all their members on the global scope. This is so because unnamed namespaces place their member names at the scope the unnamed namespace was declared.

Code:

---

    int i;  // global i
    namespace {
        int i; // namespace i
    }
    i = 12;  // error here. It's ambiguous.

---

Note that the error is only caught when the variable is used. Which makes this type of error a nasty one to debug.

> It will compile and link correctly, but different compilation units will get different results if they take the address of the constant.

Well... I'm assuming there is no need to take the address of an integral constant.

>> Well... I'm assuming there is no need to take the address of an integral constant.

From the first post:
>> I don't like the "enum-hack" (for one thing, you can't take the address of it if you need to).

In addition, and someone else can correct me if I'm wrong, but wouldn't a different address mean that the ODR is violated?

Quote:

---

If you use an unnamed namespace there will be multiple definitions of the constant in the program. It will compile and link correctly, but different compilation units will get different results if they take the address of the constant. I was under the impression that this is what was trying to be avoided.

---

That would happen with the original code, with a static variable, would it not?

>> That would happen with the original code, with a static variable, would it not?
Yes. Which is what I said earlier.

But... who talked about taking the address of the variable? And... what if he does? Wouldn't the address be in scope of whatever unit it was using? If I pass a pointer to a function I'm passing it an address that the function will place in its own scope.

... I really don't see the problem here.

>> But... who talked about taking the address of the variable?
ChaosEngine said (and I already quoted) that the enum-hack was out because you cannot take the address of an enum.

Separately, the different addresses are an indication that different constants are created for each compilation unit. Is this a violation of ODR? Isn't that what the question is all about? Your mention of scope is irrelevent. We're not worried about whether the code will compile and link.

Here is my test code:

Code:

---

// Header.h

#ifndef HEADER_H
#define HEADER_H

#define USE_UNNAMED_NAMESPACE 1

namespace NS
{
#if USE_UNNAMED_NAMESPACE
    namespace
    {
        const int size = 10;
    }
#else
    enum { size_enum = 10 };
    extern int size;
#endif
}

void Test1();
void Test2();

#endif // HEADER_H

---

Code:

---

// Source1.cpp

#include <iostream>
#include "Header.h"

void Test1()
{
    std::cout << "Test1: " << NS::size << ", " << &(NS::size) << '\n';
}

---

Code:

---

// Source2.cpp

#include <iostream>
#include "Header.h"

void Test2()
{
    std::cout << "Test2: " << NS::size << ", " << &(NS::size) << '\n';
}

---

Code:

---

// main.cpp

#include "Header.h"

#if !USE_UNNAMED_NAMESPACE
int NS::size = NS::size_enum;
#endif

int main()
{
    Test1();
    Test2();
}

---

Change USE_UNNAMED_NAMESPACE to 0 to see it with the enum/extern hack.

So those are the only two options if you want to be able to take the address of the variable, right? [edit] Or the static keyword, which does the same thing. [/edit]

I don't know if that's the only way. You could also make it a member of a class:

Code:

---

struct NS
{
    static const int size = 10;
};

---

This would mean that all compilations would get the same address for the constant, it would be available for sizing of arrays, and it wouldn't require two different names (like the enum-extern hack). I'm not sure if it is standard, though, to allow the initialization of the static const like that. There might also be other issues I haven't thought of or mentioned.

>> I'm not sure if it is standard, though, to allow the initialization of the static const like that.

from the standard:

Quote:

---

9.4.2.4 If a static data member is of const integral or const enumeration type, its declaration in the class definition can specify a constant-initializer which shall be an integral constant expression (5.19). In that case, the member can appear in integral constant expressions.

---

so you're sweet.

Well I stand corrected and I have learned something new.