static const double pi = 3.1415;

static const double pi = 3.1415;

[Mike Stump]

Ack!  I think this patch is going to screw the 3.3 release:

2002-12-09  Mark Mitchell  <mark@codesourcery.com>

         * NEWS: Document removal of in-class initialization extension 
for
         static data members of non-arithmetic, non-enumeration type.
         * decl.c (check_static_variable_definition): Do not allow that
         extension.
         * decl2.c (grokfield): Do not call digest_init when processing
         templates.

While technically correct, we generally pedwarn such things for a year 
or two or five to let people fix their broken code.  Going straight 
from GNU language feature to error will impact people.  If not pedwarn, 
then -fpermissive.

Thoughts?  I have a patch to do this, if we like the general idea.

Remind me, why was it really important to not let people use doubles?

class A {
   static const double pi = 3.1415;
} a;

This is taken from user code, Finder_FE.  :-(

Re: static const double pi = 3.1415;

[Gabriel Dos Reis]

Mike Stump <mrs@apple.com> writes:

[...]

| Remind me, why was it really important to not let people use doubles?

This is an endless debate and I don't believe we'll have the answer
this time.  However, I would suggest we issue an unconditional pedwarn
for 3.3.0 and remove that extension (was it ever documented?) in the
release after.

| class A {
|    static const double pi = 3.1415;
| } a;
| 
| This is taken from user code, Finder_FE.  :-(

Well, there are lots of broken user codes around :-/

-- Gaby

Re: static const double pi = 3.1415;

[Mark Mitchell]

--On Saturday, February 15, 2003 04:13:24 PM -0800 Mike Stump 
<mrs@apple.com> wrote:

> Thoughts?  I have a patch to do this, if we like the general idea.

I don't believe this was ever a GNU language feature as such; it was never 
documented as an extension to my knowledge.  It was just one of many, many 
places where we allowed more code to compile than we should have.

If people really feel that we need to add this back in, we can do that with 
-fpermissive -- but the only exception we should make is for floating-point 
types, not aggregates, etc.  That latter case cannot really be made to work 
reliably without major work.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: static const double pi = 3.1415;

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

| If people really feel that we need to add this back in, we can do that
| with -fpermissive -- but the only exception we should make is for
| floating-point types, not aggregates, etc.  That latter case cannot
| really be made to work reliably without major work.

I would propose we deprecate it in 3.3 and remove it in 3.4 --
following existing practice.  What do you think?

-- Gaby

Re: static const double pi = 3.1415;

[Mark Mitchell]

--On Tuesday, February 18, 2003 08:39:00 AM +0100 Gabriel Dos Reis 
<gdr@integrable-solutions.net> wrote:

> I would propose we deprecate it in 3.3 and remove it in 3.4 --
> following existing practice.  What do you think?

I assume that by "it" you mean initializing static floating-point data 
members in-class.

I still think that in some sense there's nothing to deprecate; this was a 
very unofficial extension.

Your proposal is OK with me, if there's a good patch for it.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: static const double pi = 3.1415;

[Joe Buck]

On Tue, Feb 18, 2003 at 08:05:24AM -0800, Mark Mitchell wrote:
> I assume that by "it" you mean initializing static floating-point data 
> members in-class.
> 
> I still think that in some sense there's nothing to deprecate; this was a 
> very unofficial extension.

Speaking as someone who used g++ since 1990: initialization of const members
in-class was always there.  ISO C++ picked up the ability to initialize
static integral members in-class from g++, in ARM C++ you had to use an
enum.

Given this very long history I think that it needs to be deprecated
and announced.

Re: static const double pi = 3.1415;

[Phil Edwards]

On Tue, Feb 18, 2003 at 09:44:32AM -0800, Joe Buck wrote:
> On Tue, Feb 18, 2003 at 08:05:24AM -0800, Mark Mitchell wrote:
> > I assume that by "it" you mean initializing static floating-point data 
> > members in-class.
> > 
> > I still think that in some sense there's nothing to deprecate; this was a 
> > very unofficial extension.
> 
> Speaking as someone who used g++ since 1990: initialization of const members
> in-class was always there.  ISO C++ picked up the ability to initialize
> static integral members in-class from g++, in ARM C++ you had to use an
> enum.
> 
> Given this very long history I think that it needs to be deprecated
> and announced.

I agree, but would still like to see -fpermissive allow this.  But I don't
feel strongly about it.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: static const double pi = 3.1415;

[Mark Mitchell]

--On Tuesday, February 18, 2003 02:52:46 PM -0500 Phil Edwards 
<phil@jaj.com> wrote:

>
> I agree, but would still like to see -fpermissive allow this.  But I don't
> feel strongly about it.

OK, Mike, let's see your patch. :-)

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: static const double pi = 3.1415;

[Mike Stump]

[-- Attachment #1: Type: text/plain, Size: 112 bytes --]

On Tuesday, February 18, 2003, at 11:59  AM, Mark Mitchell wrote:
> OK, Mike, let's see your patch. :-)

Sure:


[-- Attachment #2: staticinit.diffs --]
[-- Type: application/octet-stream, Size: 1705 bytes --]

*** decl.c.~1~	Thu Feb 13 18:09:34 2003
--- decl.c	Sat Feb 15 11:10:49 2003
*************** check_static_variable_definition (decl, 
*** 9895,9909 ****
       required.  */
    if (!ARITHMETIC_TYPE_P (type) && TREE_CODE (type) != ENUMERAL_TYPE)
      {
!       error ("invalid in-class initialization of static data member of non-integral type `%T'",
! 	     type);
!       /* If we just return the declaration, crashes will sometimes
! 	 occur.  We therefore return void_type_node, as if this was a
! 	 friend declaration, to cause callers to completely ignore
! 	 this declaration.  */
!       return 1;
      }
!   else if (!CP_TYPE_CONST_P (type))
      error ("ISO C++ forbids in-class initialization of non-const static member `%D'",
  	      decl);
    else if (pedantic && !INTEGRAL_TYPE_P (type))
--- 9900,9931 ----
       required.  */
    if (!ARITHMETIC_TYPE_P (type) && TREE_CODE (type) != ENUMERAL_TYPE)
      {
!       if (CLASS_TYPE_P (type) || TREE_CODE (type) == REFERENCE_TYPE)
! 	{
! 	  error ("invalid in-class initialization of static data member of non-integral type `%T'",
! 		 type);
! 	  /* If we just return the declaration, crashes will sometimes
! 	     occur.  We therefore return void_type_node, as if this was a
! 	     friend declaration, to cause callers to completely ignore
! 	     this declaration.  */
! 	  return 1;
! 	}
!       pedwarn ("invalid in-class initialization of static data member of non-integral type `%T'",
! 	       type);
!       return 0;
      }
!   if (!CP_TYPE_CONST_P (type))
      error ("ISO C++ forbids in-class initialization of non-const static member `%D'",
  	      decl);
    else if (pedantic && !INTEGRAL_TYPE_P (type))
--------------

[-- Attachment #3: Type: text/plain, Size: 216 bytes --]



They need regtesting, but should restore exactly what it did before 
with a pedwarn for it.  I don't have the permissive version, though, it 
should be easy enough to add && ! permissive to the second conditional.

Re: static const double pi = 3.1415;

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| --On Tuesday, February 18, 2003 08:39:00 AM +0100 Gabriel Dos Reis
| <gdr@integrable-solutions.net> wrote:
| 
| > I would propose we deprecate it in 3.3 and remove it in 3.4 --
| > following existing practice.  What do you think?
| 
| I assume that by "it" you mean initializing static floating-point data
| members in-class.

yes, you're right.

| I still think that in some sense there's nothing to deprecate; this
| was a very unofficial extension.

I agree in principle; I'm just trying to find a middle-solution.
Maybe there is none ;-)

-- Gaby

Re: static const double pi = 3.1415;

[Kai Henningsen]

mark@codesourcery.com (Mark Mitchell)  wrote on 17.02.03 in <43620000.1045552786@warlock.codesourcery.com>:

> --On Saturday, February 15, 2003 04:13:24 PM -0800 Mike Stump
> <mrs@apple.com> wrote:
>
> > Thoughts?  I have a patch to do this, if we like the general idea.
>
> I don't believe this was ever a GNU language feature as such; it was never
> documented as an extension to my knowledge.  It was just one of many, many
> places where we allowed more code to compile than we should have.
>
> If people really feel that we need to add this back in, we can do that with
> -fpermissive -- but the only exception we should make is for floating-point
> types, not aggregates, etc.  That latter case cannot really be made to work
> reliably without major work.

Note I'm not arguing for or against any particular extension here.

That said - what would be hard about allowing to initialize PODs with  
constant expressions? Or about any static member variables, for that  
matter - I assume there must be a reason to disallow for what are in  
effect global variables inside a class namespace what is allowed for  
global variables outside a class namespace, but it is certainly not  
obvious to me what reason that would be. (And it's certainly an ugly  
wart.)

MfG Kai

Re: static const double pi = 3.1415;

[Gabriel Dos Reis]

kaih@khms.westfalen.de (Kai Henningsen) writes:

| Note I'm not arguing for or against any particular extension here.
| 
| That said - what would be hard about allowing to initialize PODs with  
| constant expressions?

I don't know how hard it would be.  But I do know for sure that a
couple of bugs on that issue have made their ways into the compiler.
Getting rid of that undocumented extension certainly makes the job of
implementing the language easier.  

Now, if you want that feature, maybe you might come with a detailled
specification -- no, the undocumented extension didn't describe the
semantics.     

what is clear is that integral constant and enumeration are considered
compile-time entities and as such maybe "optimized" away by the
compiler -- that is the main prupose of the standard feature.
However, the picture is less clear when you consider non-compile time
entities.  

-- Gaby

Re: static const double pi = 3.1415;

[Mike Stump]

On Tuesday, February 18, 2003, at 11:33 PM, Gabriel Dos Reis wrote:
> I agree in principle; I'm just trying to find a middle-solution.
> Maybe there is none ;-)

I'd claim the standard is wrong, and we shouldn't be afraid to fix it.  
Isn't the 5year coming up?!  By having real world experience, we do, 
with the extension, we strengthen the case for it.

Personally, I don't find

int i = 1;

to be substantially different from:

double i = 1;

:-(  As far as extensions go, I've seen worse.

Re: static const double pi = 3.1415;

[Gabriel Dos Reis]

Mike Stump <mstump@apple.com> writes:

| On Tuesday, February 18, 2003, at 11:33 PM, Gabriel Dos Reis wrote:
| > I agree in principle; I'm just trying to find a middle-solution.
| > Maybe there is none ;-)
| 
| I'd claim the standard is wrong, and we shouldn't be afraid to fix it.
| Isn't the 5year coming up?!  By having real world experience, we do,
| with the extension, we strengthen the case for it.
| 
| Personally, I don't find
| 
| int i = 1;
| 
| to be substantially different from:
| 
| double i = 1;
| 
| :-(  As far as extensions go, I've seen worse.

Yeah, but I'm not sure that is a convincing argument for this
particular one.

I do not believe that teh issue is just as simple as you're stating.

The in-class initialisation thingy is much subtile (at least I
perceive it as such) that a mere replacement of int with double.

The in-class initialisation is not a definition, it is a conceptual
"#define" but at translation phase 7:  You give a symbolic name to a
manifest (compile-time) constant.  One of the issue is: What does that
mean for something whose semantics have intrincate dependency on the
executing environment?  Well, I'm not sure I would have time to follow
this opening debate.  At any rate, I was just finding an acceptable
path to 3.4 -- this is not a feature I will spend lot of time for and
I feel it would consume time to get "right". 

-- Gaby

Re: static const double pi = 3.1415;

[Nathan Sidwell]

Mike Stump wrote:
> Personally, I don't find
> 
> int i = 1;
> 
> to be substantially different from:
> 
> double i = 1;
> 
> :-(  As far as extensions go, I've seen worse.
> 
you also have to extend the meaning of a constant-expression. [9.4.2] says
that the initializer for a static int member must be a constant integral
expression. To allow float you'd have to define what a constant float
expression is, and that'd mean you'd have to define how to do float
arithmetic at compile time. Not that any of that is insurmountable,
but you need to define it.

Your example 'static double d = 1' doesn't look that different,
until you realise there's an implicit cast, and it is really
'static double d = static_cast <double> (1)'

Simply allowing a double static member, without allowing constant float
expressions would be confusing, as
    static double d1 = 1 * 2; // ok
    static double d2 = 1.0 * 2; // not ok, (huh?)

Hope that helps.

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: static const double pi = 3.1415;

[Mike Stump]

On Wednesday, February 19, 2003, at 08:52 AM, Nathan Sidwell wrote:
> Mike Stump wrote:
>> Personally, I don't find
>> int i = 1;
>> to be substantially different from:
>> double i = 1;
>> :-(  As far as extensions go, I've seen worse.
> you also have to extend the meaning of a constant-expression. [9.4.2]

Seems like I am just too radical for ya'll:

static const double d = 3.1415;

int main() {
         foo(d);
}

I asked my C compiler, it like it, it knew what it meant, it knew how 
to optimize it, it _liked_ it, and until we make that an error...  I 
don't think C++ should be radically different, anyway, I've already 
agreed with Gaby that the better forum is the C++ committee, and I'm 
content to not push the issue here.  I've already yelped, and that's 
all I'm gonna do.

> says
> that the initializer for a static int member must be a constant 
> integral
> expression. To allow float you'd have to define what a constant float
> expression is, and that'd mean you'd have to define how to do float
> arithmetic at compile time. Not that any of that is insurmountable,
> but you need to define it.

The above C program seemed to work in C++ as well.  Either, that is a 
bug in C and C++, or somewhere, it is defined well enough to work.

Re: static const double pi = 3.1415;

[Nathan Sidwell]

Mike Stump wrote:

> Seems like I am just too radical for ya'll:
> 
 > static const double d = 3.1415;
 >
 > int main() {
 >         foo(d);
 > }
 > static const double d = 3.1415;

> The above C program seemed to work in C++ as well.  Either, that is a 
> bug in C and C++, or somewhere, it is defined well enough to work.

We were talking about static *member* constants, not plain static
constants. The latter are well formed (they do not have to be initialized
by a constant expression).

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: static const double pi = 3.1415;

[Nathan Sidwell]

Nathan Sidwell wrote:
> We were talking about static *member* constants, not plain static
> constants. The latter are well formed (they do not have to be initialized
> by a constant expression).
bzzt!
they have to be constant expressions in C, but the constraints are more
relaxed and may be evaluated at runtime (C99 [6.7.8]/4 and [6.6]/2,3,4)

In C++ they can be arbitrary expressions (C++ [8.5]/2)

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: static const double pi = 3.1415;

[Mike Stump]

On Wednesday, February 19, 2003, at 09:25 AM, Nathan Sidwell wrote:
> Mike Stump wrote:
>
>> Seems like I am just too radical for ya'll:
> > static const double d = 3.1415;
> >
> > int main() {
> >         foo(d);
> > }
> > static const double d = 3.1415;
>
>> The above C program seemed to work in C++ as well.  Either, that is a 
>> bug in C and C++, or somewhere, it is defined well enough to work.
>
> We were talking about static *member* constants, not plain static
> constants. The latter are well formed (they do not have to be 
> initialized
> by a constant expression).

I still feel like I am on Mars:

LC0:
         .long   1074340298
         .long   -1065151889

_main:
LFB1:
         mflr r3
         stw r31,-4(r1)
LCFI0:
         bcl 20,31,L1$pb
L1$pb:
         stw r3,8(r1)
LCFI1:
         mflr r31
         stwu r1,-80(r1)
LCFI2:
         addis r2,r31,ha16(LC0-L1$pb)
         lfd f1,lo16(LC0-L1$pb)(r2)
         bl L__Z3food$stub

Like I said, you may not know fine, but my compiler, and the language 
standard, unless you can claim it is a bug in the compiler, they know.

Oh, and by the way if you are correct, that it can be something other 
than a constant, why does the compiler give:

bash-2.05a$ gcc -O3 -S  t.c
t.c:3: initializer element is not constant

in the case of C.

double bar();

static const double d = bar();
void foo(double);
int main() {
         foo(d);
}

is this a bug in the compiler that needs fixing?

Re: static const double pi = 3.1415;

[Mark Mitchell]

--On Tuesday, February 18, 2003 02:07:38 PM -0800 Mike Stump 
<mrs@apple.com> wrote:

> On Tuesday, February 18, 2003, at 11:59  AM, Mark Mitchell wrote:
>> OK, Mike, let's see your patch. :-)
>
> Sure:

I'm not going to get into the language debate, even though I think it's 
interesting; my goal is to get a patch for 3.3 that pedwarns for in-class 
initialization of a floating-point static data member, and that's it. :-)

Mike, I don't quite understand your patch.

First, my version of cc1plus:

  GNU C++ version 3.4 20030218 (experimental) (i686-pc-linux-gnu)

accepts the code in your original email message:

  http://gcc.gnu.org/ml/gcc/2003-02/msg01135.html

namely:

  class A {
    static const double pi = 3.1415;
  } a;

without complaint.  In fact, the NEWS entry for 3.3, specifically says:

  (ISO C++ is even stricter; it does not allow in-class
  initializations of floating-point types.)

which implies that the floating-point extension was left in.  I believe I 
wrote that text, but I can't quite remember.

Second, in your patch you're changing a conditional that is guarded by 
(!ARITHMETIC_TYPE_P (type) && TREE_CODE (type) != ENUMERAL_TYPE) which 
means it won't fire for a floating-point type, since those types are 
arithmetic, but are not enumerations.

I'm confused.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: static const double pi = 3.1415;

[Nathan Sidwell]

Mike Stump wrote:

> I still feel like I am on Mars:
I suspect we have not defined the 'argument' (A sequence of statements ....
  that's not an argument, you're merely contradicting me ...)


> Oh, and by the way if you are correct, that it can be something other 
> than a constant, why does the compiler give:
> 
> bash-2.05a$ gcc -O3 -S  t.c
> t.c:3: initializer element is not constant
> 
> in the case of C.
> 
> double bar();
> 
> static const double d = bar();
1) C and C++ are different in this respect
2) C89 and C99 *might* be different, I only have a C99 spec available.
3) C99 says the initializer must be a constant expression, *but not
necessarily a constant integral expression* C99[6.7.8]/4. A constant
expression shall not contain ... function call C99[6.6]/3. An integral
constant expression 'shall only have the following ... float constants
that are the immediate operands of casts' C99[6.6]/6
4) C++ allows an initializer of a non-member static object to be 'an arbitrary
expression' C++[8.5]/2

Now, it seems from (3) that the compiler must be able to perform
float folding, the whole rationale of (3) appears to restrict initializers
to those things that could be evaluated at compile time. The C++ std
says that integral constant expressions 'shall only contain ...
const variables or static data members of integral or enumeration type
initialized with constant expressions'C++[5.19]/1. So there already
is the restriction that some constant things are not suitable for
a constant expression. Later on there is the further restriction
(the point of your contention, I beleive), that constant static data
members shall only be initialized in class by constant integral
expressions.

That does look superfluous (the restriction on what a static const data member
may be initialized with), and I think there is a strong case
for making it a g++ extension, given the prior art we already have.

Care to file a Defect Report? (Maybe there already is one)

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: static const double pi = 3.1415;

[Mike Stump]

On Thursday, February 20, 2003, at 02:55 AM, Nathan Sidwell wrote:
>> I still feel like I am on Mars:
> I suspect we have not defined the 'argument' (A sequence of statements 
>  that's not an argument, you're merely contradicting me ...)

I don't want to argue...  I just wanted to get across the point that 
for:

double bar();

static const double d = 3.1415;

void foo(double);
int main() {
         foo(d);
}

a compiler of C is must understand and translate this, and that for C++ 
a compiler must understand and translate this, and that the compiler is 
free to generate the same code for it, if it wants to.

Using the those well defined semantics, whatever they are, and however 
they are defined for each language, I want to argue that whether or not 
we accept static const double d = 3.1415 in a class as a member, is 
arbitrary and not based upon the `gosh, it is just too complex', or 
some other argument based upon floating point being qualitatively 
different from int or enums.  That being said, a restriction against 
floating point in this context is arbitrary (and wrong).

> Care to file a Defect Report? (Maybe there already is one)

Wish I felt like I had the time...  Maybe I can get Matt to do the 
dirty work...  :-)

Re: static const double pi = 3.1415;

[Mike Stump]

On Wednesday, February 19, 2003, at 10:14 AM, Mark Mitchell wrote:
>> On Tuesday, February 18, 2003, at 11:59  AM, Mark Mitchell wrote:
>>> OK, Mike, let's see your patch. :-)

I'm sorry, I think I confused two different things, though, I don't 
quite know how I did that.

The real code was:

class A {
	static const char *name = "hi";
} a;

which has all the same arguments as float, though, float is allowed, as 
you point out.  -pedantic-errors kills the ability to use 3.1415 as a 
value of pi, one must use 3 as the approximation of pi to make it 
compile.  :-(  In some fields that's fine, but in general, this is bad.

ANSI C++ should be fixed to allow 3.1415, we should allow it by 
default, and we do, so no change is necessary for it.

g++ should just pedwarn for static const char *, as it is a good 
extention, g++ has had it forever, and eventually we will fix the 
Standard to allow it.  My patch adds this pedwarn for it.  Strict 
conformance is retained, and an error is produced, if people want it 
that way (via -pedantic-errors).

Hope that clarifies it.

Re: static const double pi = 3.1415;

[Mark Mitchell]

--On Thursday, February 20, 2003 12:20:30 PM -0800 Mike Stump 
<mstump@apple.com> wrote:

> Hope that clarifies it.

Yes, that clarifies it.  Your patch is still incorrect in that it allow 
initializations of things that are not "const", unless I read it wrong. 
You simply return 0, which means you miss the other tests in that function.

In addition, I think we even less want to allow initializations for 
pointers.  The point is that the expressions allowed as initializers are 
extremely restricted because there is no definition of the static data 
member yet.  Until that happens -- outside the class-specifier -- you don't 
really have a good place to perform any complex computation.  The whole 
point of constant-expression is to provide a specification of what *must* 
be computed by the compiler at compile-time.

I'll accept this patch for 3.3, if you address the "const" issue, as a 
gradual transition, but I will argue very strongly against it for 3.4.

Go convince the committee first, then I'll be totally agreeable.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: static const double pi = 3.1415;

[Kai Henningsen]

gdr@integrable-solutions.net (Gabriel Dos Reis)  wrote on 19.02.03 in <m3d6lo904k.fsf@uniton.integrable-solutions.net>:

> kaih@khms.westfalen.de (Kai Henningsen) writes:
>
> | Note I'm not arguing for or against any particular extension here.
> |
> | That said - what would be hard about allowing to initialize PODs with
> | constant expressions?
>
> I don't know how hard it would be.  But I do know for sure that a
> couple of bugs on that issue have made their ways into the compiler.
> Getting rid of that undocumented extension certainly makes the job of
> implementing the language easier.
>
> Now, if you want that feature,

Note my first sentence above.

> maybe you might come with a detailled
> specification -- no, the undocumented extension didn't describe the
> semantics.
>
> what is clear is that integral constant and enumeration are considered
> compile-time entities and as such maybe "optimized" away by the
> compiler -- that is the main prupose of the standard feature.
> However, the picture is less clear when you consider non-compile time
> entities.

Frankly, that answer doesn't make sense to me.

Let me try to put the question differently.

Exhibit 1:

static sometype = someexpression;

Exhibit 2:

class foo {

static sometype = someexpression;

[...]
};

What is the justification for putting stronger requirements on the Exhibit  
2 case than on the Exhibit 1 case? (That is, why does the standard make a  
difference here?)

That is what is unobvious.

As for a detailed specification: "Handle Exhibit 2 exactly like Exhibit 1,  
except for namespace issues." That would certainly follow the principle of  
least surprise. What is hard about that?

I can't decide to prefer one version over the other until I know why there  
is a difference in the first place. Maybe there is a good reason - but  
until now, I haven't seen any argument that doesn't seem to be restricted  
to "the standard says so". Well duh, we already know that. It doesn't  
answer the question - it *causes* the question.

MfG Kai

Re: static const double pi = 3.1415;

[Gabriel Dos Reis]

kaih@khms.westfalen.de (Kai Henningsen) writes:

| Frankly, that answer doesn't make sense to me.

Well, I don't have the time to make an involved issue an obvious thing.

-- Gaby

Re: static const double pi = 3.1415;

[Olivier Galibert]

On Thu, Feb 20, 2003 at 10:25:00PM +0200, Kai Henningsen wrote:
> Exhibit 1:
> 
> static sometype = someexpression;
> 
> Exhibit 2:
> 
> class foo {
> 
> static sometype = someexpression;
> 
> [...]
> };
> 
> What is the justification for putting stronger requirements on the Exhibit  
> 2 case than on the Exhibit 1 case? (That is, why does the standard make a  
> difference here?)


A.h:
static double x;

struct A {
  static double y;
};

A.cc:
#include "A.h"

double A::y;

b1.cc:
#include "A.h"
double *b1x() { return &x; }
double *b1y() { return &a::y; }

b2.cc:
#include "A.h"
double *b2x() { return &x; }
double *b2y() { return &a::y; }

main.cc:
#include <stdlib.h>
extern double *b1x(), *b1y(), *b2x(), *b2y();

int main()
{
  assert(b1x() != b2x());
  assert(b1y() == b2y());
  return 0;
}


Modulo typos, this program should work. "const" makes zero difference.

  OG.