Thread overview
Bug: dmc doesn't like static const double
Aug 31, 2007
Sz. Horvát
Aug 31, 2007
Anton Sekeris
Aug 31, 2007
Sz. Horvát
Aug 31, 2007
Sz. Horvát
Sep 01, 2007
Anton Sekeris
Aug 31, 2007
Walter Bright
Sep 01, 2007
Jan Knepper
August 31, 2007
The following code gives an error in spite of c being const.

class A {
	static const double c = 1.0;
};


        static const double c = 1.0;
                              ^
te.cpp(5) : Error: initializer for non-const static member must be outside of class def
--- errorlevel 1
August 31, 2007
I've fallen into this trap as well on more than one occasion, but actually DMC is just following the standard here (you will see similar behaviour using compilers with the EDG front-end). You can only do what you are trying to do for integral or enumeration types.

9.4.2 Static data members [class.static.data] - item 4 says:

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 (5.19). In that case, the member can appear in integral constant expressions. 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.

Sz. Horvát wrote:
> The following code gives an error in spite of c being const.
> 
> class A {
>     static const double c = 1.0;
> };
> 
> 
>         static const double c = 1.0;
>                               ^
> te.cpp(5) : Error: initializer for non-const static member must be outside of class def
> --- errorlevel 1
August 31, 2007
Anton Sekeris wrote:
> I've fallen into this trap as well on more than one occasion, but actually DMC is just following the standard here (you will see similar behaviour using compilers with the EDG front-end). You can only do what you are trying to do for integral or enumeration types.
> 
> 9.4.2 Static data members [class.static.data] - item 4 says:
> 
> 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 (5.19). In that case, the member can appear in integral constant expressions. 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.

Hm ... you are right.  http://www.comeaucomputing.com/tryitout/ gives an error too.  But I really cannot see the reason for not allowing this, it just makes one's life more difficult ... did the people writing the standard simply forget about floating point types?

And DMC's error message is a little bit confusing (telling me that const double is not const).
August 31, 2007
>> In that case, the member can appear in integral constant
>> expressions.
>
> But I really cannot see the reason for not allowing this,

OK, so should I think about this as a special exception, allowed only to make things similar to the following code possible?

class A {
    static const int len = 3;
    int a[len];
};

But there is no special reason to allow doing the same with float or double (except maybe convenience? ...)
August 31, 2007
Sz. Horvát wrote:
> But I really cannot see the reason for not allowing this, it just makes one's life more difficult ... did the people writing the standard simply forget about floating point types?

Ours is not to reason why, but to implement the Standard or cry. <g>
September 01, 2007

Sz. Horvát wrote:
>  >> In that case, the member can appear in integral constant
>>> expressions.
>  >
>  > But I really cannot see the reason for not allowing this,
> 
> OK, so should I think about this as a special exception, allowed only to make things similar to the following code possible?
> 
> class A {
>     static const int len = 3;
>     int a[len];
> };
> 
> But there is no special reason to allow doing the same with float or double (except maybe convenience? ...)

I haven't a clue what the reason was for skipping non-integral built-in types, but your theory sounds quite plausible. From what I've seen in the past these types of standard strangeness are also rather often related to backwards compatibility with C, although in this scenario I don't readily see that.
September 01, 2007
Sz. Horvát wrote:
> The following code gives an error in spite of c being const.
> 
> class A {
>     static const double c = 1.0;
> };
> 
> 
>         static const double c = 1.0;
>                               ^
> te.cpp(5) : Error: initializer for non-const static member must be outside of class def
> --- errorlevel 1

h/hpp:

class  A
{
   static const double   c;
};

cpp:

const double       A :: c = 1.0;



-- 
ManiaC++
Jan Knepper

www.janknepper.com

But as for me and my household, we shall use Mozilla...
www.mozilla.org
Get legal - Get OpenOffice.org www.openoffice.org