Define a static in a class declaration .. Legal ??
Roger Onslow
Define a static in a class declaration .. Legal ??
Someone has suggested that:
class X
static int myvalue = 1;
};
is part of the CURRENT ANSI C++ standard.
I thought it was still the case that you needed
class X
static int myvalue;
};
int X::myvalue = 1;
Can anyone confirm/deny this?
If it is not part of the current standard, is such a (sensible) extension
part of any draft standard?
Thanks
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Fergus Henderson
"Roger Onslow" <Roger_Ons...@compsys.com.au> writes:
>Define a static in a class declaration .. Legal ??
You can't *define* a static in a class declaration; however, if the
static has integral type, then you can include an initializer for it.
See 9.2 [class.member] paragraph 4 and 9.4.2 [class.static.data]
paragraph 5 in the draft standard.
>Someone has suggested that:
>
>class X
>
> static int myvalue = 1;
>};
>
>is part of the CURRENT ANSI C++ standard.
Yes, that's correct.
However, you still need a definition
static int X::myvalue;
somewhere.
>I thought it was still the case that you needed
>
>class X
>
> static int myvalue;
>};
>
>int X::myvalue = 1;
Nope.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
sweet boy
The former case:
class x
{
static int myvalue = 1;
};
is illegal, because when you declare a static data member within a
class, you're NOT defining it; that is, you're not allocating storage
for it. Instead, you must provide a global definition for the static
data member elsewhere, outside the class, as you did in the later case.
As a convenience, older versions of C++ did not require the second
declaration of a static member variable. However, this convenience gave
rise to serious inconsistencies, and it was eliminated several years
ago. Even so, you may still find older C++ code that does not redeclare
static member variables. In these cases, you'll need a definition;
maybe what someone suggested is because of this.
sweet boy
e-mail: an...@mail.com
ICQ UIN: 2056592
homepage: http://www.geocities.com/~foreverland
sweet boy
class x{static int myvalue = 1;};
--
Oleg Zabluda
Roger Onslow <Roger_Ons...@compsys.com.au> wrote:
: Define a static in a class declaration .. Legal ??
: Someone has suggested that:
: class X {
: static int myvalue = 1;
: };
: is part of the CURRENT ANSI C++ standard.
: I thought it was still the case that you needed
: class X {
: static int myvalue;
: };
: int X::myvalue = 1;
: Can anyone confirm/deny this?
It's in the current standard. You still can not define static in
class declaration, but you can initialize it there, as long as
the static is of constant integral type.
class X {
static int myvalue1 = 1; // illegal. non-const.
static const float myvalue2 = 1; // illegal. non-integral.
static const int myvalue3 = 1; // legal.
};
static const int X::myvalue3; // you still must provide exactly one
// definition.
Oleg.
---
Alexandre Oliva
Roger Onslow <Roger_Ons...@compsys.com.au> writes:
> Define a static in a class declaration .. Legal ??
Yes, as long as the data member is of integral or enumeration type
[class.mem]/4 and [class.static.data]/4. However, there must still be
a definition of this data member outside the class body, without an
initializer.
--
Alexandre Oliva
mailto:ol...@dcc.unicamp.br mailto:aol...@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil
Nathan Myers
Fergus Henderson<f...@cs.mu.OZ.AU> wrote:
>"Roger Onslow" <Roger_Ons...@compsys.com.au> writes:
>You can't *define* a static in a class declaration; however, if the
>static has integral type, then you can include an initializer for it.
>See 9.2 [class.member] paragraph 4 and 9.4.2 [class.static.data]
>paragraph 5 in the draft standard.
>
>>
>> class X { static int myvalue = 1; };
>>
>
>Yes, that's correct.
No, it's not correct. However, you can say this:
class X { static const int myvalue = 1; };
^^^^^
It must be static, it must be const, and it must be an integer
or enumeration type.
>However, you still need a definition
>
> static int X::myvalue;
>
>somewhere.
This is also not right, for the cases where in-class definition
is permitted. You only need such a definition if some bit of
code takes its address.
--
Nathan Myers
n...@nospam.cantrip.org http://www.cantrip.org/
Alexandre Oliva
Nathan Myers <n...@nospam.cantrip.org> writes:
> No, it's not correct. However, you can say this:
> class X { static const int myvalue = 1; };
> ^^^^^
> It must be static, it must be const, and it must be an integer
> or enumeration type.
Nope, it need not be const. You're mixing up two different issues.
First, there's [class.static.data]/4, that says:
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
(_expr.const_). In that case, the member can appear in integral con-
stant expressions within its scope. The member shall still be defined
in a namespace scope if it is used in the program and the namespace
scope definition shall not contain an initializer.
Which means that the declaration of a const-qualified static data
member of integral or enumeration type can have an initializer and, if
it does, it can be used as a constant.
Note, however, that it doesn't state that an initializer is acceptable
only for such types. But then, there's [class.mem]/4:
4 A member-declarator can contain a constant-initializer only if it
declares a static member (_class.static_) of integral or enumeration
type, see _class.static.data_.
Which says nothing about constness.
>> However, you still need a definition
>> somewhere.
> This is also not right, for the cases where in-class definition
> is permitted. You only need such a definition if some bit of
> code takes its address.
It may be the case for most reasonable implementations, but it is not
specified in the (to-be) Standard, so you can't count on this. Better
be on the safe side, and provide a definition somewhere.
--
Alexandre Oliva
mailto:ol...@dcc.unicamp.br mailto:aol...@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil
Oleg Zabluda
In comp.std.c++ Nathan Myers <n...@nospam.cantrip.org> wrote:
: Fergus Henderson<f...@cs.mu.OZ.AU> wrote:
[...]
: class X { static const int myvalue = 1; };
[...]
: >However, you still need a definition
: >
: > static int X::myvalue;
: >
: >somewhere.
: This is also not right, for the cases where in-class definition
: is permitted. You only need such a definition if some bit of
: code takes its address.
Can you point to the wording in the standard which says so?
As a practical matter, I understand that this should be
the case, since anyone who uses the value of the static
member, must see the definition of the class and therefore
the initializer for this static member. However, the standard
seems to say that you must provide the definition nevertheless.
9.4.2 Static data members.
[...]
5 There shall be exactly one definition of a static
data member that is used in the program; no diagnostic
is required; see 3.2. ....
3.2 One definition rule.
[...]
2 .... An object ... is used if its name appears in a
potentially-evaluated expression.
Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
Nathan Myers
Oleg Zabluda <zab...@math.psu.edu> wrote:
>In comp.std.c++ Nathan Myers <n...@nospam.cantrip.org> wrote:
>: Fergus Henderson<f...@cs.mu.OZ.AU> wrote:
>: class X { static const int myvalue = 1; };
>: > static int X::myvalue;
>: >somewhere.
>
>: code takes its address.
>
>Can you point to the wording in the standard which says so?
I thought I recalled a proposal passing that relaxed the
requirement as described. Unless some wording turns up,
it seems I misremembered.
--
Nathan Myers
n...@nospam.cantrip.org http://www.cantrip.org/
---
Bill Gibbons
In article <6jbada$3u4$1...@shell7.ba.best.com>, n...@nospam.cantrip.org
(Nathan Myers) wrote:
> Oleg Zabluda <zab...@math.psu.edu> wrote:
> >In comp.std.c++ Nathan Myers <n...@nospam.cantrip.org> wrote:
> >: Fergus Henderson<f...@cs.mu.OZ.AU> wrote:
> >: class X { static const int myvalue = 1; };
> >: >However, you still need a definition
> >: > static int X::myvalue;
> >: >somewhere.
> >
> >: You only need such a definition if some bit of
> >: code takes its address.
> >
> >Can you point to the wording in the standard which says so?
>
> I thought I recalled a proposal passing that relaxed the
> requirement as described. Unless some wording turns up,
> it seems I misremembered.
Yes, we agreed to this, but it appears that the wording did not make it
into the final draft. It seems likely that the official interpretation
of the standard will be that the definition is needed only if the static
member is used as an lvalue, i.e. its address is taken.
In article <org1ij4...@zecarneiro.lsd.dcc.unicamp.br>, Alexandre Oliva
<ol...@dcc.unicamp.br> wrote:
> Nathan Myers <n...@nospam.cantrip.org> writes:
>
> > No, it's not correct. However, you can say this:
>
> > class X { static const int myvalue = 1; };
> > ^^^^^
>
> > It must be static, it must be const, and it must be an integer
> > or enumeration type.
>
> Nope, it need not be const.
Yes, it must. That was explicit in the proposal. (I know, I wrote it.)
-- Bill Gibbons
bi...@gibbons.org
Alexandre Oliva
Bill Gibbons <bi...@gibbons.org> writes:
> In article <org1ij4...@zecarneiro.lsd.dcc.unicamp.br>, Alexandre Oliva
> <ol...@dcc.unicamp.br> wrote:
>> Nathan Myers <n...@nospam.cantrip.org> writes:
>> > It must be static, it must be const, and it must be an integer
>> > or enumeration type.
>> Nope, it needs not be const.
> Yes, it must. That was explicit in the proposal. (I know, I wrote it.)
Does this mean the FDIS's wording for [class.mem]/4 is any different
from the wording in the Nov'97 DWP, that I've quoted in
<URL:http://x3.dejanews.com/getdoc.xp?AN=352730637&CONTEXT=895470201.856555626&hitnum=10>
? Or is my interpretation incorret?
--
Alexandre Oliva
mailto:ol...@dcc.unicamp.br mailto:aol...@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil
---
Bill Gibbons
In article <ork97kn...@zecarneiro.lsd.dcc.unicamp.br>, Alexandre Oliva
<ol...@dcc.unicamp.br> wrote:
> Does this mean the FDIS's wording for [class.mem]/4 is any different
> from the wording in the Nov'97 DWP? Or is my interpretation incorret?
The wording has not changed; it is still as quoted:
> First, there's 9.4.2/4, that says:
>
> 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 con-
> stant expressions within its scope. The member shall still be defined
> in a namespace scope if it is used in the program and the namespace
> scope definition shall not contain an initializer.
>
> Which means that the declaration of a const-qualified static data
> member of integral or enumeration type can have an initializer and, if
> it does, it can be used as a constant.
>
> Note, however, that it doesn't state that an initializer is acceptable
> only for such types. But then, there's 9.2/4:
>
> 4 A member-declarator can contain a constant-initializer only if it
> declares a static member (9.4) of integral or enumeration
> type, see 9.4.2.
It is true that the restriction is omitted from the second paragraph.
When interpreting the draft, though, keep in mind that:
(1) Sections which present an overview of a language feature cannot
quote the entire text of the corresponding detail sections.
In this case, the complete description of static data members
is in 9.4.2, and the overview in 9.2 is less complete - and
less definitive. Obviously one additional word in the overview
would have eliminated some confusion in this case.
(2) The fact that one section does not mention a feature or restriction
does not imply that no such feature or restriction exists; only
its omission throughout the draft would imply that. So when one
section omits a feature or restriction and another specifies it
explicitly, there is no conflict.
The committee was painfully aware that the draft is a very large document
which is very difficult to read. Mentioning every feature only once would
have made the draft more precise but also much less readable. So we tried
to strike a balance, repeating parts of the descriptions of some language
features when it seemed necessary for clarity.
Since these repeated descriptions are usually more brief than the complete
specifications from which they were extracted, they usually omit many of
the details. This often leads to the situation above, where you really
must refer to the defining section to get the complete specification.
(There is usually a cross-reference to that section, as above.)
-- Bill Gibbons
bi...@gibbons.org
jka...@otelo.ibmmail.com
In article <ork97kn...@zecarneiro.lsd.dcc.unicamp.br>,
Alexandre Oliva <ol...@dcc.unicamp.br> wrote:
>
>
> > In article <org1ij4...@zecarneiro.lsd.dcc.unicamp.br>, Alexandre
Oliva
> > <ol...@dcc.unicamp.br> wrote:
>
> >> Nathan Myers <n...@nospam.cantrip.org> writes:
> >> > It must be static, it must be const, and it must be an integer
> >> > or enumeration type.
>
> >> Nope, it needs not be const.
>
> > Yes, it must. That was explicit in the proposal. (I know, I wrote it.)
>
>
<URL:http://x3.dejanews.com/getdoc.xp?AN=352730637&CONTEXT=895470201.85655562
6&hitnum=10>
It almost looks like there is a contradiction in the standard:
[class.mem]/4 references [class.static.data], where it says: "If a
static data member is of const integral or const enumeration type,
its declaration in the class definition can specify a
constant-initializer [...]". The types must be const, although it
doesn't say that in [class.mem]/4.
--
James Kanze +33 (0)1 39 23 84 71 mailto: ka...@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jka...@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientée objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Alexandre Oliva
Bill Gibbons <bi...@gibbons.org> writes:
>> 4 A member-declarator can contain a constant-initializer only if it
>> declares a static member (9.4) of integral or enumeration
>> type, see 9.4.2.
> It is true that the restriction is omitted from the second paragraph.
I'm not a native speaker of English, but the text seems quite clear to
me, and 9.4.2/4 seems to specify only an additional property of static
members of integral or enumeration constant types, namely, that they
can be used to form constant expressions. If 9.4.2/4 started with
`If, and only if', or 9.2/4 explicitly restricted to constant types,
there'd be no doubt, but the current specification *is* misleading. A
defect report should be issued, IMO.
--
Alexandre Oliva
mailto:ol...@dcc.unicamp.br mailto:aol...@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil
---