static member variable
siddhu
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
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
siddhu
I guess I will have to refer to header file to find out the type.
> I do not respond to top-posted replies, please don't ask- Hide quoted text -
>
> - Show quoted text -
siddhu
>
> - 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
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?
siddhu
A::i=0; // without mentioning the type of i
Do we provide the type for compiler's convenience?
Paul Brettschneider
> siddhu wrote:
>> On Jul 28, 2:07 pm, siddhu <siddharth....@gmail.com> wrote:
>>> 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.
>>>
>>> On Jul 28, 1:59 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
>>>
>>>> siddhu wrote:
>>>>> 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'?
>>
>> 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?
class A { static int i; };
decltype(A::i) A::i = 0;
:-P
Juha Nieminen
> decltype(A::i) A::i = 0;
> :-P
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
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"?
Paul Brettschneider
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 (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
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
> siddhu <siddharth....@gmail.com> writes:
> >//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.
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.
Abhishek Padmanabh
> James Kanze <james.ka...@gmail.com> writes:
> >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.
>
> 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. :-)