Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

I came up with the idea of using decltype to define static members in a .cpp file, and then using this macro:

#define DEFINE_SYMBOL(x) decltype(x) x
This way, for instance, if class Foo declares static int bar, I can do the following in foo.cpp:
DEFINE_SYMBOL(Foo::bar) = 1337;
This seems a bit "hacky", but it has the advantage of being resilient to changes in the original symbol type. For instance, if bar changes to unsigned in foo.hpp, I wouldn't need to change foo.cpp. It's also easier to read when the type of the member is complex.
However, if the static member is private, in Visual Studio 2015, Intellisense complains about using decltype (saying it's inaccessible). The complaint makes sense, although the program compiles just fine. Now, my question is, is Intellisense wrong, or is this usage of decltype not recommended (and why)?
                Looks like IntelliSense thinks DEFINE_SYMBOL(Foo::bar) would be a function call and not a macro.
– Simon Kraemer
                Nov 4, 2015 at 12:52
Intellisense is incorrect, both gcc and clang compile a similar program and we can see the draft C++ standard section 11 [class.access] says:
  
All access controls in Clause 11 affect the ability to access a class member name from the declaration of a particular entity, including parts of the declaration preceding the name of the entity being declared and, if the
  entity is a class, the definitions of members of the class appearing outside the class’s member-specification.
  [ Note: this access also applies to implicit references to constructors, conversion functions, and destructors.
  —end note ] [ Example:
class A {
typedef int I; // private member
I f();
friend I g(I);
static I x;
template<int> struct Q;
template<int> friend struct R;
protected:
struct B { };
A::I A::f() { return 0; }
A::I g(A::I p = A::x);
A::I g(A::I p) { return 0; }
A::I A::x = 0;
template<A::I> struct A::Q { };
template<A::I> struct R { };
struct D: A::B, A { };
  
Here, all the uses of A::I are well-formed because A::f, A::x, and A::Q are members of class A and g and
  R are friends of class A. This implies, for example, that access checking on the first use of A::I must be
  deferred until it is determined that this use of A::I is as the return type of a member of class A. Similarly,
  the use of A::B as a base-specifier is well-formed because D is derived from A, so checking of base-specifiers
  must be deferred until the entire base-specifier-list has been seen. —end example ]
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.