Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   initialization of a const static float data member in a class (http://www.velocityreviews.com/forums/t619877-initialization-of-a-const-static-float-data-member-in-a-class.html)

akomiakov@gmail.com 06-12-2008 02:51 PM

initialization of a const static float data member in a class
 
Is there a technical reason why one can't initialize a cost static non-
integral data member in a class?

Andrey Tarasevich 06-12-2008 07:05 PM

Re: initialization of a const static float data member in a class
 
akomiakov@gmail.com wrote:
> Is there a technical reason why one can't initialize a cost static non-
> integral data member in a class?


Probably not.

Moreover, it should probably be seen the other way around. The bottom
line here is that in C++ normally non-defining declarations can't
include initializers. An exception was made for integral and enum types
only. And the real question here is whether there's a reason for this
exception. The answer is: yes, there is. The exception was made for
constants of integral and enum types in order to allow these constants
to participate in integral constant expressions. For other types there
is no good reason to allow the initialization.

--
Best regards,
Andrey Tarasevich

akomiakov@gmail.com 06-13-2008 08:04 AM

Re: initialization of a const static float data member in a class
 
On Jun 13, 12:05 am, Andrey Tarasevich <andreytarasev...@hotmail.com>
wrote:
> akomia...@gmail.com wrote:
> > Is there a technical reason why one can't initialize a cost static non-
> > integral data member in a class?

>
> Probably not.
>
> Moreover, it should probably be seen the other way around. The bottom
> line here is that in C++ normally non-defining declarations can't
> include initializers. An exception was made for integral and enum types
> only. And the real question here is whether there's a reason for this
> exception. The answer is: yes, there is. The exception was made for
> constants of integral and enum types in order to allow these constants
> to participate in integral constant expressions. For other types there
> is no good reason to allow the initialization.
>
> --
> Best regards,
> Andrey Tarasevich


Thanks a lot.

James Kanze 06-13-2008 11:51 AM

Re: initialization of a const static float data member in a class
 
On Jun 12, 10:16 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * Andrey Tarasevich:


> > The exception was made for
> > constants of integral and enum types in order to allow these constants
> > to participate in integral constant expressions.


> Yes.


> > For other types there
> > is no good reason to allow the initialization.


> Sorry, but that statement is in blatant contradiction of fact.


Yes and no. There is no imperative language based reason to
allow them. Of course, this is at least partially linked to the
fact templates can't have floating point parameters, but the
fact remains that at present, there's nothing at the language
level which you can do with a floating point constant whose
initialization can be seen that you can't also do with one whose
initialization can't be seen.

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. The main
argument I know in favor of it is orthogonality---it's allowed
for integral types, and there doesn't seem to be any really good
reason for not allowing it for floating point. (Given that the
hack is already present, applying it to a few more types doesn't
seem to make a significant difference in the "hackness".)

For that matter, is there any persuasive reason for not allowing
the initialization in the class definition for all static data
members. Obviously, in cases where it implied dynamic
initialization, it would be ignored except where the variable
was actually defined, but if you're going to have a hack, you
might as well be systematic about it.

> The fact is, this functionality is requested again and again
> and again,


By whom? I don't recall having seen any such request (but there
was a long period in which I wasn't that active in
standardization, so I easily could have missed it).

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34

James Kanze 06-13-2008 04:57 PM

Re: initialization of a const static float data member in a class
 
On Jun 13, 6:10 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * James Kanze:
> > On Jun 12, 10:16 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> >> * Andrey Tarasevich:


> >>> The exception was made for
> >>> constants of integral and enum types in order to allow these constants
> >>> to participate in integral constant expressions.


> >> Yes.


> >>> For other types there
> >>> is no good reason to allow the initialization.


> >> Sorry, but that statement is in blatant contradiction of fact.


> > Yes and no. There is no imperative language based reason to
> > allow them. Of course, this is at least partially linked to the
> > fact templates can't have floating point parameters, but the
> > fact remains that at present, there's nothing at the language
> > level which you can do with a floating point constant whose
> > initialization can be seen that you can't also do with one whose
> > initialization can't be seen.


> I'm sorry but that argument doesn't hold water.


For you. For most of the members of the committee (and for all
of the other experts I know), it does. The general feeling is
that ideally, you shouldn't be able to provide the
initialization in the class definition at all---it's an ugly
hack. But there are language imperatives for allowing it for
integral types. (My own opinion is that you either have the
hack, or you don't. Extending it to double, or even all other
types, doesn't seem a problem to me once you've got the hack.
But I don't decide these things anymore than you do.)

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


> Assuming a practical language rule, of course, where the
> current sillyness of having to define the identifier
> separately (outside the class definition) if it's "used", is
> dropped.


OK. That's a major change in the way C++ works. Or at least in
the way it worked before templates. In other words, what you
want is for the declaration of a static class member to be a
definition, and drop the one definition rule on it.

I'm not sure I agree, but it's certainly something worth
considering.

> Note in that respect: using templating trick all the required
> code is in header file, and within current language rules, so
> there's no reason that the compiler can't do that rewrite
> automatically, and check for errors, and so requirement of
> separate definition if "used" is just silly, completely
> redundant.


Oh, I don't have any doubt that its implementable. It would
have caused problems 15 years ago, but as you say, it can just
piggyback on techniques needed for templates anyway.

> [snip]


> >> The fact is, this functionality is requested again and
> >> again and again,


> > By whom? I don't recall having seen any such request (but
> > there was a long period in which I wasn't that active in
> > standardization, so I easily could have missed it).


> I don't know about requests to the standards committee,


Those are the only ones which will actually get acted upon.

> except I know it has been discussed. I think that historically
> (discussing the last year or so would be absurd, nothing new
> is going to make it into C++0x),


I don't know about that. One of the proposals I made in the
last year or so has been accepted (that <iostream> be required
to include <istream> and <ostream>). Admittedly, however, it
was just a request to bring the standard in line with existing
practice.

> with the understanding that there were at least a few
> committee members very much against doing the right thing,
> nobody would take the trouble of wasting time by making a
> formal proposal. Speculating haphazardly, I conjecture that
> any proposal that would make some prominent committee members
> feel that they'd been made to look like fools,


Times change, and many committee members accept today things
they would have rejected in the past. You obviously have to
present it in a polite fashion: it might have been the right
thing in the past, but technology has evolved. (In 1991, when I
started using C++ professionally, implementing your suggestion
of not requiring the additional definition would have been
almost impossible.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique oriente objet/
Beratung in objektorientierter Datenverarbeitung
9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34

Kai-Uwe Bux 06-13-2008 05:07 PM

Re: initialization of a const static float data member in a class
 
James Kanze wrote:

> On Jun 13, 6:10 pm, "Alf P. Steinbach" <al...@start.no> wrote:
>> * James Kanze:
>> > On Jun 12, 10:16 pm, "Alf P. Steinbach" <al...@start.no> wrote:
>> >> * Andrey Tarasevich:

>
>> >>> The exception was made for
>> >>> constants of integral and enum types in order to allow these
>> >>> constants to participate in integral constant expressions.

>
>> >> Yes.

>
>> >>> For other types there
>> >>> is no good reason to allow the initialization.

>
>> >> Sorry, but that statement is in blatant contradiction of fact.

>
>> > Yes and no. There is no imperative language based reason to
>> > allow them. Of course, this is at least partially linked to the
>> > fact templates can't have floating point parameters, but the
>> > fact remains that at present, there's nothing at the language
>> > level which you can do with a floating point constant whose
>> > initialization can be seen that you can't also do with one whose
>> > initialization can't be seen.

>
>> I'm sorry but that argument doesn't hold water.

>
> For you. For most of the members of the committee (and for all
> of the other experts I know), it does. The general feeling is
> that ideally, you shouldn't be able to provide the
> initialization in the class definition at all---it's an ugly
> hack.

[snip]

Actually, I wonder where that assesment comes from. In my coding style (I do
almost exclusively templated code), all code goes into header files. I
rarely ever split declarations from definitions. Being forced to do that
for static const members creates an imbalance in coding style that makes
the non-hack ugly and the hack natural.

I don't think it is a good idea for the standard to legislate style; and for
templated code, the issue is more or less entirely a matter of style.


Best

Kai-Uwe Bux

Ian Collins 06-13-2008 08:58 PM

Re: initialization of a const static float data member in a class
 
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.

--
Ian Collins.

Greg Herlihy 06-13-2008 11:08 PM

Re: initialization of a const static float data member in a class
 
On Jun 13, 10:07*am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> > For you. *For most of the members of the committee (and for all
> > of the other experts I know), it does. *The general feeling is
> > that ideally, you shouldn't be able to provide the
> > initialization in the class definition at all---it's an ugly
> > hack.

>
> [snip]
>
> Actually, I wonder where that assesment comes from. In my coding style (I do
> almost exclusively templated code), all code goes into header files. I
> rarely ever split declarations from definitions. Being forced to do that
> for static const members creates an imbalance in coding style that makes
> the non-hack ugly and the hack natural.
>
> I don't think it is a good idea for the standard to legislate style; and for
> templated code, the issue is more or less entirely a matter of style.


C++09 will allow the in-definition intialization of any static class
member of a "literal" type - including floating point types. After
all, it probably doesn't make much sense to most C++ programmers, that
a floating point constant in a header file is OK outside of a class
definition - but suddenly becomes a problem when moved inside a class
definition:

// header.h

const float kFloatConstant = 1.0f; // OK

class A
{
public:
static float kFloatConstant = 2.0f; // Error - but OK in C++09
};

Greg

Greg Herlihy 06-13-2008 11:14 PM

Re: initialization of a const static float data member in a class
 
On Jun 13, 10:07*am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> James Kanze wrote:.
>
> > For you. *For most of the members of the committee (and for all
> > of the other experts I know), it does. *The general feeling is
> > that ideally, you shouldn't be able to provide the
> > initialization in the class definition at all---it's an ugly
> > hack.

>
> [snip]
>
> Actually, I wonder where that assesment comes from. In my coding style (I do
> almost exclusively templated code), all code goes into header files. I
> rarely ever split declarations from definitions. Being forced to do that
> for static const members creates an imbalance in coding style that makes
> the non-hack ugly and the hack natural.
>
> I don't think it is a good idea for the standard to legislate style; and for
> templated code, the issue is more or less entirely a matter of style.


C++09 will allow the in-definition initialization of any static class
member of a "literal" type - including floating point types. After
all, it probably does not make much sense to most C++ programmers that
a constant floating point variable may be declared in a header file
(outside of a class) - but may not be declared in a header file
(inside of a class):

// header.h

const float kFloatConstant = 1.0f; // OK

class A
{
public:
static const float kFloatConstant = 2.0f; // Error - but OK in C+
+09
}

Greg


Ian Collins 06-14-2008 02:50 AM

Re: initialization of a const static float data member in a class
 
Alf P. Steinbach 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.
>

One case would be a cross-compiler.

> After all, there's nothing preventing us from defining these constants
> with the current language.
>

That's true, but I don't think they are classed as compile time
constants (not that is makes much difference for a floating point value)
where as an integer type is.

A quick check with Sun CC shows "const float ff = 42.0*42.0;" is
calculated at run time with all but the most relaxed architecture and
floating point compiler options.

> 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.
>
> Now I see else-thread that purportedly C++0x will fix this.
>

There is a case for consistency.

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

:)

A always thought the exception for integer types was to remove the
necessity for the old enum hack compile time constant (for an array size
for instance). This was a pain in pre-standard compilers, just as it is
in C today.

It looks like the exception is about to become the rule!

--
Ian Collins.


All times are GMT. The time now is 01:35 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.