"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
news:ygR5MuBJhEr+Ew80@robinton.demon.co.uk
> In article <8TOqa.7512$b71.112118@news4.e.nsc.no>, Espen Ruud Schultz
> <default@nospam.invalid> writes
>> You have misunderstood completely.  Of course speed is important, but
>> initializing different types of static consts in class scope won't give
>> anyone speed, it gives me control and an easy code.  And that's what I
>> want. I want the control of using consts in a class instead of macros.
>> I want the easy code I get from initializing a static const instead of
>> using the initializer list.
>
> Please go and find out how class statics are intialised. The initialiser
> has nothing to do with it.

Well of course the initializer list has nothing to do with statics.  I'm
talking about that I have to use the initializer list ( or macros ) on const
types becasue I can _not_ use statics.  And that I would rather use static
consts instead of the initializer list, or a list of macros...

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> I see the initializer list as a mean for initializing constants that
aren't
> set, but are given throught the constructor.  Or for single, standalone
> constants, not for a large list of constants where their values are know
at
> compile time and will never ever change.
>
> And on top of this, constants in the initializer list can't always be
> optimized, so they get a place on the stack.  This is especially the case
> for static libraries...

you are confusing const and static const.

const members are initialized in the initializer list in the ctor:

MyClass::MyClass() : myConst(1000) {}

static const are initialized separately:

int MyClass::myConst = 1000;

there is no need for saving them on a stack or the data-segment.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu
[noncommercial and no fucking ads]


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <JSbra.7836$b71.118002@news4.e.nsc.no>, Espen Ruud Schultz
<default@nospam.invalid> writes
>Well of course the initializer list has nothing to do with statics.  I'm
>talking about that I have to use the initializer list ( or macros ) on const
>types becasue I can _not_ use statics.  And that I would rather use static
>consts instead of the initializer list, or a list of macros...

Sorry, but you have completely lost me. Obviously it is a failure in my
imagination because I cannot see how using an initialiser list to
initialise a const member has anything to do with being/not being able
to use a static const.

Nowhere is there a prohibition on using static consts of any type you
like. As class definitions are composed of pure declarations of members
(except for inline member functions defined in class) members must be
defined elsewhere if they are used. This applies just as much to class
statics as to other members. It is at the point of definition that you
have to provide an initialiser for a static const member UNLESS you have
used the special dispensation for static consts of an integer type that
allows an initialiser to be provided in class. In that circumstance you
must NOT intialise the variable at the point of definition.

Now please post a code example to illustrate the point you are trying to
make.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 29 Apr 2003 05:53:03 +0000 (UTC), default@nospam.invalid
("Espen Ruud Schultz") wrote:

>"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
>news:ygR5MuBJhEr+Ew80@robinton.demon.co.uk
>>
>> Please go and find out how class statics are intialised. The initialiser
>> has nothing to do with it.
>
>Well of course the initializer list has nothing to do with statics.  I'm
>talking about that I have to use the initializer list ( or macros ) on const
>types becasue I can _not_ use statics.  And that I would rather use static
>consts instead of the initializer list, or a list of macros...

Please explain why you can't use this:

// myclass.h
// ...

class Math {
public:
  static const float pi;
// ...
};

// end myclass.h

// myclass.cpp
#include "myclass.h"

static const float Math::pi = 3.14;

// end myclass.cpp

>
>, Espen
>
Bart v Ingen Schenau

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Randy Maddox" <rmaddox@isicns.com> wrote in message
news:8c8b368d.0304250451.74aab3b@posting.google.com
> default@nospam.invalid ("Espen Ruud Schultz") wrote in message
> news:<W2_pa.6875$b71.103812@news4.e.nsc.no>...
>> "Randy Maddox" <rmaddox@isicns.com> wrote in message
>> news:8c8b368d.0304240510.14b8c4f7@posting.google.com
>>>
>>> Integers, floating point, and character strings are not quite the same
>>> in terms of when they are initialized or where they are stored.  A
>>> const integer value, and possibly, depending on the architecture, a
>>> const floating point value, can be a compile time constant whose value
>>> is inserted into the code segment where it is used.  Of course, if you
>>> take the address of such a constant, then it will almost certainly
>>> need to be stored in the data segment instead.  Pointers into the code
>>> segment are rather frowned upon, and we never write self-modifying
>>> code anymore ...
>>>
>
> C++ never prevents you from shooting yourself in the foot if you
> really want to.  Using a C-style cast to throw away the constness of
> Class.MyArraySize and stuff a troublesome value there is undefined
> behavior anyway, so whatever happens after that point is your own
> lookout.
>

I was just trying to point out what actually would happen if you did "take
an address of such a constant".  And Allan W is right, it is undifined.
What happened on my system was that I got two versions of one constant.  I'm
not even sure how we got this far though, but it seems like we're off the
original topic...

>>>
>>> A character string, like any other array, const or not, requires
>>> storage in the data segment, and is initialized at run time rather
>>> than being a compile time constant.  This makes sense since the name
>>> of an array is in effect a pointer to its first element, so whenever
>>> you declare an array you have in effect taken the address of its
>>> storage.
>>>
>>
>> Excuse my language, but this is bullshit, a compiler can and will
>> optimize
>> character strings, const or not, static or not, as the compiler see fit.
>> And, as static const ints in class scope, my guess is that the compiler
>> would explicitly optimize a static const char in class scope in the same
>> manner.
>>
>> PS:  I'm not sure what the standard say about explicitly optimizing.
>> But
>> running the above code in the VC++ 7 compiler gives strong indications
>> that
>> this is exactly what's happening...
>>
>
> Not sure what you're disagreeing with here, but if you will take a
> look at the generated code, and the dissasembled code of your vendor
> supplied runtime startup code, you will see that I am correct about
> arrays being stored in the data segment.  If you are trying to say
> that a character string is not an array, then you are simply mistaken.
>  And if you are saying that a const int and a const array can both be
> stored in the code segment, then you are again simply mistaken.
>

Sorry about that, it seems like you're right.  I think I have turned
character string optimizing upside down.  It is actually more optimized by
not optimizing it.  But this still doesn't make any sence why you brought
this up against static const char.

>
> I'm a bit surprised that the moderators let your rude comment through.
>  I had thought that the level of discourse in this newsgroup was just
> a tad higher than that.
>

The comment ( or one word ) might be rude, but it wasn't an attack on your
person.  It was my opinion on one of your posts.  And the fact that this
topic is more spaghetti than a basic code just make me frustrated.  I did,
however, regret using the word bullshit after I posted it...

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Espen Ruud Schultz" <default@nospam.invalid> schrieb in im Newsbeitrag:
gZaqa.6982$8g5.101481@news2.e.nsc.no...
> Yeah, that's what I said in the first post about this "problem".  The
class
> where I tried this is linked multiple times with my program.  So to make
> this work, the user of the class will have to initialize these static
> consts, and that is unacceptable.  Pluss, that doing it this way will most
> sertainly give these static const their own place on the stack and not be
> optimized, which is the primary effect I'm after...

I think a static const will almost certainly not be placed on the stack, but
somewhere within the data segment. However, I still don't see why this
should make the programme run slower than if you were allowed to initialize
the variable at the point of declaration (within the class). As other people
have pointed out, a character string is an array that needs to be stored
somewhere, no matter where it is initialized.

I'm really getting curious what kind of application you are writing that
requires such intense an optimazation - are you sure that this is really
necessary in your case? If your programme is running slow, than it would be
interesting to profile it first - your application might be slowed down at a
totally different place in your code.

And if you really insist on the speed, then why don't you just define a
string outside the class, like

const char * const MY_SPEEDY_STRING = "Now it's fast and I am happy!";

Of course the string is now at global scope, but at least it let's you try
out wether it really makes your programme run faster. It wouldn't surprise
me if there were no difference in speed.




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Matthias Hofmann"" <hofmann@anvil-soft.com> wrote in message
news:3eaa6cf6@news.nefonline.de
> "Espen Ruud Schultz" <default@nospam.invalid> schrieb in im Newsbeitrag:
> gZaqa.6982$8g5.101481@news2.e.nsc.no...
>> Yeah, that's what I said in the first post about this "problem".  The
>> class where I tried this is linked multiple times with my program.  So
>> to make this work, the user of the class will have to initialize these
>> static consts, and that is unacceptable.  Pluss, that doing it this way
>> will most sertainly give these static const their own place on the
>> stack and not be optimized, which is the primary effect I'm after...
>
> I think a static const will almost certainly not be placed on the stack,
> but somewhere within the data segment. However, I still don't see why
> this should make the programme run slower than if you were allowed to
> initialize the variable at the point of declaration (within the class).
> As other people have pointed out, a character string is an array that
> needs to be stored somewhere, no matter where it is initialized.
>
> I'm really getting curious what kind of application you are writing that
> requires such intense an optimazation - are you sure that this is really
> necessary in your case? If your programme is running slow, than it would
> be interesting to profile it first - your application might be slowed
> down at a totally different place in your code.
>
> And if you really insist on the speed, then why don't you just define a
> string outside the class, like
>
> const char * const MY_SPEEDY_STRING = "Now it's fast and I am happy!";
>
> Of course the string is now at global scope, but at least it let's you
> try out wether it really makes your programme run faster. It wouldn't
> surprise me if there were no difference in speed.
>

You have misunderstood completely.  Of course speed is important, but
initializing different types of static consts in class scope won't give
anyone speed, it gives me control and an easy code.  And that's what I want.
I want the control of using consts in a class instead of macros.  I want the
easy code I get from initializing a static const instead of using the
initializer list.

I see the initializer list as a mean for initializing constants that aren't
set, but are given throught the constructor.  Or for single, standalone
constants, not for a large list of constants where their values are know at
compile time and will never ever change.

And on top of this, constants in the initializer list can't always be
optimized, so they get a place on the stack.  This is especially the case
for static libraries...

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <8TOqa.7512$b71.112118@news4.e.nsc.no>, Espen Ruud Schultz
<default@nospam.invalid> writes
>You have misunderstood completely.  Of course speed is important, but
>initializing different types of static consts in class scope won't give
>anyone speed, it gives me control and an easy code.  And that's what I want.
>I want the control of using consts in a class instead of macros.  I want the
>easy code I get from initializing a static const instead of using the
>initializer list.

Please go and find out how class statics are intialised. The initialiser
has nothing to do with it.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

default@nospam.invalid ("Espen Ruud Schultz") wrote in message news:<K2Apa.6431$b71.97388@news4.e.nsc.no>...
> "Allan W" <allan_w@my-dejanews.com> wrote in message
> news:7f2735a5.0304221619.50a7bff@posting.google.com
> >
> > This is a standards newsgroup. People have given him good reasons
> > why a certain part of the standard works the way it does. His reply
> > was, in effect, "we should have changed it anyway. There would have
> > been consequences, but I'm cool with it."
> >
>
> You didn't read my part where I said that's exactly how it is with static
> const integers did you?  Because, as proven, static const int is error
> prone, but the standard says it's there, so people just have to be "cool"
> with it to use it.  Wouldn't be any different with floats or chars either -
> if they were allowed...

Your "proof" re static const int kind of lost me.  Perhaps you could
explain that again a bit more clearly?

>
> Integers, floating point, and character strings are all relatively the same
> when it comes down to this.  So in a very childish way I could say:  Since
> we have static const ints, then why not floats and chars?  In some cases
> they would make life easier, just as static const ints makes life easier
> now.  Of course they will "work against" what people think about
> initializing anything in class scope, but the ints are already far down that
> alley.  So why not just send floats and chars to join the ints?  I know it
> will make my life easier...
>
> , Espen
>

Integers, floating point, and character strings are not quite the same
in terms of when they are initialized or where they are stored.  A
const integer value, and possibly, depending on the architecture, a
const floating point value, can be a compile time constant whose value
is inserted into the code segment where it is used.  Of course, if you
take the address of such a constant, then it will almost certainly
need to be stored in the data segment instead.  Pointers into the code
segment are rather frowned upon, and we never write self-modifying
code anymore ...

A character string, like any other array, const or not, requires
storage in the data segment, and is initialized at run time rather
than being a compile time constant.  This makes sense since the name
of an array is in effect a pointer to its first element, so whenever
you declare an array you have in effect taken the address of its
storage.

Things that are different cannot always be treated the same.  :-)

Randy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:GJTkmufK1ap+EwIG@robinton.demon.co.uk
> In article <VYbpa.6002$b71.91433@news4.e.nsc.no>, Espen Ruud Schultz
> <default@nospam.invalid> writes
>> Talking about choosing the better of two evils:  I would say
>> initializing a huge list of floats through the initializer list is one
>> big evil.  And I would choose the lesser evil, static const float, any
>> day over an unreadable initializer list or a list of macros.  Maybe you
>> don't agree about this thought?
>
>
> But I would not do that. I would do what the standard requires and
> initialise static consts at the point of definition.

This is the reason why I keep posting here.  It doesn't seem like you
understand what I'm saying.  No offence, but I've had to ask myself "What is
he replying to?" on a few of your replies to my posts.

About your reply to this post:  So you're saying that you would do what the
standard requires and initialize a static const float at the point of
definition?  This is what I ment, and are arguing for, becasue the standard
does not allow this...

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Espen Ruud Schultz" <default@nospam.invalid> wrote...
> [...] So you're saying that you would do what the
> standard requires and initialize a static const float at the point of
> definition?  This is what I ment, and are arguing for, becasue the
standard
> does not allow this...


Forgive me for barging in, but you seem to be confusing the terms
"declaration" and "definition".  Static data members in a class
definition are _declared_.  The _definition_ for those members
must be placed _outside_ the class [definition], at the _namespace_
level:

    class X {
        static const float whatever; // declaration
    };
    ...
    const float X::whatever; // definition

There is no _definition_ for static data members _inside_ the
class [definition].  Plain and simple.  Static integral consts
are allowed to be _initialised_ where they are _declared_.  Not
floats, not aggregates, only integrals, and only because they
may be used instead of enums for _declaring_ other things, like
arrays sizes.  Had there been no static consts initialised at
a wrong place (at the point of _declaration_), there would be
no confusion and no argument.  Everybody would be using enums,
and be happy.  No, somebody needed to allow that strange form,
initialisation at the point of _declaration_.  Why?  Because the
use of enums looked bad.  Oh well...

Victor
--
Please remove capital A's from my address when replying by mail


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.de (James Kanze) wrote
> allan_w@my-dejanews.com (Allan W) wrote in message
> > The language C++ was around before the standard. One of the tasks of
> > the C++ standard (the major one?) was to document existing
> > practice. When existing practice differed, the standard was supposed
> > to select one for all to follow.
>
> > In this light, perhaps you would like to rephrase your sentiment?
>
> Given the presence of two-phase lookup, export and member templates,
> new-style casts, RTTI, for-scope, the STL, std::locale, templated
> iostream's, etc., none of which existed before the standard defined it,
> perhaps you would care to rephrase YOUR sentiment.  A language called
> C++ was around before the standard, and is still around today to a large
> extent, but this language bears only a passing resemblance to standard
> C++.  Your statement corresponds to what a standard SHOULD do (IMHO),
> but not to what the C++ standard actually did.

Thanks, but no.

Note that I never said this was the committee's only task, just that it
was the major one.

>     The general consensus was that there is no point in adopting
>     something that can't, or won't be implemented.

That's another biggie.

> Don't forget: if once the feature is actually implemented and used, it
> turns out that allowing more would be nice, and pose no problems, it is
> easy to do.  Whereas if you allow a lot, and it later turns out that
> allowing it does cause problems, you really can't go back and take it
> out.  For the moment, I've yet to see any real arguments to the effect
> that we need support for floating point, but if someone does present
> some, there would be no problem adding it in the future; adding it can't
> break any existing code.  Where as if we had allowed floating point, and
> experience showed that there were problems with it (which, from what I
> know about floating point seems likely), it would be impossible to take
> it out.

This same principle is useful in designing interfaces (for instance,
public class members). This is not a coincidence.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Randy Maddox" <rmaddox@isicns.com> wrote in message
news:8c8b368d.0304240510.14b8c4f7@posting.google.com
> default@nospam.invalid ("Espen Ruud Schultz") wrote in message
> news:<K2Apa.6431$b71.97388@news4.e.nsc.no>...
>> "Allan W" <allan_w@my-dejanews.com> wrote in message
>> news:7f2735a5.0304221619.50a7bff@posting.google.com
>>>
>>> This is a standards newsgroup. People have given him good reasons
>>> why a certain part of the standard works the way it does. His reply
>>> was, in effect, "we should have changed it anyway. There would have
>>> been consequences, but I'm cool with it."
>>>
>>
>> You didn't read my part where I said that's exactly how it is with
>> static
>> const integers did you?  Because, as proven, static const int is error
>> prone, but the standard says it's there, so people just have to be
>> "cool"
>> with it to use it.  Wouldn't be any different with floats or chars
>> either -
>> if they were allowed...
>
> Your "proof" re static const int kind of lost me.  Perhaps you could
> explain that again a bit more clearly?
>

Well, as proven in another post under this discussion somewhere; you can
initialize a static const int with a function call.  And that was a big
error, because the static const int was 0 no matter what the function
returned...

>>
>> Integers, floating point, and character strings are all relatively the
>> same
>> when it comes down to this.  So in a very childish way I could say:
>> Since
>> we have static const ints, then why not floats and chars?  In some cases
>> they would make life easier, just as static const ints makes life easier
>> now.  Of course they will "work against" what people think about
>> initializing anything in class scope, but the ints are already far down
>> that
>> alley.  So why not just send floats and chars to join the ints?  I know
>> it
>> will make my life easier...
>>
>
> Integers, floating point, and character strings are not quite the same
> in terms of when they are initialized or where they are stored.  A
> const integer value, and possibly, depending on the architecture, a
> const floating point value, can be a compile time constant whose value
> is inserted into the code segment where it is used.  Of course, if you
> take the address of such a constant, then it will almost certainly
> need to be stored in the data segment instead.  Pointers into the code
> segment are rather frowned upon, and we never write self-modifying
> code anymore ...
>

Actually, look at the code below.  I tried it a few days ago just to see.
And guess what?  It's just another proof that static const ints are error
prone, and that they are no less error prone than any other type if allowed
in class scope...

struct MyClass {
   static const int MyArraySize = 10;
   int MyArray[MyArraySize];
} Class;

int main( void ) {
   int *MyPnt;
   MyPnt = (int*)&Class.MyArraySize;
   *MyPnt = 20;
   for( int Runner = 0; Runner < Class.MyArraySize; Runner++ ) {
      Class.MyArray[ Runner ] = Runner;
   }
   return 0;
}

>
> A character string, like any other array, const or not, requires
> storage in the data segment, and is initialized at run time rather
> than being a compile time constant.  This makes sense since the name
> of an array is in effect a pointer to its first element, so whenever
> you declare an array you have in effect taken the address of its
> storage.
>

Excuse my language, but this is bullshit, a compiler can and will optimize
character strings, const or not, static or not, as the compiler see fit.
And, as static const ints in class scope, my guess is that the compiler
would explicitly optimize a static const char in class scope in the same
manner.

PS:  I'm not sure what the standard say about explicitly optimizing.  But
running the above code in the VC++ 7 compiler gives strong indications that
this is exactly what's happening...

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Victor Bazarov"" <v.Abazarov@attAbi.com> wrote in message
news:vageg0hbf1iva8@corp.supernews.com
> "Espen Ruud Schultz" <default@nospam.invalid> wrote...
>> [...] So you're saying that you would do what the
>> standard requires and initialize a static const float at the point of
>> definition?  This is what I ment, and are arguing for, becasue the
>> standard does not allow this...
>
>
> Forgive me for barging in, but you seem to be confusing the terms
> "declaration" and "definition".  Static data members in a class
> definition are _declared_.  The _definition_ for those members
> must be placed _outside_ the class [definition], at the _namespace_
> level:
>
>     class X {
>         static const float whatever; // declaration
>     };
>     ...
>     const float X::whatever; // definition
>
> There is no _definition_ for static data members _inside_ the
> class [definition].  Plain and simple.  Static integral consts
> are allowed to be _initialised_ where they are _declared_.  Not
> floats, not aggregates, only integrals, and only because they
> may be used instead of enums for _declaring_ other things, like
> arrays sizes.  Had there been no static consts initialised at
> a wrong place (at the point of _declaration_), there would be
> no confusion and no argument.  Everybody would be using enums,
> and be happy.  No, somebody needed to allow that strange form,
> initialisation at the point of _declaration_.  Why?  Because the
> use of enums looked bad.  Oh well...
>

First.  When I tried it this way, the linker chocked on me.  I posted this
incident in an earlier post, and you can read all about it there.

Second.  To make it past the linker I have to alter the code is such a way
that there is now way the compiler can optimize the code.  And this is the
very thing I want to achieve with other types in class scope...

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 23 Apr 2003 13:53:19 +0000, James Kanze wrote:

> allan_w@my-dejanews.com (Allan W) wrote in message
> news:<7f2735a5.0304211217.678df461@posting.google.com>...
>> > | Espen Ruud Schultz wrote
>> > | > I have thought about this for a while.  And I can not see why
>> > | > only integrals can be const statics inside a class or a struct.
>> > | > Why not floating point numbers or character strings?
>
>
> (...good stuff deleted...)
> Don't forget: if once the feature is actually implemented and used, it
> turns out that allowing more would be nice, and pose no problems, it is
> easy to do.  Whereas if you allow a lot, and it later turns out that
> allowing it does cause problems, you really can't go back and take it
> out. (...) Where as if we had allowed floating point, and experience
> showed that there were problems with it (which, from what I know about
> floating point seems likely), it would be impossible to take it out.

Thanks James, this is the first really informative post in this whole
thread. That raises the question: I think many people reading this thread
would like to know what this "problems" alluded to by several people
(clearly more experienced than the many) would be... I don't have enough
experience with compilers to know, can anyone expand on that? I think that
a clear statement of what the problem would be, if static const float
in-class initialization were allowed, would really help answer the original
question.

Best,
Oliber


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Espen Ruud Schultz" <default@nospam.invalid> wrote...
> ""Victor Bazarov"" <v.Abazarov@attAbi.com> wrote in message
> news:vageg0hbf1iva8@corp.supernews.com
> > "Espen Ruud Schultz" <default@nospam.invalid> wrote...
> >> [...] So you're saying that you would do what the
> >> standard requires and initialize a static const float at the point of
> >> definition?  This is what I ment, and are arguing for, becasue the
> >> standard does not allow this...
> >
> >
> > Forgive me for barging in, but you seem to be confusing the terms
> > "declaration" and "definition".  Static data members in a class
> > definition are _declared_.  The _definition_ for those members
> > must be placed _outside_ the class [definition], at the _namespace_
> > level:
> >
> >     class X {
> >         static const float whatever; // declaration
> >     };
> >     ...
> >     const float X::whatever; // definition
> >
> > There is no _definition_ for static data members _inside_ the
> > class [definition].  Plain and simple.  Static integral consts
> > are allowed to be _initialised_ where they are _declared_.  Not
> > floats, not aggregates, only integrals, and only because they
> > may be used instead of enums for _declaring_ other things, like
> > arrays sizes.  Had there been no static consts initialised at
> > a wrong place (at the point of _declaration_), there would be
> > no confusion and no argument.  Everybody would be using enums,
> > and be happy.  No, somebody needed to allow that strange form,
> > initialisation at the point of _declaration_.  Why?  Because the
> > use of enums looked bad.  Oh well...
> >
>
> First.  When I tried it this way, the linker chocked on me.  I posted this
> incident in an earlier post, and you can read all about it there.
>
> Second.  To make it past the linker I have to alter the code is such a way
> that there is now way the compiler can optimize the code.  And this is the
> very thing I want to achieve with other types in class scope...


You're still confused.  You think you can follow one rule of the
language without following any other.  That's not right.  You have
to follow them all.  The linker "chocked" on you because you did
probably violate the "one definition rule".  Now, if you don't want
to follow the rules, you shouldn't be using a language that imposes
them.

Victor
--
Please remove capital A's from my address when replying by mail

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Victor Bazarov"" <v.Abazarov@attAbi.com> wrote in message
news:Rb1qa.630767$S_4.683016@rwcrnsc53
> "Espen Ruud Schultz" <default@nospam.invalid> wrote...
>> ""Victor Bazarov"" <v.Abazarov@attAbi.com> wrote in message
>> news:vageg0hbf1iva8@corp.supernews.com
>>> "Espen Ruud Schultz" <default@nospam.invalid> wrote...
>>>> [...] So you're saying that you would do what the
>>>> standard requires and initialize a static const float at the point of
>>>> definition?  This is what I ment, and are arguing for, becasue the
>>>> standard does not allow this...
>>>
>>>
>>> Forgive me for barging in, but you seem to be confusing the terms
>>> "declaration" and "definition".  Static data members in a class
>>> definition are _declared_.  The _definition_ for those members
>>> must be placed _outside_ the class [definition], at the _namespace_
>>> level:
>>>
>>>     class X {
>>>         static const float whatever; // declaration
>>>     };
>>>     ...
>>>     const float X::whatever; // definition
>>>
>>> There is no _definition_ for static data members _inside_ the
>>> class [definition].  Plain and simple.  Static integral consts
>>> are allowed to be _initialised_ where they are _declared_.  Not
>>> floats, not aggregates, only integrals, and only because they
>>> may be used instead of enums for _declaring_ other things, like
>>> arrays sizes.  Had there been no static consts initialised at
>>> a wrong place (at the point of _declaration_), there would be
>>> no confusion and no argument.  Everybody would be using enums,
>>> and be happy.  No, somebody needed to allow that strange form,
>>> initialisation at the point of _declaration_.  Why?  Because the
>>> use of enums looked bad.  Oh well...
>>>
>>
>> First.  When I tried it this way, the linker chocked on me.  I posted
>> this incident in an earlier post, and you can read all about it there.
>>
>> Second.  To make it past the linker I have to alter the code is such a
>> way that there is now way the compiler can optimize the code.  And this
>> is the very thing I want to achieve with other types in class scope...
>
>
> You're still confused.  You think you can follow one rule of the
> language without following any other.  That's not right.  You have
> to follow them all.  The linker "chocked" on you because you did
> probably violate the "one definition rule".  Now, if you don't want
> to follow the rules, you shouldn't be using a language that imposes
> them.
>

Yeah, that's what I said in the first post about this "problem".  The class
where I tried this is linked multiple times with my program.  So to make
this work, the user of the class will have to initialize these static
consts, and that is unacceptable.  Pluss, that doing it this way will most
sertainly give these static const their own place on the stack and not be
optimized, which is the primary effect I'm after...

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

default@nospam.invalid ("Espen Ruud Schultz") wrote
> Actually, look at the code below.  I tried it a few days ago just to see.
> And guess what?  It's just another proof that static const ints are error
> prone, and that they are no less error prone than any other type if allowed
> in class scope...
>
> struct MyClass {
>    static const int MyArraySize = 10;
>    int MyArray[MyArraySize];
> } Class;
>
> int main( void ) {
>    int *MyPnt;

    // MyPnt is a pointer to non-const int.

>    MyPnt = (int*)&Class.MyArraySize;

MyArraySize is a const int. In order to assign this address to a pointer
you needed to cast it.

>    *MyPnt = 20;

Modifying the const int through a pointer to non-const brings on
undefined behavior.

>    for( int Runner = 0; Runner < Class.MyArraySize; Runner++ ) {
>       Class.MyArray[ Runner ] = Runner;
>    }
>  return 0;
> }

Not sure what results you're seeing here, but it's irrelevant --
no matter what behaviour you find on any particular platform, it
isn't a "proof" of anything. (Undefined behavior is allowed, by
definition, to behave any way at all -- including what you might
wrongly happen to expect.)

Perhaps you had a point? I'm sorry, but I missed it -- no abuse
intended, I read and re-read it! Please re-post your point without
any example of undefined behavior, and I will reply just as nicely
as I know how.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

default@nospam.invalid ("Espen Ruud Schultz") wrote in message news:<W2_pa.6875$b71.103812@news4.e.nsc.no>...
> "Randy Maddox" <rmaddox@isicns.com> wrote in message
> news:8c8b368d.0304240510.14b8c4f7@posting.google.com
> > default@nospam.invalid ("Espen Ruud Schultz") wrote in message
> > news:<K2Apa.6431$b71.97388@news4.e.nsc.no>...
> >> "Allan W" <allan_w@my-dejanews.com> wrote in message
> >> news:7f2735a5.0304221619.50a7bff@posting.google.com
> >>>
> >>> This is a standards newsgroup. People have given him good reasons
> >>> why a certain part of the standard works the way it does. His reply
> >>> was, in effect, "we should have changed it anyway. There would have
> >>> been consequences, but I'm cool with it."
> >>>
> >>
> >> You didn't read my part where I said that's exactly how it is with
> >> static
> >> const integers did you?  Because, as proven, static const int is error
> >> prone, but the standard says it's there, so people just have to be
> >> "cool"
> >> with it to use it.  Wouldn't be any different with floats or chars
> >> either -
> >> if they were allowed...
> >
> > Your "proof" re static const int kind of lost me.  Perhaps you could
> > explain that again a bit more clearly?
> >
>
> Well, as proven in another post under this discussion somewhere; you can
> initialize a static const int with a function call.  And that was a big
> error, because the static const int was 0 no matter what the function
> returned...
>
> >>
> >> Integers, floating point, and character strings are all relatively the
> >> same
> >> when it comes down to this.  So in a very childish way I could say:
> >> Since
> >> we have static const ints, then why not floats and chars?  In some cases
> >> they would make life easier, just as static const ints makes life easier
> >> now.  Of course they will "work against" what people think about
> >> initializing anything in class scope, but the ints are already far down
> >> that
> >> alley.  So why not just send floats and chars to join the ints?  I know
> >> it
> >> will make my life easier...
> >>
> >
> > Integers, floating point, and character strings are not quite the same
> > in terms of when they are initialized or where they are stored.  A
> > const integer value, and possibly, depending on the architecture, a
> > const floating point value, can be a compile time constant whose value
> > is inserted into the code segment where it is used.  Of course, if you
> > take the address of such a constant, then it will almost certainly
> > need to be stored in the data segment instead.  Pointers into the code
> > segment are rather frowned upon, and we never write self-modifying
> > code anymore ...
> >
>
> Actually, look at the code below.  I tried it a few days ago just to see.
> And guess what?  It's just another proof that static const ints are error
> prone, and that they are no less error prone than any other type if allowed
> in class scope...
>
> struct MyClass {
>    static const int MyArraySize = 10;
>    int MyArray[MyArraySize];
> } Class;
>
> int main( void ) {
>    int *MyPnt;
>    MyPnt = (int*)&Class.MyArraySize;
>    *MyPnt = 20;
>    for( int Runner = 0; Runner < Class.MyArraySize; Runner++ ) {
>       Class.MyArray[ Runner ] = Runner;
>    }
>  return 0;
> }
>

C++ never prevents you from shooting yourself in the foot if you
really want to.  Using a C-style cast to throw away the constness of
Class.MyArraySize and stuff a troublesome value there is undefined
behavior anyway, so whatever happens after that point is your own
lookout.

> >
> > A character string, like any other array, const or not, requires
> > storage in the data segment, and is initialized at run time rather
> > than being a compile time constant.  This makes sense since the name
> > of an array is in effect a pointer to its first element, so whenever
> > you declare an array you have in effect taken the address of its
> > storage.
> >
>
> Excuse my language, but this is bullshit, a compiler can and will optimize
> character strings, const or not, static or not, as the compiler see fit.
> And, as static const ints in class scope, my guess is that the compiler
> would explicitly optimize a static const char in class scope in the same
> manner.
>
> PS:  I'm not sure what the standard say about explicitly optimizing.  But
> running the above code in the VC++ 7 compiler gives strong indications that
> this is exactly what's happening...
>
> , Espen
>
> ---

Not sure what you're disagreeing with here, but if you will take a
look at the generated code, and the dissasembled code of your vendor
supplied runtime startup code, you will see that I am correct about
arrays being stored in the data segment.  If you are trying to say
that a character string is not an array, then you are simply mistaken.
 And if you are saying that a const int and a const array can both be
stored in the code segment, then you are again simply mistaken.

I'm a bit surprised that the moderators let your rude comment through.
 I had thought that the level of discourse in this newsgroup was just
a tad higher than that.

Randy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

oliver.schoenborn@utoronto.ca ("Oliver Schoenborn") wrote in message
news:<pan.2003.04.24.23.18.28.433475@utoronto.ca>...
> On Wed, 23 Apr 2003 13:53:19 +0000, James Kanze wrote:

> > allan_w@my-dejanews.com (Allan W) wrote in message
> > news:<7f2735a5.0304211217.678df461@posting.google.com>...
> >> > | Espen Ruud Schultz wrote
> >> > | > I have thought about this for a while.  And I can not see why
> >> > | > only integrals can be const statics inside a class or a
> >> > | > struct.  Why not floating point numbers or character strings?

> > (...good stuff deleted...)
> > Don't forget: if once the feature is actually implemented and used,
> > it turns out that allowing more would be nice, and pose no problems,
> > it is easy to do.  Whereas if you allow a lot, and it later turns
> > out that allowing it does cause problems, you really can't go back
> > and take it out. (...) Where as if we had allowed floating point,
> > and experience showed that there were problems with it (which, from
> > what I know about floating point seems likely), it would be
> > impossible to take it out.

> Thanks James, this is the first really informative post in this whole
> thread. That raises the question: I think many people reading this
> thread would like to know what this "problems" alluded to by several
> people (clearly more experienced than the many) would be... I don't
> have enough experience with compilers to know, can anyone expand on
> that? I think that a clear statement of what the problem would be, if
> static const float in-class initialization were allowed, would really
> help answer the original question.

First, of course, any sort of dynamic initialization is likely to cause
problems, for order of initialization reasons, if nothing else.  This is
why the standard currently forbids dynamic initialization even of
integral or enum types.  This also eliminates any type with a user
defined constructor (e.g. std::string).

Beyond that, most of the problems will only hold for cross compilers.
Regardless of the target and host architectures, a compiler must
implement integral arithmetic such that it will obtain the same results
as that on the target machine.  At present, this is NOT required for
floating point.  And floating point does have a lot of funny problems.
And the utility of floating point seems somewhat less to me.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T   l. : +33 (0)1 30 23 45 16

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Espen Ruud Schultz" <default@nospam.invalid> schrieb in im Newsbeitrag:
W2_pa.6875$b71.103812@news4.e.nsc.no...
> "Randy Maddox" <rmaddox@isicns.com> wrote in message
> news:8c8b368d.0304240510.14b8c4f7@posting.google.com
> > default@nospam.invalid ("Espen Ruud Schultz") wrote in message
> > news:<K2Apa.6431$b71.97388@news4.e.nsc.no>...
> >> "Allan W" <allan_w@my-dejanews.com> wrote in message
> >> news:7f2735a5.0304221619.50a7bff@posting.google.com
> >>>
> Actually, look at the code below.  I tried it a few days ago just to see.
> And guess what?  It's just another proof that static const ints are error
> prone, and that they are no less error prone than any other type if
allowed
> in class scope...
>
> struct MyClass {
>    static const int MyArraySize = 10;
>    int MyArray[MyArraySize];
> } Class;
>
> int main( void ) {
>    int *MyPnt;
>    MyPnt = (int*)&Class.MyArraySize; // THIS IS NOT RECOMMENDED !!!
>    *MyPnt = 20;
>    for( int Runner = 0; Runner < Class.MyArraySize; Runner++ ) {
>       Class.MyArray[ Runner ] = Runner;
>    }
>    return 0;
> }

So what is the "error" that occurs when you run the code above? I cannot try
out myself as VC++ 6.0 won't compile it. Anyway, you have cast a pointer to
a const object into a pointer to a non-const object, and this has nothing to
do with being error-prone - if you do something like that, it's simply your
own fault if something goes wrong.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3ea11cfc@news.nefonline.de>, Matthias Hofmann
<hofmann@anvil-soft.com> writes
>> There is little advantage to providing in class initialisation for other
>> static members of const type.
>
>I see. But where's the big advantage of providing in class initialisation
>for integral types? Is it the easier syntax, especially when you want to use
>the integral type as the size of an array member of the class like:
>
>class CMyClass
>{
>static const int    m_iSize = 16;
>int                      m_array[m_iSize];
>};
>
Basically , yes.


--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Ibaoa.5100$8g5.77956@news2.e.nsc.no>, Espen Ruud Schultz
<default@nospam.invalid> writes
>"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
>news:5PrLnsNvqIo+EwG8@robinton.demon.co.uk...
>> In article <3ea0670a@news.nefonline.de>, Matthias Hofmann
>> <hofmann@anvil-soft.com> writes
>| >But are you sure the standard does not allow const static character
>strings
>| >or floating point values? If so, then my compiler must be offering some
>| >language extensions.
>|
>| I think you are both misunderstanding. A class can have static members
>| of any type. However a class definition is composed of declarations.
>| static members must be defined once only, this is not allowed in the
>| class for data. The C++ Standard makes a special provision for static
>| consts of integer types where the value may be provided in class.
>| However the definition must still be provided elsewhere.
>|
>
>This is not how I see it.  A const static of any type do not need any space
>in memeory, and so I do not see why integrals should need special treatment.

Of course it normally needs space. The question is where, in the code
section or in the static memory block. It maybe that sometimes the
compiler can optimise away the storage requirement.

The reason that integrals received special treatment is because they are
often used for such things as array sizes where the static value is used
at compile time.

If all that is needed is to use the value as part of an expression, the
compiler can provide the appropriate space which the linker can fill.

>
>>
>> There is little advantage to providing in class initialisation for other
>> static members of const type.
>>
>
>The advantage is the same for any type just as it it for integral const
>static members - you can combine the declaration and initialization in the
>same line, and therby save one line of code for each const static member (
>and the code looks a better too ).  No one type of const statics should need
>any special treatment as their value is set in stone when the program
>runs...

Except that for integer values the compiler needs to be able to handle
such things as:

const int arraysize(10);
mytype aray[arraysize];

Now the compiler must know the value of arraysize, link time is too late
(well a really good linker/compiler combination might manage but it is
surely much easier if the compiler can see what size is required.]

In class context that means the compiler sometimes needs to know the
value of a static const int.

It never needs to know the value of a float.


--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:9Yl6CDBXlco+Ewna@robinton.demon.co.uk...
|
| Except that for integer values the compiler needs to be able to handle
| such things as:
|
| const int arraysize(10);
| mytype aray[arraysize];
|
| Now the compiler must know the value of arraysize, link time is too late
| (well a really good linker/compiler combination might manage but it is
| surely much easier if the compiler can see what size is required.]
|
| In class context that means the compiler sometimes needs to know the
| value of a static const int.
|
| It never needs to know the value of a float.
|

Ok, here's an idea:  Instead of making rules for the moment.  How about
making rules that makes the language versatile and expandable?  All I can
see here is that this is limiting the potential of the language.

If someone found the use for initializing a static const integral inside a
class, then who is to say that there will never be a use for initializing a
static const float inside a class, or a character string?  And there is
sertainly nothing wrong by doing it.  So why the rule?  Why the limitation?

You can argue all you want about why static const integrals should be able
to be initialized inside a class.  But I haven't seen a single point on why
a static const float shouldn't be...

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Wlmoa.5381$b71.84095@news4.e.nsc.no>, Espen Ruud Schultz
<default@nospam.invalid> writes
>You can argue all you want about why static const integrals should be able
>to be initialized inside a class.  But I haven't seen a single point on why
>a static const float shouldn't be...

Consistency seems fine, but in fact we have nasty problems concerned
with dynamic initialisation so we would be unlikely to be able to
support a general license for in class initialisers for static const
objects. The question is how to specify a clear unambiguous rule for
when it is allowed. We have one that seems to cover the useful cases. Do
you wish to formulate an alternative that covers a wider range? That
would require justification and I do not think consistency will do
because we cannot allow unconstrained in class initialisers.


--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <Wlmoa.5381$b71.84095@news4.e.nsc.no>, Espen Ruud Schultz
> <default@nospam.invalid> writes
>> You can argue all you want about why static const integrals should
>> be able to be initialized inside a class.  But I haven't seen a
>> single point on why a static const float shouldn't be...
>
> Consistency seems fine, but in fact we have nasty problems concerned
> with dynamic initialisation so we would be unlikely to be able to
> support a general license for in class initialisers for static const
> objects.

You should explain what the "nasty problems" are, or at least point
programmers to the right document which details these problems.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <78Eoa.34514$4P1.3072711@newsread2.prod.itd.earthlink.net>,
Edward Diener <eldiener@earthlink.net> writes
>> Consistency seems fine, but in fact we have nasty problems concerned
>> with dynamic initialisation so we would be unlikely to be able to
>> support a general license for in class initialisers for static const
>> objects.
>
>You should explain what the "nasty problems" are, or at least point
>programmers to the right document which details these problems.

So what does the following mean in class scope:

static udt1 const aval = 3;
static udt2 const bval = aval;

Given that udt1 has a ctor that takes an int and udt2 has a dtor that
takes a udt1.

Or:

static double const afloat = atan2(3, 4);

And yes, I can write rules to disallow such awkward initialisations, but
the point is that I would have to write such rules for very little
profit.


--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:y1UpZvATxxo+Ew1l@robinton.demon.co.uk
>
> So what does the following mean in class scope:
>
> static udt1 const aval = 3;
> static udt2 const bval = aval;
>
> Given that udt1 has a ctor that takes an int and udt2 has a dtor that
> takes a udt1.
>
> Or:
>
> static double const afloat = atan2(3, 4);
>
> And yes, I can write rules to disallow such awkward initialisations, but
> the point is that I would have to write such rules for very little
> profit.

Maybe you should...:

(class scope)
static const int MyInt = eval( 1, 2 );

....compiled just fine.  The outcome, however, was of course wrong.

It is obvious that a static const in a class scope _always_ will be a
"#define" constant ( not sure how to explain it better atm, but you get the
point ).  And it is also obvious that a static const int in a class scope
comes with a warning - "Use at own risk!", at least it should.  So why not
just add all built in types to the static-const-in-a-class family, and just
give them the same warning?  I'm cool with it.  You should know what you're
doing anyway.  I would gladly give up on "compiler safety" for language
"flexibility".  And it seems like static const ints in class scope already
have.

I just find it cumbersome to initialize a list of floating point values
through a looong initializer list.  Especially when I know that _static_
_const_ is what I really could need anyway, and is what I would use if this
was outside a class scope...

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <B9Goa.5621$b71.86665@news4.e.nsc.no>, Espen Ruud Schultz
<default@nospam.invalid> writes
>Maybe you should...:
>
>(class scope)
>static const int MyInt = eval( 1, 2 );

Looking at 9.2 para 4 and 9.4.2 para 4 leads me to think that the
compiler should be issuing a diagnostic because (assuming it isn't a
preprocessor macro)  eval(1, 2) is not a constant initialiser.


--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:dqmS+3AaY+o+EwgT@robinton.demon.co.uk
> In article <B9Goa.5621$b71.86665@news4.e.nsc.no>, Espen Ruud Schultz
> <default@nospam.invalid> writes
>> Maybe you should...:
>>
>> (class scope)
>> static const int MyInt = eval( 1, 2 );
>
> Looking at 9.2 para 4 and 9.4.2 para 4 leads me to think that the
> compiler should be issuing a diagnostic because (assuming it isn't a
> preprocessor macro)  eval(1, 2) is not a constant initialiser.

eval() is a simpel function returning an int.  It was kompiled with VC++ 7
( warning level 3 I think ), not like it should mean anything thought, since
I don't think there are any compilers out there that fully complies to the
standard...

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> | Espen Ruud Schultz wrote
> | > I have thought about this for a while.  And I can not see why
> | > only integrals can be const statics inside a class or a struct.
> | > Why not floating point numbers or character strings?

> "Allan W" <allan_w@my-dejanews.com> wrote
> | I *think* that some compilers handle these very similarly to the
> | way that they handle enums. As you probably know, enums cannot
> | be floating point numbers or character strings.

Espen Ruud Schultz wrote
> Well, that could be it, but I don't think so.  First it would be
> stupid to set a standard from what a compiler does, the compiler
> should do what the standard says.  And this is probably the case too.

The language C++ was around before the standard. One of the tasks
of the C++ standard (the major one?) was to document existing
practice. When existing practice differed, the standard was supposed
to select one for all to follow.

In this light, perhaps you would like to rephrase your sentiment?

> Second, you can have two or more const static itegrals with the
> same value. Of course, if it was en enum, the values could easily
> be merged, but I don't think so either...

Sorry, but enums can also have the same value -- even the same enum.

    class foo {
        enum { zero=0, one,
           two=2, sqrt_of_4=2, cuberoot_of_8=2,
           half_of_four=2, two_times_one=2
        };
    };

> | Naturally, you CAN create const static floats or strings... they just
> | can't be fully defined in the class or struct.
>
> The reason for me asking this is releated to the post "namespace inside a
> class", where I want to group some values inside a class.  Now if I only had
> integral values I could easily group them with a struct and set them as
> const statics.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Espen Ruud Schultz wrote
> It is obvious that a static const in a class scope _always_
> will be a "#define" constant ( not sure how to explain it
> better atm, but you get the point ).
I'm not sure I get the point.

Even if I did, that wouldn't be good enough for the standard.
#define is in the precompiler; long before lexical analysis.
Furthermore, we want our constants to be able to evaluate
expressions such as (40+1), which (in the precompiler) would
always be "an expression" rather than "a constant expression."


> And it is also obvious that a static const int in a class
> scope comes with a warning - "Use at own risk!", at least
> it should.  So why not just add all built in types to the
> static-const-in-a-class family, and just give them the
> same warning?  I'm cool with it.

Okay, time for a quiz. There's only one question, multiple choice.

Question 1. When C++ was standardized, what did the committee
members think about you, Espen Ruud Schultz?

A. The C++ standard was written (and others agreed to be bound by
it) specifically to satisfy you, Espen Ruud Schultz. How tragic
that they came so close, then made some blundering errors -- all
without even consulting you.

B. The C++ standard was written with this in mind: We know who
Espen Ruud Schultz is, and what he would like. We hate him, so
we'll try to drive him crazy: We'll make the whole language just
logical and easy to use, except for this thing about non-integral
constants in classes. Won't he just hate that?!?

C. The C++ standardization committee hadn't even heard of you,
Espen Ruud Schultz, which is why it was NOT written just for you.
A committee of very smart men take time out of their "productive"
work. Not not only are they not paid for this work, but they (or
their companies) pay dearly for the privilige. They use their best
judgement, plus impressions gathered from this newsgroup and
other communication, to try to determine what would be best
for the language as a whole -- including you, Espen Ruud Schultz,
but also for other people and even companies. "Best for the
language" usually means the greatest good for the greatest number
of people. There are specific design goals that guide them in that
general direction. I'm sure that "consistency" is on that list,
but it doesn't overwhelm it -- there are a great many things that
they should do, or should avoid doing. One of them is, avoid code
constructs that tend to cause errors -- this is the opposite of
your "use at own risk!" warning.

D. Whoops! I, Espen Ruud Schultz, am in the wrong newsgroup.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:
 On further consideration, I probably should have rejected that
article for this exactly this reason.


===================================== END OF MODERATOR'S COMMENT
allan_w@my-dejanews.com (Allan W) writes:

> Okay, time for a quiz. There's only one question, multiple choice.

<snip>

> D. Whoops! I, Espen Ruud Schultz, am in the wrong newsgroup.

He may be off base, but what did he do to deserve this kind of abuse?

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I have thought about this for a while.  And I can not see why only integrals
can be const statics inside a class or a struct.  Why not floating point
numbers or character strings?

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

default@nospam.invalid ("Espen Ruud Schultz") wrote in message news:<F3kna.4698$b71.76245@news4.e.nsc.no>...
> I have thought about this for a while.  And I can not see why only integrals
> can be const statics inside a class or a struct.  Why not floating point
> numbers or character strings?

I *think* that some compilers handle these very similarly to the
way that they handle enums. As you probably know, enums cannot
be floating point numbers or character strings.

Naturally, you CAN create const static floats or strings... they just
can't be fully defined in the class or struct.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message
news:7f2735a5.0304171529.27be4dd8@posting.google.com...
| default@nospam.invalid ("Espen Ruud Schultz") wrote in message
news:<F3kna.4698$b71.76245@news4.e.nsc.no>...
| > I have thought about this for a while.  And I can not see why only
integrals
| > can be const statics inside a class or a struct.  Why not floating point
| > numbers or character strings?
|
| I *think* that some compilers handle these very similarly to the
| way that they handle enums. As you probably know, enums cannot
| be floating point numbers or character strings.
|

Well, that could be it, but I don't think so.  First it would be stupid to
set a standard from what a compiler does, the compiler should do what the
standard says.  And this is probably the case too.  Second, you can have two
or more const static itegrals with the same value.  Of course, if it was en
enum, the values could easily be merged, but I don't think so either...

|
| Naturally, you CAN create const static floats or strings... they just
| can't be fully defined in the class or struct.
|

The reason for me asking this is releated to the post "namespace inside a
class", where I want to group some values inside a class.  Now if I only had
integral values I could easily group them with a struct and set them as
const statics.  To easily see my problem, this is what I have:

namespace MySpace {

   namespace MyGroup0 {
      const int MyInt0 = 0;
      const int MyInt1 = 1;
   }

   namespace MyGroup1 {
      const int MyInt0 = 0;
      const int MyInt1 = 1;
   }

   namespace MyGroup2 {
      const char MyChar0[] = "string0";
      const char MyChar1[] = "string1";
   }

   class MyClass {
      ...
   };

}

Everybody can see the disadvantage in having the namespace groups outside
the class.  I could, however, put the groups inside the class through
structs and setting the values as const statics.  And I can too, but only
the integral values, only MyGroup0 and MyGroup1.  MyGroup2 have to stay
outside the class because chars can't be const statics inside a struct.  And
if one have to stay outside, then there's no reason to put the others
inside.  Especially if it's the one group I can't put inside that I want to
keep private, and the others public...

So once again I feel I have been stopped by a rule just becasue it wan't
needed at the time it was created.  Unless there is something I have missed.
I valid reason for only allowing integrals to be const statics inside a
struct...?

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> So once again I feel I have been stopped by a rule just becasue it wan't
> needed at the time it was created.  Unless there is something I have
missed.
> I valid reason for only allowing integrals to be const statics inside a
> struct...?

Well, that confuses me as it works on my compiler. I use Microsoft Visual
C++ 6.0 and the following code compiles and works fine:

class CBogus
{
public:
    CBogus()
    {
        cout << m_szString << endl;

        cout << m_fNumber << endl;
    }

private:
    static const char*  m_szString;
    static const float  m_fNumber;
};

const char* CBogus::m_szString = "Hello";
const float CBogus::m_fNumber = 0.2f;

int main()
{
    CBogus b;

    return 0;
}

The only drawback is that I have to define and initialize static members
outside the class, as my compiler does not comply with the standard in that
respect.

But are you sure the standard does not allow const static character strings
or floating point values? If so, then my compiler must be offering some
language extensions.

Regards,

Matthias



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3ea0670a@news.nefonline.de>, Matthias Hofmann
<hofmann@anvil-soft.com> writes
>But are you sure the standard does not allow const static character strings
>or floating point values? If so, then my compiler must be offering some
>language extensions.

I think you are both misunderstanding. A class can have static members
of any type. However a class definition is composed of declarations.
static members must be defined once only, this is not allowed in the
class for data. The C++ Standard makes a special provision for static
consts of integer types where the value may be provided in class.
However the definition must still be provided elsewhere.

There is little advantage to providing in class initialisation for other
static members of const type.



--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Matthias Hofmann"" <hofmann@anvil-soft.com> wrote in message
news:3ea0670a@news.nefonline.de...
| > So once again I feel I have been stopped by a rule just becasue it wan't
| > needed at the time it was created.  Unless there is something I have
| missed.
| > I valid reason for only allowing integrals to be const statics inside a
| > struct...?
|
| Well, that confuses me as it works on my compiler. I use Microsoft Visual
| C++ 6.0 and the following code compiles and works fine:
|
| class CBogus
| {
| public:
|     CBogus()
|     {
|         cout << m_szString << endl;
|
|         cout << m_fNumber << endl;
|     }
|
| private:
|     static const char*  m_szString;
|     static const float  m_fNumber;
| };
|
| const char* CBogus::m_szString = "Hello";
| const float CBogus::m_fNumber = 0.2f;
|
| int main()
| {
|     CBogus b;
|
|     return 0;
| }
|
| The only drawback is that I have to define and initialize static members
| outside the class, as my compiler does not comply with the standard in
that
| respect.
|
| But are you sure the standard does not allow const static character
strings
| or floating point values? If so, then my compiler must be offering some
| language extensions.
|

Hmm, works on the VC++ 7 compiler too.  Actually, I haven't checked the
standard.  But when I first encountered this "problem", I asked around, and
I didn't get any indication as to this not being a problem.  So I just
assumed that standard said so.

Anyway, this new discovery doesn't make any sence either.  Why do all
non-integral const statics have to be initialized outside the struct?  The
compiler will most likely not give them any memory space anyway, and instead
just use the values directly.

Can anybody please enlighten me about what the standard really says about
const statics and classes?

Anyway, thanks for the new info.  I would say this was a big step in the
right direction, even though it doesn't make sence to do it like this...

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> There is little advantage to providing in class initialisation for other
> static members of const type.

I see. But where's the big advantage of providing in class initialisation
for integral types? Is it the easier syntax, especially when you want to use
the integral type as the size of an array member of the class like:

class CMyClass
{
static const int    m_iSize = 16;
int                      m_array[m_iSize];
};


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:5PrLnsNvqIo+EwG8@robinton.demon.co.uk...
| In article <3ea0670a@news.nefonline.de>, Matthias Hofmann
| <hofmann@anvil-soft.com> writes
| >But are you sure the standard does not allow const static character
strings
| >or floating point values? If so, then my compiler must be offering some
| >language extensions.
|
| I think you are both misunderstanding. A class can have static members
| of any type. However a class definition is composed of declarations.
| static members must be defined once only, this is not allowed in the
| class for data. The C++ Standard makes a special provision for static
| consts of integer types where the value may be provided in class.
| However the definition must still be provided elsewhere.
|

This is not how I see it.  A const static of any type do not need any space
in memeory, and so I do not see why integrals should need special treatment.

|
| There is little advantage to providing in class initialisation for other
| static members of const type.
|

The advantage is the same for any type just as it it for integral const
static members - you can combine the declaration and initialization in the
same line, and therby save one line of code for each const static member (
and the code looks a better too ).  No one type of const statics should need
any special treatment as their value is set in stone when the program
runs...

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Matthias Hofmann"" <hofmann@anvil-soft.com> wrote in message
news:3ea0670a@news.nefonline.de...
|
| Well, that confuses me as it works on my compiler. I use Microsoft Visual
| C++ 6.0 and the following code compiles and works fine:
|
| class CBogus
| {
| public:
|     CBogus()
|     {
|         cout << m_szString << endl;
|
|         cout << m_fNumber << endl;
|     }
|
| private:
|     static const char*  m_szString;
|     static const float  m_fNumber;
| };
|
| const char* CBogus::m_szString = "Hello";
| const float CBogus::m_fNumber = 0.2f;
|
| int main()
| {
|     CBogus b;
|
|     return 0;
| }
|
| The only drawback is that I have to define and initialize static members
| outside the class, as my compiler does not comply with the standard in
that
| respect.
|

This drawback might be too much.  At first I though, "outside the class, but
in the same header file, so ok, this can work".  But no, it can't be in the
same hader file if more than one part of the program use this file.  They
have to be defined once only in the entire program.  Even though I have
ifndef'ed the entire file (linker problem).  So this means the user of the
class has to do the initialization, and that is not acceptable...

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <78Eoa.34514$4P1.3072711@newsread2.prod.itd.earthlink.net>,
> Edward Diener <eldiener@earthlink.net> writes
>>> Consistency seems fine, but in fact we have nasty problems concerned
>>> with dynamic initialisation so we would be unlikely to be able to
>>> support a general license for in class initialisers for static const
>>> objects.
>>
>> You should explain what the "nasty problems" are, or at least point
>> programmers to the right document which details these problems.
>
> So what does the following mean in class scope:
>
> static udt1 const aval = 3;
> static udt2 const bval = aval;
>
> Given that udt1 has a ctor that takes an int and udt2 has a dtor that
> takes a udt1.
>
> Or:
>
> static double const afloat = atan2(3, 4);
>
> And yes, I can write rules to disallow such awkward initialisations,
> but the point is that I would have to write such rules for very little
> profit.

It seems as if C++ could allow static const variables to be initialized in a
class for all built-in types and not for object types, and that the
expression used to initialize the static const variable would be a constant
expression. I would disallow any calls of functions but would allow such
types as float or double to be initialized as well as enumerated constants.
It does seem as if only integral consts are a bit restrictive. Wit this
expanded allowance, none of your examples above would be rightly allowed.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:9Yl6CDBXlco+Ewna@robinton.demon.co.uk
>>
>> The advantage is the same for any type just as it it for integral const
>> static members - you can combine the declaration and initialization in
>> the same line, and therby save one line of code for each const static
>> member ( and the code looks a better too ).  No one type of const
>> statics should need any special treatment as their value is set in
>> stone when the program runs...
>
> Except that for integer values the compiler needs to be able to handle
> such things as:
>
> const int arraysize(10);
> mytype aray[arraysize];
>
> Now the compiler must know the value of arraysize, link time is too late
> (well a really good linker/compiler combination might manage but it is
> surely much easier if the compiler can see what size is required.]
>
> In class context that means the compiler sometimes needs to know the
> value of a static const int.
>
> It never needs to know the value of a float.
>

I'm gonna finish my thoughts about static const by going back a few posts
and fill inn something I feel I missed here:

You say that the reason for allowing initialization of static const ints in
class scope, is a special case becasue sometimes the compiler needs to know
the value of an int.  I'm with you so far, and I agree.  And you probably
also doesn't like the idea of initializing _any_ type of consts in class
scope.  But it weights against using macros, and it is the better of two
evils, so you agree to this special case of static const ints.  I'm even
with you this far.  And I agree about the macros, but not the rest.  I can't
see the danger in any static const.  In fact, I think of static consts just
as a type checked and scope defined macro ( I think, I don't say it is ).

Talking about choosing the better of two evils:  I would say initializing a
huge list of floats through the initializer list is one big evil.  And I
would choose the lesser evil, static const float, any day over an unreadable
initializer list or a list of macros.  Maybe you don't agree about this
thought?

I just find the initializer list cumbersome.  It is perfect for a few
consts, but not for a long list of them.  Then I would rather go for a list
of macros, and just thinking about that makes my stomach turn...

PS:  I'm sorry if it sounds like I'm putting the words in you mouth when I
talk about what you think.  I have no idea what you exact thought are about
this, but I would say this is more the general thoguhts people have.

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> Anyway, this new discovery doesn't make any sence either.  Why do all
> non-integral const statics have to be initialized outside the struct?  The
> compiler will most likely not give them any memory space anyway, and
instead
> just use the values directly.

I don't know what the standard says, but when I initialize the variable in
class, VC++ 6.0 mixes it up with a pure virtual function, obviously bevause
of the similarities between

virtual int f() = 0;

and

const int value = 2;

I know this because the compiler gives me an error message which mentions
something about a virtual function.

> This drawback might be too much.  At first I though, "outside the class,
but
> in the same header file, so ok, this can work".  But no, it can't be in
the
> same hader file if more than one part of the program use this file.  They
> have to be defined once only in the entire program.  Even though I have
> ifndef'ed the entire file (linker problem).  So this means the user of the
> class has to do the initialization, and that is not acceptable...

What's so bad about defining them in the .cpp file? The user of the class
does not have to do the initialization, like he does not have to do the
implementation either.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Matthias Hofmann"" <hofmann@anvil-soft.com> wrote in message news:3ea57f60@news.nefonline.de...
>
> What's so bad about defining them in the .cpp file? The user of the class
> does not have to do the initialization, like he does not have to do the
> implementation either.
>
If you don't have the initializer visible, you don't have a constant expression
which is required by certain operations.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <VYbpa.6002$b71.91433@news4.e.nsc.no>, Espen Ruud Schultz
<default@nospam.invalid> writes
>Talking about choosing the better of two evils:  I would say initializing a
>huge list of floats through the initializer list is one big evil.  And I
>would choose the lesser evil, static const float, any day over an unreadable
>initializer list or a list of macros.  Maybe you don't agree about this
>thought?


But I would not do that. I would do what the standard requires and
initialise static consts at the point of definition.

--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Matthias Hofmann" wrote:
>> This drawback might be too much.  At first I though, "outside the
>> class, but in the same header file, so ok, this can work".  But no,
>> it can't be in the same hader file if more than one part of the
>> program use this file.  They have to be defined once only in the
>> entire program.  Even though I have ifndef'ed the entire file
>> (linker problem).  So this means the user of the class has to do the
>> initialization, and that is not acceptable...
>
> What's so bad about defining them in the .cpp file? The user of the
> class does not have to do the initialization, like he does not have
> to do the implementation either.

By initializing them in the class itself, the variable can be used by other
declarations in the class as if one was using a constant value. Thus static
const variables would more closely mimic and replace macro #defines for
values. This can not be done if the static const variable were initialized
in the source file instead.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Espen Ruud Schultz wrote
> So why not just add all built in types to the
> static-const-in-a-class family, and just give them the
> same warning?  I'm cool with it.

dave@boost-consulting.com (David Abrahams) wrote
> allan_w@my-dejanews.com (Allan W) writes:
>
> > Okay, time for a quiz. There's only one question, multiple choice.
>
> <snip>
>
> > D. Whoops! I, Espen Ruud Schultz, am in the wrong newsgroup.
>
> He may be off base, but what did he do to deserve this kind of abuse?

> ===================================== MODERATOR'S COMMENT:
>  On further consideration, I probably should have rejected that
> article for this exactly this reason.
> ===================================== END OF MODERATOR'S COMMENT

I didn't intend this as "abuse" and I sincerely apologize if it came
out that way.

This is a standards newsgroup. People have given him good reasons
why a certain part of the standard works the way it does. His reply
was, in effect, "we should have changed it anyway. There would have
been consequences, but I'm cool with it."

As I pointed out in a part of my reply that you snipped, the standard
isn't about making things "cool" just for one person. The whole point
of a standard is a stationary target. If a vendor says that his product
complies with the standard, we now have certain minimum expectations of
that product.

Perhaps I didn't say that the best way possible.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis.glassborow@ntlworld.com (Francis Glassborow) wrote in
news:5PrLnsNvqIo+EwG8@robinton.demon.co.uk:

>
> There is little advantage to providing in class initialisation for
> other static members of const type.
>

Brace initializers can only be used when initializing an aggregate, and I
can't think of a more convenient way to initialize an array of const static
integrals.


--
Mike Conley

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Xns9365E59C28E80conley141osuedu@65.24.2.11>, Mike Conley
<conley.141@osu.edu> writes
>francis.glassborow@ntlworld.com (Francis Glassborow) wrote in
>news:5PrLnsNvqIo+EwG8@robinton.demon.co.uk:
>
>>
>> There is little advantage to providing in class initialisation for
>> other static members of const type.
>>
>
>Brace initializers can only be used when initializing an aggregate, and I
>can't think of a more convenient way to initialize an array of const static
>integrals.
>
You are  missing the point. We do not allow brace initialisers in pure
declarations, only in definitions. Allowing an initialiser in a
declaration that is not a definition is a very special case. That is
what we have with in class initialisers for static const integer
objects.

You brace initialisation is applied in the perfectly normal place, the
single point of definition that every variable including class statics
must have.

Personally I have always disliked in class initialisers and opposed them
when they were proposed. Basically they were introduced because a number
of people did not like the 'hijacking' of enums to provide manifest
constants at class scope.

--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> So what does the following mean in class scope:
>
> static udt1 const aval = 3;
> static udt2 const bval = aval;
>
> Given that udt1 has a ctor that takes an int and udt2 has a dtor that
> takes a udt1.
>
> Or:
>
> static double const afloat = atan2(3, 4);
>
> And yes, I can write rules to disallow such awkward initialisations, but
> the point is that I would have to write such rules for very little
> profit.

sure there would be lots of problems when you would use non-primitive
datatypes or use other initializers than just compiletime expressions.

i do not see any difference between

const static int i = 0;

and

const static float f = 0.0f;

both are stored in the code, not in the data segment, both are compiletime
expressions, both primitive datatypes.

quesition:
what would be if i compiled the cpp with a value of the const static int i
set to 0, then throw away the cpp file and link only the .obj file to the
project and include the .h file with a const static int i set to 1? the code
in the class itself would still use 0 but outside the class the compiler
would use the new value(1) and there would be no way to detect this kind of
error, wouldnt it?

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu
[noncommercial and no fucking ads]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) wrote in message
news:<7f2735a5.0304211217.678df461@posting.google.com>...
> > | Espen Ruud Schultz wrote
> > | > I have thought about this for a while.  And I can not see why
> > | > only integrals can be const statics inside a class or a struct.
> > | > Why not floating point numbers or character strings?

>  "Allan W" <allan_w@my-dejanews.com> wrote
> > | I *think* that some compilers handle these very similarly to the
> > | way that they handle enums. As you probably know, enums cannot be
> > | floating point numbers or character strings.

> Espen Ruud Schultz wrote
> > Well, that could be it, but I don't think so.  First it would be
> > stupid to set a standard from what a compiler does, the compiler
> > should do what the standard says.  And this is probably the case
> > too.

> The language C++ was around before the standard. One of the tasks of
> the C++ standard (the major one?) was to document existing
> practice. When existing practice differed, the standard was supposed
> to select one for all to follow.

> In this light, perhaps you would like to rephrase your sentiment?

Given the presence of two-phase lookup, export and member templates,
new-style casts, RTTI, for-scope, the STL, std::locale, templated
iostream's, etc., none of which existed before the standard defined it,
perhaps you would care to rephrase YOUR sentiment.  A language called
C++ was around before the standard, and is still around today to a large
extent, but this language bears only a passing resemblance to standard
C++.  Your statement corresponds to what a standard SHOULD do (IMHO),
but not to what the C++ standard actually did.

That said, the question is valid.  It was even considered by the
standards committee.  In the end:

  - Existing practice didn't allow any initializers in the class
    definition.  This was awkward because it didn't allow things like:

        struct A
        {
            static size_t const size ;
            int                 data[ size ] ;
        } ;

    Presumably, the committee could have required making this work.  It
    probably wouldn't have been much more difficult than export for the
    compiler implementors.

    The general consensus was that there is no point in adopting
    something that can't, or won't be implemented.

  - The obvious solution is to allow the initializer in the class
    definition.  However, things like:

        struct A
        {
            static MyClass const a( "a string", aDouble, anIntFunction() ) ;
        } ;

    cause probl   mes with regards to the order of implementation.  It is,
    I hope, evident that some restrictions are necessary.

  - Given that some restrictions are necessary, the question is: what?
    To make things simple, it is preferable that the restrictions are
    already formulated in the standard, for other reasons.  Given that
    the motivation requires supporting constant integral exceptions for
    integral types, as a minimum, and what I've just said excludes
    dynamic initialization, as a maximum, there aren't that many
    choices: restrict it to constant integral expressions, or allow any
    static initialization.  Between the two, the choice is really pretty
    arbitrary.  We've given up orthogonality already (since we don't
    allow just any initialization).  This feature was added fairly late
    in the process, and there was doubtlessly some worry about its
    effects (especially with regards to floating point). This leads to
    favoring a minimalist approach, which was what was adopted.

Don't forget: if once the feature is actually implemented and used, it
turns out that allowing more would be nice, and pose no problems, it is
easy to do.  Whereas if you allow a lot, and it later turns out that
allowing it does cause problems, you really can't go back and take it
out.  For the moment, I've yet to see any real arguments to the effect
that we need support for floating point, but if someone does present
some, there would be no problem adding it in the future; adding it can't
break any existing code.  Where as if we had allowed floating point, and
experience showed that there were problems with it (which, from what I
know about floating point seems likely), it would be impossible to take
it out.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T   l. : +33 (0)1 30 23 45 16

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"cody" <deutronium@web.de> wrote...
> [...]
> quesition:
> what would be if i compiled the cpp with a value of the const static int i
> set to 0, then throw away the cpp file and link only the .obj file to the
> project and include the .h file with a const static int i set to 1? the
code
> in the class itself would still use 0 but outside the class the compiler
> would use the new value(1) and there would be no way to detect this kind
of
> error, wouldnt it?

Of course there wouldn't.  The Standard does not define '.obj'
file or the process of linking.

What if I defined a class, compiled a unit using it, then changed
the class, compiled another unit with a new class, and then passed
objects of that class between the units?  It's undefined.  There
is no way to specify the outcome of such compilation process.

When you change the source code (no matter how), you're compiling
a different class.  It doesn't matter that the layout didn't change
and it's only a static const integer that got a different value.
You managed to have two definitions for the "same" class in your
program.  You violated the "one definition rule".  Plain and simple.


Victor
--
Please remove capital A's from my address when replying by mail


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message
news:7f2735a5.0304221619.50a7bff@posting.google.com
>
> This is a standards newsgroup. People have given him good reasons
> why a certain part of the standard works the way it does. His reply
> was, in effect, "we should have changed it anyway. There would have
> been consequences, but I'm cool with it."
>

You didn't read my part where I said that's exactly how it is with static
const integers did you?  Because, as proven, static const int is error
prone, but the standard says it's there, so people just have to be "cool"
with it to use it.  Wouldn't be any different with floats or chars either -
if they were allowed...

Integers, floating point, and character strings are all relatively the same
when it comes down to this.  So in a very childish way I could say:  Since
we have static const ints, then why not floats and chars?  In some cases
they would make life easier, just as static const ints makes life easier
now.  Of course they will "work against" what people think about
initializing anything in class scope, but the ints are already far down that
alley.  So why not just send floats and chars to join the ints?  I know it
will make my life easier...

, Espen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> You brace initialisation is applied in the perfectly normal place, the
> single point of definition that every variable including class statics
> must have.

The perfectly normal place for a member array of const static things is at
the point of declaration.  There is no other place where such an
initializer could go.

> Personally I have always disliked in class initialisers and opposed
> them when they were proposed. Basically they were introduced because a
> number of people did not like the 'hijacking' of enums to provide
> manifest constants at class scope.

It seems reasonable to allow them for const static members of any type, if
only because there's no better place to initialize such members.


--
Mike Conley

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Edward Diener" <eldiener@earthlink.net> schrieb in im Newsbeitrag:
OUipa.37451$4P1.3377536@newsread2.prod.itd.earthlink.net...
> "Matthias Hofmann" wrote:
> By initializing them in the class itself, the variable can be used by
other
> declarations in the class as if one was using a constant value. Thus
static
> const variables would more closely mimic and replace macro #defines for
> values. This can not be done if the static const variable were initialized
> in the source file instead.

So this means that the compiler's "reaction" on the static const variable
can be one of the following two:

1. If the initializer is visible because the variable is initialized in the
class itself, the compiler will optimize the code by putting the constant in
the code segment

2. If the static const is initialized in the cpp file, the compiler will put
this variable in the data segment, and whenever it is used in the code, its
value will have to be looked up in the data segment

Am I getting this right?


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

conley.141@osu.edu (Mike Conley) wrote in
news:Xns93668BEE0C50conley141osuedu@65.24.2.11:

> It seems reasonable to allow them for const static members of any
> type, if only because there's no better place to initialize such
> members.
>

That should read any POD type.  We wouldn't want any functions called,
including ctors.




--
Mike Conley

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

conley.141@osu.edu (Mike Conley) wrote in
news:Xns93668BEE0C50conley141osuedu@65.24.2.11:

Never mind.  I reread the relevant section.  The static's definition
belongs at namespace scope (which kind of makes in class initialization
silly).


--
Mike Conley

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Xns93668BEE0C50conley141osuedu@65.24.2.11>, Mike Conley
<conley.141@osu.edu> writes
>> You brace initialisation is applied in the perfectly normal place, the
>> single point of definition that every variable including class statics
>> must have.
>
>The perfectly normal place for a member array of const static things is at
>the point of declaration.  There is no other place where such an
>initializer could go.


Please explain because this makes no sense to me.

--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3ea6d65c$1@news.nefonline.de>, Matthias Hofmann
<hofmann@anvil-soft.com> writes
>So this means that the compiler's "reaction" on the static const variable
>can be one of the following two:
>
>1. If the initializer is visible because the variable is initialized in the
>class itself, the compiler will optimize the code by putting the constant in
>the code segment
>
>2. If the static const is initialized in the cpp file, the compiler will put
>this variable in the data segment, and whenever it is used in the code, its
>value will have to be looked up in the data segment
>
>Am I getting this right?

No because linkers already do far more complicated things. There is no
reason that a half way decent linker cannot patch up consts. What it
cannot do so easily is cope with static arrays whose size is provided by
a const int.

--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis.glassborow@ntlworld.com (Francis Glassborow) wrote in
news:GpRkOWCDrtp+Ew6X@robinton.demon.co.uk:

> Please explain because this makes no sense to me.

As it shouldn't.  It makes no sense because I misunderstood the standard.
Somehow I had gotten the impression that static const members had to be
initialized at the point of declaration (within the class).  Clearly, that
is not the case.


--
Mike Conley

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]