By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,084 Members | 1,207 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,084 IT Pros & Developers. It's quick & easy.

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

P: n/a
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?

--

Cheers
--
Hewson::Mike
"This letter is longer than usual because I lack the time to make it
shorter" - Blaise Pascal
Jul 22 '05 #1
Share this Question
Share on Google+
14 Replies


P: n/a

"Mike Hewson" <he******@optusnet.com.au> wrote in message
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

Jul 22 '05 #2

P: n/a
Mike Hewson wrote:
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.

Jul 22 '05 #3

P: n/a
Sharad Kala wrote:
"Mike Hewson" <he******@optusnet.com.au> wrote in message
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.

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;


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?

--

Cheers
--
Hewson::Mike
"This letter is longer than usual because I lack the time to make it
shorter" - Blaise Pascal
Jul 22 '05 #4

P: n/a
ve*********@hotmail.com wrote:
Mike Hewson wrote:
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.


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

--

Cheers
--
Hewson::Mike
"This letter is longer than usual because I lack the time to make it
shorter" - Blaise Pascal
Jul 22 '05 #5

P: n/a
Mike Hewson wrote:
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.
Jul 22 '05 #6

P: n/a

"Mike Hewson" <he******@optusnet.com.au> wrote in message
Sharad Kala wrote:
"Mike Hewson" <he******@optusnet.com.au> wrote in message
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!


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.

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? )


Even if the program takes the address of the member it needs to be defined.
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;


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 news:comp.std.c++ 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
Jul 22 '05 #7

P: n/a
Micah Cowan wrote:
Mike Hewson wrote:
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).


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' .... :-(

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;


Yup, got that.

HTH.


You have, and thanks!

--

Cheers
--
Hewson::Mike
"This letter is longer than usual because I lack the time to make it
shorter" - Blaise Pascal
Jul 22 '05 #8

P: n/a

"Micah Cowan" <mi***@cowan.name> wrote in message
news:41**********************@news.calweb.com...
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
Jul 22 '05 #9

P: n/a
Sharad Kala wrote:
"Mike Hewson" <he******@optusnet.com.au> wrote in message
Sharad Kala wrote:
"Mike Hewson" <he******@optusnet.com.au> wrote in message
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!

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.

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? )

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

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;


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.


Yup, as per 9.4.2 #2
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 news:comp.std.c++ 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.

--

Cheers
--
Hewson::Mike
"This letter is longer than usual because I lack the time to make it
shorter" - Blaise Pascal
Jul 22 '05 #10

P: n/a
Sharad Kala wrote:
"Micah Cowan" <mi***@cowan.name> wrote in message
news:41**********************@news.calweb.com...

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".


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.
Jul 22 '05 #11

P: n/a

"Micah Cowan" <mi***@cowan.name> wrote in message
Sharad Kala wrote:
"Micah Cowan" <mi***@cowan.name> wrote in message
news:41**********************@news.calweb.com...

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".


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
Jul 22 '05 #12

P: n/a
Mike Hewson wrote:
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?

--
Best regards,
Andrey Tarasevich
Jul 22 '05 #13

P: n/a
Sharad Kala wrote:
"Micah Cowan" <mi***@cowan.name> wrote in message
news:41**********************@news.calweb.com...
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".
...


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".

--
Best regards,
Andrey Tarasevich
Jul 22 '05 #14

P: n/a
Andrey Tarasevich wrote:
Sharad Kala wrote:

"Micah Cowan" <mi***@cowan.name> wrote in message
news:41**********************@news.calweb.com. ..

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".
...

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).
Jul 22 '05 #15

This discussion thread is closed

Replies have been disabled for this discussion.