static member variable

[siddhu]

Dear experts,

Let's say we have static member variable in a class declared in a
header file and we define it in a cpp file.

//A.h
class A
{
static int i;
};

//A.cpp

int A::i = 0;

When we define it in a cpp file we also mention the type of of the
variable ( e..g int in this case ).
Is it a redundant information we are giving to the compiler or is
there a logical reasoning behind this?

Regards,
Siddharth

 

[Victor Bazarov]

Let's say we have static member variable in a class declared in a
header file and we define it in a cpp file.

//A.h
class A
{
static int i;
};

//A.cpp

int A::i = 0;

When we define it in a cpp file we also mention the type of of the
variable ( e..g int in this case ).
Is it a redundant information we are giving to the compiler or is
there a logical reasoning behind this?

This might be the case answered in FAQ 5.2, I am just not sure about it.
If not, let's see what would you suggest. How would you change the
contents of 'A.cpp'?

V

 

[Stefan Ram]

//A.h
Is it a redundant information we are giving to the compiler or is
there a logical reasoning behind this?

When A.h is included in other source files, it is not
redundant, because in other source files, there is no other
declaration of i.

When A.h is included in A.cpp, it is not redundant, because it
helps to find errors that might occur, when the redeclaration
is not compatible with the first declaration.

 

[siddhu]

You mean in case we do not mention the type in cpp file.
I guess I will have to refer to header file to find out the type.

 

[siddhu]

You mean in case we do not mention the type in cpp file.
I guess I will have to refer to header file to find out the type.






- Show quoted text -

Stefan, Thanks for replying. I am sorry i did not get your point. I
think I am thinking in a wrong direction.
If there is no other declaration of i, type of i can not be anything
other than "int" and scope of i is also mentioned. So for linker there
should be no ambiguity in finding the definition of A::i. Please
enlighten me.

Regards,
Siddharth

 

[Victor Bazarov]

Stefan, Thanks for replying. I am sorry i did not get your point. I
think I am thinking in a wrong direction.
If there is no other declaration of i, type of i can not be anything
other than "int" and scope of i is also mentioned. So for linker there
should be no ambiguity in finding the definition of A::i.

Please demonstrate "the definition of A::i". What would it look like?
Would it look exactly like the one you already have in 'A.cpp'? If so,
what's your question is about? Or, would it look different? If so, how?

V

 

[siddhu]

A.cpp will be something like.

A::i=0; // without mentioning the type of i

Do we provide the type for compiler's convenience?

 

[Paul Brettschneider]

Please demonstrate "the definition of A::i". What would it look like?
Would it look exactly like the one you already have in 'A.cpp'? If so,
what's your question is about? Or, would it look different? If so, how?

class A { static int i; };
decltype(A::i) A::i = 0;

 

[Juha Nieminen]

decltype(A::i) A::i = 0;

I think this would be handier (although I can't say how unambiguous or
easy to parse it would be):

auto A::i = 0;

 

[Victor Bazarov]

I think this would be handier (although I can't say how unambiguous or
easy to parse it would be):

auto A::i = 0;

Sure. I'm all for the latter. But (a) it's not there yet, (b) not sure
it's going to be there, and (c) does the OP understand the difference
between this and what he "proposed"?

V

 

[Paul Brettschneider]

I think this would be handier (although I can't say how unambiguous or
easy to parse it would be):

auto A::i = 0;

Yes, but if I understood the difference between decltype and auto correctly,
the latter would depend on the type of "0" and not of "A::i", as was
intended.

 

[James Kanze]

A.cpp will be something like.

A::i=0; // without mentioning the type of i

That's also a legal statement in C++, but it's not a definition,
it's an expression statement. One of the reasons (in C++) that
you have to mention the type is because that's how the compiler
recognizes that the statement is a declaration, and not an
expression. (In the case of C++, it's actually a lot more
complicated, since expressions can also begin with the name of a
type. But that was the case in C.)

Do we provide the type for compiler's convenience?

One could argue that it is provided for better error checking.
In this case, however, I'm sceptical---I think it's mainly a
result of C++ grammar rules, which derive from those of C. But
regardless of the language, you do need some way to tell the
compiler that what follows is a variable definition, and not
something else. In your example, "int" is about as short as it
gets---there'd be no advantage in replacing it with e.g. "var".
But for complicated types (e.g. something like std::vector<
MyNamespace::MyClass::MyNestedClass >::const_iterator), one
might argue in favor of allowing auto here as well:
auto A::i = ... ;
, since as you say, the compiler knows the type already. On
the other hand, one could argue against it on the grounds of
orthogonality: the compiler doesn't always know the declared
type of the variable, because not all variables have to be
previously declared, and it's perhaps confusing that the actual
type used comes from a previous declaration, if one is present,
or from the initialization expression otherwise. (The current
rule is that it always comes from the initialization
expression.)

 

[James Kanze]

I think this would be handier (although I can't say how
unambiguous or easy to parse it would be):

auto A::i = 0;

And what about this:
extern long x ;
auto x = 0 ;
What worries me about this suggestion is that depending on
context, the type resulting from auto depends on a previous
declaration or the initialization expression. Which could lead
to confusion.

 

[James Kanze]

When A.h is included in other source files, it is not
redundant, because in other source files, there is no other
declaration of i.

When A.h is included in A.cpp, it is not redundant, because
it helps to find errors that might occur, when the
redeclaration is not compatible with the first declaration.

I think his proposal was to not have to repeat the type in the
definition in A.cc; the only place the type would be specified
would be in A.hh.

 

[Stefan Ram]

I think his proposal was to not have to repeat the type in the
definition in A.cc; the only place the type would be specified
would be in A.hh.

One wants what I call »centralization«, that is, each
information should be stored only at no more than one location
in the world.

But why? So that we only need to do /one/ change, when this
record of information is supposed to change.

So, one wants the datatype »int« to be mentioned only once for
a given variable (in the header file, not in the source file).

But, if this would be possible, would it help to change the
type just once and be done? Most often, not, because usually
many other pieces of code depend on this type and need to be
changed, too.

Repeating the »int« in the source file, also gives some more
readability to this location (the human reader might not
immediatly know the »decltype« of an identifier).

One »modern« solution to the »problem« of changing the
datatype of a declaration only once might be a refactor
function in an IDE that will change the type of an identifier
in all its declarations within a given set of source files.

One solution for people with much leisure: Write your own
module definition language on top of C++. Define a »module« in
this language. Then, your translator will generate a pair of
».h« and ».cpp« files from you module definition file.

A rough attempt to do something like this sometimes is:

int i
#if !INCLUDED
= 0
#endif
;

That is a single file doubling as both a header and a
source file. When it is supposed to be the header file,
one writes something like:

#define INCLUDED
#include "example.cpp"
#undef INCLUDED

But every such deviation from standard coding styles reduces
the readability of a project.

 

[Abhishek Padmanabh]

  One wants what I call »centralization«, that is, each
  information should be stored only at no more than one location
  in the world.

  But why? So that we only need to do /one/ change, when this
  record of information is supposed to change.

  So, one wants the datatype »int« to be mentioned only once for
  a given variable (in the header file, not in the source file).

  But, if this would be possible, would it help to change the
  type just once and be done? Most often, not, because usually
  many other pieces of code depend on this type and need to be
  changed, too.

That probably wouldn't be the reason. I would tend to look at the
question from the point that if something is redundant information,
that there is no use of it, why have that in the first place rather
than when questioning the existing syntax, having to explain the use
of redundancy removal.

  Repeating the »int« in the source file, also gives some more
  readability to this location (the human reader might not
  immediatly know the »decltype« of an identifier).

Isn't that true for just about any member variable where in the source
file the type information is not available? I am not saying that this
information is not useful as of now but this reasoning doesn't cover
up for the redundancy much.

It would probably lead to a "special" case handling for parsing for
definition by compilers which probably now assume type info to be in
the statement, but in our case they would need to consider the case
where the type info might have been lacking and it would have to store
that type info from header file. And in that case, the "special" would
have just been "normal".

Hypothetically,

A::i = 0;

would have worked. Considering that this is not allowed outside a
function block anyway now, so this would not have led to any ambiguity
for the parser (unless I am unable to recall an exception). It could
have been treated as a definition and it would have just worked fine
without the need of "auto" or "decltype".

To conclude, since I am unable to find any use of the repeated type
information in the static variable definition, as of now, I do think
the type information is redundant and C++ would have been as fairy
that way as it is now.