Static const non-integrals in-class initialization

M

Miguel Guedes

Hello,

Why can't non-integral static const data members be initialized within a class?

I know how to initialize the members but I don't understand the underlying
reason to this rule. Would someone explain this to me?

Example:

class foo
{
public:
static const float f = 0.02f; // Error!
static const int i = 1; // Valid.
};


-- Miguel Guedes - X marks the spot for spammers. If you wish to get in touch
with me by email, remove the X from my address. -
 
R

red floyd

Miguel said:
Hello,

Why can't non-integral static const data members be initialized within a class?

I know how to initialize the members but I don't understand the underlying
reason to this rule. Would someone explain this to me?

Example:

class foo
{
public:
static const float f = 0.02f; // Error!
static const int i = 1; // Valid.
};

Because the Standard says so. I don't know if this has been changed in
the draft 0x standard.
 
M

Miguel Guedes

red said:
Because the Standard says so. I don't know if this has been changed in
the draft 0x standard.

Well, yes. But I'm interested in knowing the reason why they chose to
differentiate the way non-integrals are initialized. Anyone knows?
 
O

Ondra Holub

Well, yes. But I'm interested in knowing the reason why they chose to
differentiate the way non-integrals are initialized. Anyone knows?

--
Miguel Guedes

- X marks the spot for spammers. If you wish to get in touch with me by email,
remove the X from my address. -

I am only guessing. Maybe this way may be initialized only these
types, which are allowed as template parameters. But I do not know why.
 
B

BobR

Miguel Guedes said:
Well, yes. But I'm interested in knowing the reason why they chose to
differentiate the way non-integrals are initialized. Anyone knows?

Then you should ask in an NG that deals with those issues. Maybe
comp.std.c++.

Until *all* systems agree on the float/double format, you probably won't see
it happen.
Take a trip through <limits> to see what has to be dealt with.
Is it FPU or is it emulated? (memorex ad)<G>
 
A

Alf P. Steinbach

* Miguel Guedes:
Well, yes. But I'm interested in knowing the reason why they chose to
differentiate the way non-integrals are initialized. Anyone knows?

No. It has been discussed before, several times. And the upshot seems
to be that if other types than integral types were to be allowed, then
it was feared that this would open up a hornet's nest of issues the
commitee would then have to deal with. I'm not sure what those issues
would be; constants of class types have been mentioned, but I think
that's a red herring class misunderstanding.

But note that the current standard only allows use of such constants as
pure compile time values (i.e. not taking address), unless you define
the constant outside the class, i.e. in a separately compiled file, e.g. as

int foo::i;

which looks suspiciously like a pure declaration, but is actually a
definition, and what looks like a definition in the class definition, is
actually a pure declaration. Formally. And different compilers differ
in how strictly they interpret the standard, or how they interpret it.

In other words, the whole thing is a kludge, probably tacked on to the
language because of pressure from some sub-group of the committee, and
what was accepted was probably the minimum needed to make 'em shut up.

:)

Now, as device for introducing a named, typed non-integral constant in
the class definition /in a header file/, without any separately compiled
definition, you can alternatively use the templated constant trick,
which as far as I know has only been put forward by me, and not even I
use it -- it's strictly a "yes there is a (painful) way" thing:

#include <iostream>
#include <ostream>

template< typename Dummy > struct FConstant { static float const f; };
template< typename Dummy > float const FConstant<Dummy>::f = 0.02f;

class Foo
: public FConstant<void>
{
// Whatever, here we have foo::f.
};

int main()
{
std::cout << Foo::f << std::endl;
}

Checking that this compiles & works... Yes. So a standard-conforming
C++ compiler has no problem introducing such a constant, it is
/required/ to support this, provided it's supplied with the proper magic
incantation, and as mentioned above, why the committee didn't allow a
more natural and concise way to write that, well, politics, probably...

Enjoy (if u like pain!).

Cheers, & hth.,

- Alf
 
R

Ron Natalie

red said:
Because the Standard says so. I don't know if this has been changed in
the draft 0x standard.
The issue is that the compiler is expectedto know how to execute
const integral expressions at compile time, so the const inline int
makes sense. The compiler is not required to be able to do floating
point at compile time (it may assume that it's too hard to crosscompile).
 
A

Alf P. Steinbach

* Ron Natalie:
The issue is that the compiler is expectedto know how to execute
const integral expressions at compile time, so the const inline int
makes sense. The compiler is not required to be able to do floating
point at compile time (it may assume that it's too hard to crosscompile).

Sorry, while that is relevant it's not a valid reason to forbid the
syntax. It's only a valid reason to forbid the use of e.g. a named
double constant at compile time (e.g. casted to int). As I've shown
else-thread, you can easily achieve the effect of having a constant
float foo::f, so any standard-conforming compiler must support the
effective functionality, just not the sensible syntax: it's explicitly
not allowed to support the sensible /syntax/, so the question is why on
Earth not, and the answer, probably, politics and arbitrary history.

Cheers,

- Alf
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top