Why no non-integral static const initialiser's within class definition?

[Mike Hewson]

Have been researching as to why:

<example 1>

class ABC
{
static const float some_float = 3.3f;
};

<end example 1>

is not allowed.

Found that

<example 2>

class ABC
{
static const float some_float;
};

const float some_float = 3.3f;

<end example 2>

is allowed.

Is this correct and why is it so?

 

[Sharad Kala]

Have been researching as to why:

<example 1>

class ABC
{
static const float some_float = 3.3f;
};

<end example 1>

is not allowed.

The relevant clause is 9.4.2/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. In that case, the member can
appear in integral constant 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."

So the only relaxation is that for static const integral/enum types you can
get away with the definition if you don't use them in their program i.e.
don't treat them as l-values. The key point you are missing is that the
member can still appear in integral constant expressions (like case label).
So this clause is just a relaxation applicable only with integral constant
expressions.

Found that

<example 2>

class ABC
{
static const float some_float;
};

const float some_float = 3.3f;

<end example 2>

is allowed.

Is this correct and why is it so?

No, even this is incorrect. Correct way is -
const float ABC::some_float = 3.3f;

Sharad

 

[velthuijsen]

Have been researching as to why:
<example 1>
class ABC
{
static const float some_float = 3.3f;
};
<end example 1>

is not allowed.
Found that
<example 2>
class ABC
{
static const float some_float;
};
const float some_float = 3.3f;

should be:
const float ABC::some_float = 3.3f;

<end example 2>

is allowed.
Is this correct and why is it so?

The second example is correct.
To be able to do what you did in the first example you variable would
have to conform to the following set of requirements:
Must be static.
Must be const.
Must have some integral or enumeration type.
The initializing value must be an integral constant expression.
Can be initialized at most once. If you initialize them within the
class, you can't initialize them again in their definitions.

The floating point types violate the Must have some integral or
enumeration type requirement.

 

[Mike Hewson]

The relevant clause is 9.4.2/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. In that case, the member can
appear in integral constant 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."

Yeah, I'd found that clause, but I don't read/see how it makes any
comment on non-integral types. Unless my comprehension co-processor is
down this week!

So the only relaxation is that for static const integral/enum types you can
get away with the definition if you don't use them in their program i.e.
don't treat them as l-values.

Yup, they're const....so can't be l-values, however I can surely 'use
them' in a way that doesn't assign to them ( otherwise what's the point
in creating it? )

The key point you are missing is that the
member can still appear in integral constant expressions (like case label).
So this clause is just a relaxation applicable only with integral constant
expressions.




No, even this is incorrect. Correct way is -
const float ABC::some_float = 3.3f;

I think

const float some_float = 3.3f;

is fine. ( Provided there is no other some_float about, in scope to
confuse things )

In any case, perhaps I should rephrase:

Why can I initialise *integral types* in this context and manner but not
any other fundamental type ( or 'user' defined )? Is it a compiler
implementation problem?

 

[Mike Hewson]

should be:
const float ABC::some_float = 3.3f;




The second example is correct.
To be able to do what you did in the first example you variable would
have to conform to the following set of requirements:
Must be static.
Must be const.
Must have some integral or enumeration type.
The initializing value must be an integral constant expression.
Can be initialized at most once. If you initialize them within the
class, you can't initialize them again in their definitions.

The floating point types violate the Must have some integral or
enumeration type requirement.

Yup! I'm looking for the statement/source of that requirement.
Fair enough, does anyone know the rationale for that requirement?

 

[Micah Cowan]

Have been researching as to why:

<example 1>

class ABC
{
static const float some_float = 3.3f;
};

<end example 1>

is not allowed.

The declaration of a static data member is not a definition.
Therefore, it may not include an initializer (9.4.2#2).

As a special exception, a constant expression may be used as the
initializer of a const integral or const enumeration static data
member. But it's still not a definition, and a definition must be
provided somewhere (without an initializer), or its use will
invoke undefined behavior.

Found that

<example 2>

class ABC
{
static const float some_float;
};

const float some_float = 3.3f;

<end example 2>

is allowed.

Is this correct and why is it so?

The above is allowed but doesn't do what you think. You need:

const float ABC::some_float = 3.3f;

HTH.

 

[Sharad Kala]

Yeah, I'd found that clause, but I don't read/see how it makes any
comment on non-integral types. Unless my comprehension co-processor is
down this week!

It clearly states "const integral or const enumeration type". The point is
that const integral or const enumeration type could be used in integral
constant expressions which is not the case with non-integral constant
expressions.

Yup, they're const....so can't be l-values, however I can surely 'use
them' in a way that doesn't assign to them ( otherwise what's the point
in creating it? )

Even if the program takes the address of the member it needs to be defined.

I think

const float some_float = 3.3f;

is fine. ( Provided there is no other some_float about, in scope to
confuse things )

Incorrect. You are just defining an independent global some_float this
way. To define the static member of class you have to write the way I wrote
in my last post.

In any case, perhaps I should rephrase:

Why can I initialise *integral types* in this context and manner but not
any other fundamental type ( or 'user' defined )? Is it a compiler
implementation problem?

Well, the proper place to ask is where people can tell you
why only this is allowed in the language. My guess is that people did not
find it very useful to allow it with non-integral types. Of course this is
my interpretation, other poeple could enlighten us if there are any other
reasons too.

Sharad

 

[Mike Hewson]

The declaration of a static data member is not a definition. Therefore,
it may not include an initializer (9.4.2#2).

Aha! Outstanding!
For the group ( ISO/IEC 14882 ):

9.4.2 Static data members
2 The declaration of a static data member in its class definition is not
a definition and may be of an incomplete type other than cvqualified
void. The definition for a static data member shall appear in a
namespace scope enclosing the member’s class definition. In the
definition at namespace scope, the name of the static data member shall
be qualified by its class name using the :: operator. The initializer
expression in the definition of a static data member is in the scope of
its class (3.3.6).

As a special exception, a constant expression may be used as the
initializer of a const integral or const enumeration static data member.
But it's still not a definition, and a definition must be provided
somewhere (without an initializer), or its use will invoke undefined
behavior.

Oh, how I hate 'static' .... :-(

The above is allowed but doesn't do what you think. You need:

const float ABC::some_float = 3.3f;

Yup, got that.

HTH.

You have, and thanks!

 

[Sharad Kala]

As a special exception, a constant expression may be used as the
initializer of a const integral or const enumeration static data
member. But it's still not a definition, and a definition must be
provided somewhere (without an initializer), or its use will
invoke undefined behavior.

Are you sure it invokes UB even if it is not used in the program ? Let me
quote Bill Gibbons (who wrote 9.4.2/4) - "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".

Sharad

 

[Mike Hewson]

It clearly states "const integral or const enumeration type". The point is
that const integral or const enumeration type could be used in integral
constant expressions which is not the case with non-integral constant
expressions.

I'd read that clause as "IF an X THEN do ...", that is it didn't ( alone
) comment about non-X's.

Even if the program takes the address of the member it needs to be defined.




Incorrect. You are just defining an independent global some_float this
way. To define the static member of class you have to write the way I wrote
in my last post.

Yup, as per 9.4.2 #2

Well, the proper place to ask is where people can tell you
why only this is allowed in the language.

Well it's a place. Good thought, will do.

My guess is that people did not
find it very useful to allow it with non-integral types. Of course this is
my interpretation, other poeple could enlighten us if there are any other
reasons too.

I have this feeling that I'm missing/misunderstanding something
important here. But if it's just arcana I'll relax.

Thank you for your help, Sharad.

 

[Micah Cowan]

Are you sure it invokes UB even if it is not used in the program ? Let me
quote Bill Gibbons (who wrote 9.4.2/4) - "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".

If you read the above quote, "its use will invoke...", that seems
already to answer your "...invokes UB even if it is not used in
the program?".

If the intention of that paragraph is as you state above, then it
was very poorly written. Use means use, not use as an lvalue.
However, that seems at least how it is implemented in practice.
Me, I'll play it safe: even the standard writers themselves can't
change the meaning of the standard, until they formally correct
it. But I am very interested in the source of that quote. Can you
provide the reference?

Personally, I'm going to play it safe, until I get more definite
info. Also, the standard still seems to make it clear that the
existence of the initializer does not make the declaration a
definition, which bolsters the literal interpretation of 9.4.2/4.

 

[Sharad Kala]

If you read the above quote, "its use will invoke...", that seems
already to answer your "...invokes UB even if it is not used in
the program?".

If the intention of that paragraph is as you state above, then it
was very poorly written. Use means use, not use as an lvalue.
However, that seems at least how it is implemented in practice.
Me, I'll play it safe: even the standard writers themselves can't
change the meaning of the standard, until they formally correct
it. But I am very interested in the source of that quote. Can you
provide the reference?

Here is the link to the newsgroup discussion on comp.std.c++ that I was
referring to - http://tinyurl.com/59zop . But like you I too play safe by
still defining it.

Personally, I'm going to play it safe, until I get more definite
info. Also, the standard still seems to make it clear that the
existence of the initializer does not make the declaration a
definition, which bolsters the literal interpretation of 9.4.2/4.

Of course there is no doubt about it.

Sharad

 

[Andrey Tarasevich]

Have been researching as to why:

<example 1>

class ABC
{
static const float some_float = 3.3f;
};

<end example 1>

is not allowed.

Found that

<example 2>

class ABC
{
static const float some_float;
};

const float some_float = 3.3f;

<end example 2>

is allowed.

Is this correct and why is it so?

In-class initializers for static members of integral/enum type are
mainly useful because they allow the use of these members in integral
constant expressions (ICE). That's the reason why such initialization
syntax was allowed in C++. And that's a very good reason because in C++
ICEs play the important role in several contexts.

That can't be said about floating point constants. In other words,
there's no good reason to allow that for floating-point constants. Can
you come up with one?

 

[Andrey Tarasevich]

Are you sure it invokes UB even if it is not used in the program ? Let me
quote Bill Gibbons (who wrote 9.4.2/4) - "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".
...

The definition of what constitutes a "use" of an object in C++ program
has been changed in TC1. Compare the TC1's definition and the original
one and you'll see the difference. According to the TC1's definition, an
appearance of such a member in an integral constant expression no longer
constitutes a "use' of that member and, therefore, no longer requires a
definition (which was required in the original version of the standard).
Informally, it indeed pretty much boils down to "definition is required
only if the member is used as an lvalue".

 

[Micah Cowan]

Sharad Kala wrote:




The definition of what constitutes a "use" of an object in C++ program
has been changed in TC1. Compare the TC1's definition and the original
one and you'll see the difference. According to the TC1's definition, an
appearance of such a member in an integral constant expression no longer
constitutes a "use' of that member and, therefore, no longer requires a
definition (which was required in the original version of the standard).
Informally, it indeed pretty much boils down to "definition is required
only if the member is used as an lvalue".

I'm too lazy to go grab the TC1 language draft. However, if it is
only the "appearance of such a member in an integral constant
expression" that is exempted, that would still be a far cry from
"only if the member is used as an lvalue", since there are many
cases where you would wish to use such a member in a non-constant
expression, and still would not wish to access it as an lvalue
(nor to be bothered with providing a definition).