Re: 19980824 bugs in initializing static const members

["Reid M. Pinchback" <reidmp at MIT dot EDU>]

At 07:31 PM 8/27/98 -0300, you wrote:
>Reid M Pinchback <reidmp@MIT.EDU> writes:
>
>> I'm using 19980824 on a alpha-dec-osf4.0d, ran into what appears
>> to be some bugs related to the handling of initialization in
>> static const data members.  Experts on the standard may determine
>> some of this to be ok behaviour, even if it evidences itself
>> in egcs in less-than-verbose ways.
>
>According to the standard, member variable can only be initialized
>inside the class body if it is of const integral or const enumeration
>type, and it is initialized with a constant value [class.mem]/4,
>[class.static.data]/4
>
>However, even in this case, the data member must be defined outside
>the class body [class.static.data]/2.  Your code is lacking it, so
>whenever you refer to the symbol, a link-time error should occur.  

Thanks for the clarification!  I think that leaves one open issue.

Based on your information we now see that the cases A and A+X
are probably (definitely? see below) correct compiler behaviour;
they yield the compile-time error that the initializer isn't 
constant.  Shouldn't the cases A+Y and A+X+Y *also* yield the 
exact same compile-time error?

In other words, if the static initialization was invalid for a class 
and that was detected by the compiler, shouldn't the static 
initialization for a templated class by detected by the compiler when
that template is instantiated?  I understand now why there was a link 
error; I just don't understand why the templated class results in a 
link error but the non-templated class results in a compile-time error.
Shouldn't the process of abstracting a class into template be an
invertable function with respect to instantiation?

The link error implies (correctly or incorrectly, depending on the
circumstance?) that the "problem" can be solved by having something
laying around to link to.  That makes me wonder if there is a way
to twist this example into something uglier where you end up
accidentally linking to things you didn't intend to link to
(because you didn't intend to link to anything in the first place).
 
I admit this is definitely a fringe case; I wouldn't exactly hold up
the next egcs release over it.
  
 
====================================================
= Reid M. Pinchback                                =
= I/T Delivery, MIT                                =
=                                                  =
= Email:   reidmp@mit.edu                          =
= URL:     http://web.mit.edu/reidmp/www/home.html =
====================================================