Re: initialization of a const static float data member in a class
* James Kanze:
On Jun 14, 4:30 am, "Alf P. Steinbach" <al...@start.no> wrote:
* Ian Collins:
Alf P. Steinbach wrote:
* James Kanze:
I'm just curious, but do you have any examples where being
able to define the initialization in the class definition
(which is definitely a hack) would make some coding
simpler.
I can't see any example where it wouldn't?
One argument I've heard is differences between the
compilation host and target floating point representations.
42 is always 42, but 0.123*12345.678 may not have the same
representation on all hardware.
It's just a specious red herring argument.
Historically, it wasn't. And it wasn't a question of
representation, but actual value: 5*7 is equal to 35 always,
everywhere. The actual value of 1.2*3.4 depends on the floating
point representation, however.
Note that this very definitely was the motivation for not
allowing floating point arguments for templates. Given
something like:
template< double F > class T{} ;
do
T< 1.2*3.4 > t1 ;
T< 4.08 > t2 ;
have the same type or not?
Of course, this argument doesn't really apply to the initializer
of a static member.
Right. It's specious. :-)
Uh, note James, lately I've not had the drive I had earlier to engage in all
sorts of long-winded discussions.
I just make my points and if people don't grok 'em, well I don't any longer feel
any strong compulsion to enlighten them -- let people be idiots, you can't
change them, that's my new motto! :-) But I make exception for you since you're
not in ordinary people (idiot) class, but somewhere at opposite end of scale.
Just, still don't expect me to reply to all.
But historically, C has made a point of not
requiring a cross compiler to implement the target floating
point arithmetic---there is currently no where in the language
where the compiler is required to do floating point arithmetic.
That is irrelevant.
After all, there's nothing preventing us from defining these
constants with the current language.
The language currently does not have the concept of a constant
0.123*12345.678.
I think you mean "compile time constant". Right. And irrelevant. Misleading
though since we're talking about (other) constants and it might seem to apply to
those. It doesn't.
It's just that with current rules it's a load of unnecessary
notation and complication and no guaranteed checking that
you've fulfilled the language's requirements.
Which current rule? That you have to define the variable if you
use it?
Yeah, that one. Plus the one limiting in-class initialization.
G++ certainly gives an error here, even if the variable
has an initializer. (Technically, of course, it is the linker
that gives the error, but error there is.)
It's not required to.
Now I see else-thread that purportedly C++0x will fix this.
Fix what? I have the impression that we are talking about
several different things here. I don't have the very latest
draft here, but from what I can see, all that has changed is
that you can now provide an initializer for any "const literal
type" (whatever that is---I'm guessing that it means a type for
which some literal exists). You still have to provide a
definition somewhere.
Yeah, that's stupid.
To date, as I said, I'm not aware of any proposal to change
this. And I don't feel competent to discuss the pros and cons
of a proposal that doesn't exist---I want to know exactly what
is being proposed, first.
Here's one possible proposal, off the cuff, so not sure if compiles! :-)
The C++xx construction
struct A
{
static double const x = 1*2;
};
is to be treated as (i.e. compiler rewrites as) C++98 valid code
template< typename Dummy >
struct __A_x
{
static double const x;
};
template< typename Dummy >
double const __A_x<Dummy>::x = 1*2;
struct A: __A_x<void>
{
};
where __A_x is some generated globally unique name, and except that if there is
any way of generally detecting whether A has a base class (dunno), then such way
shall not detect the presence of __A_x.
Since the rewritten code is valid C++98 code there's no adjustment of
one-definition-rule: it's still in effect as before, and still rules.
If so, hurray (I haven't noticed that, but then I haven't
scrutinized the draft!) -- and if so, it sort of pulls the
rug under James' argument that
"For most of the members of the committee (and for all of the
other experts I know), [There is no imperative language based
reason to allow [these in-class definition initializations]].
The general feeling is that ideally, you shouldn't be able to
provide the initialization in the class definition at all"
You'll have to explain that one to me. There is no imperative
language based reason.
Yeah. And as mentioned earlier that applies to 'for', 'do' and 'while' as well.
Your argument was that in spite of that, most members of the committee and all
other experts you know had embraced the fallacious argument, so that they would
not be likely to consider anything like reason, but with some support in C++0x
draft, although still keeping separate definition sillyness, that argument has
very little force left it in -- when they can be moved to go most of the way,
perhaps they can be moved to go the teeny tiny little distance left also?
:-)
Of course, there is a huge distance left for the Most General Solution, that of
introducing something akin to 'inline' for /data/. :-) But since we don't
really really need that MGS in practice, no need to waste time convincing.
Cheers,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?