Why field inside a local class cannot be static?

void foo (int x)
{
  struct A { static const int d = 0; }; // error
}

Other than the reference from standard, is there any motivation behind this to disallow static field inside an inner class ?

error: field `foo(int)::A::d' in local class cannot be static

Edit: However, static member functions are allowed. I have one use case for such scenario. Suppose I want foo() to be called only for PODs then I can implement it like,

template<typename T>
v开发者_开发技巧oid foo (T x)
{
  struct A { static const T d = 0; }; // many compilers allow double, float etc.
}

foo() should pass for PODs only (if static is allowed) and not for other data types. This is just one use case which comes to my mind.

Because, static members of a class need to be defined in global a scope, e.g.

foo.h

class A {
  static int dude;
};

foo.cpp

int A::dude = 314;

Since the scope inside void foo(int x) is local to that function, there is no scope to define its static member[s].

Magnus Skog has given the real answer: a static data member is just a declaration; the object must be defined elsewhere, at namespace scope, and the class definition isn't visible at namespace scope.

Note that this restriction only applies to static data members. Which means that there is a simple work-around:

class Local
{
    static int& static_i()
    {
        static int value;
        return value;
    }
};

This provides you with exactly the same functionality, at the cost of using the function syntax to access it.

Because nobody saw any need for it ?

[edit]: static variables need be defined only once, generally outside of the class (except for built-ins). Allowing them within a local class would require designing a way to define them also. [/edit]

Any feature added to a language has a cost:

• it must be implemented by the compiler
• it must be maintained in the compiler (and may introduce bugs, even in other features)
• it lives in the compiler (and thus may cause some slow down even when unused)

Sometimes, not implementing a feature is the right decision.

Local functions, and classes, add difficulty already to the language, for little gain: they can be avoided with static functions and unnamed namespaces.

Frankly, if I had to make the decision, I'd remove them entirely: they just clutter the grammar.

A single example: The Most Vexing Parse.

I think this is the same naming problem that has prevented us from using local types in template instantiations.

The name foo()::A::d is not a good name for the linker to resolve, so how should it find the definition of the static member? What if there is another struct A in function baz()?

Interesting question, but I have difficulty understanding why you'd want a static member in a local class. Statics are typically used to maintain state across program flow, but in this case wouldn't it be better to use a static variable whose scope was foo()?

If I had to guess why the restriction exists, I'd say it was something to do with the difficulty for the compiler in knowing when to perform the static initialisation. The C++ standards docs might provide a more formal justification.

Just because.

One annoying thing about C++ is that there's a strong dependence on a "global context" concept where everything must be uniquely named. Even the nested namespaces machinery is just string trickery.

I suppose (just a wild guess) that one serious technical issue is working with linkers that were designed for C and that just got some tweak to get them working with C++ (and C++ code needs C interoperability).

It would be nice to be able to get any C++ code and "wrap it" to be able to use it without conflicts in a larger project, but this is not the case because of linkage problems. I don't think there is any reasonable philosophical reason for forbidding statics or non-inline methods (or even nested functions) at the function level but this is what we got (for now).

Even the declaration/definition duality with all its annoying verbosity and implications is just about implementation problems (and to give the ability to sell usable object code without providing the source, something that is now a lot less popular for good reasons).