wmm@fastdial.net wrote:

> In article <39ff5957_1@news.nwlink.com>,
>   "Gary Hinger" <garyh@zipperint.com> wrote:
> > Your message implies that something like
> >
> > int const two = static_cast<int>( 1.0f+1.0f );
> >
> > isn't supported. Isn't it?
>
> No, it isn't.  According to 5.19p1, "Floating literals (2.13.3)
> can appear only if they are cast to integral or enumeration types."
> That means the literal itself, not the result of some operation
> on a literal.  In other words, "int(1.0)+int(2.0)" is fine, but
> "int(1.0+2.0)" isn't.  (Of course, "not supported" doesn't mean
> that the compiler issues an error when seeing your example, just
> that the initialization is done dynamically by evaluating the
> expression at runtime rather than statically with compile-time
> evaluation.)
>
> > Also, I have trouble believing that floating point computations are
> that big
> > of a burden when compared to the "export" keyword, which nobody has
> actually
> > implemented yet AFAIK.
>
> The reason for excluding floating point compile-time calculations
> here isn't that they are intrinsically hard.  It's to allow for
> cross-compilers, where the hardware on which the compiler runs
> may not support the floating point format used by the target
> environment.  We didn't want to require writers of cross-compilers
> to write a complete emulation of the floating point hardware on
> their target, and we didn't want to have to deal with situations
> where the compile-time and runtime calculations might get different
> results.

This is already a serious issue because things like DBL_EPSILON/2.0 may be
evaluated by the compiler with a mantissa width that does not match that of
the run-time on the same machine.  Now in principle dividing by two should be
trivial for a machine with FLT_RADIX == 2.  But some (otherwise respectable)
compilers fail to handle these situations consistently.  One does not need
templates to produce instances of this issue.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <39ff5957_1@news.nwlink.com>,
  "Gary Hinger" <garyh@zipperint.com> wrote:
> Your message implies that something like
>
> int const two = static_cast<int>( 1.0f+1.0f );
>
> isn't supported. Isn't it?

No, it isn't.  According to 5.19p1, "Floating literals (2.13.3)
can appear only if they are cast to integral or enumeration types."
That means the literal itself, not the result of some operation
on a literal.  In other words, "int(1.0)+int(2.0)" is fine, but
"int(1.0+2.0)" isn't.  (Of course, "not supported" doesn't mean
that the compiler issues an error when seeing your example, just
that the initialization is done dynamically by evaluating the
expression at runtime rather than statically with compile-time
evaluation.)

> Also, I have trouble believing that floating point computations are
that big
> of a burden when compared to the "export" keyword, which nobody has
actually
> implemented yet AFAIK.

The reason for excluding floating point compile-time calculations
here isn't that they are intrinsically hard.  It's to allow for
cross-compilers, where the hardware on which the compiler runs
may not support the floating point format used by the target
environment.  We didn't want to require writers of cross-compilers
to write a complete emulation of the floating point hardware on
their target, and we didn't want to have to deal with situations
where the compile-time and runtime calculations might get different
results.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Your message implies that something like

int const two = static_cast<int>( 1.0f+1.0f );

isn't supported. Isn't it?

Also, I have trouble believing that floating point computations are that big
of a burden when compared to the "export" keyword, which nobody has actually
implemented yet AFAIK.

Ron Natalie <ron@sensor.com> wrote in message
news:39FD8DEE.343DC582@sensor.com...
> I suppose it's because they didn't want to burden the compiler with having
> to be able to do floating point computations.  It's hard to write a
compiler that doesn't
> do at least integer math internally.



---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ron Natalie <ron@sensor.com> writes:

>Michael Schumacher wrote:
>
>> Followup question: why does the standard not allow floating-point types ?
>> I can't see why these should be any different to integral types.
>
>I suppose it's because they didn't want to burden the compiler with having
>to be able to do floating point computations.

In particular for cross-compilers, it would be burdensome for the
compiler to have to emulate the target machine's floating point
arithmetic.

>It's hard to write a compiler that doesn't do at least integer math
>internally.

And furthermore emulating a target machine's integer arithmetic is
generally a lot easier than emulating its floating point arithmetic.

(Also as others mentioned compile-time floating point constants
are much less useful than compile-time integer constants.)

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <39FD8DEE.343DC582@sensor.com>,
  Ron Natalie <ron@sensor.com> wrote:
>
>
> Michael Schumacher wrote:
>
> > Followup question: why does the standard not allow floating-point
types ?
> > I can't see why these should be any different to integral types.
>
> I suppose it's because they didn't want to burden the compiler with
having
> to be able to do floating point computations.

That's part of it, but the other side is that the language has
been structured so that there's no real use for compile-time
constant floating-point expressions, either.

There are a number of contexts that require a compile-time
constant value -- "case" labels, array bounds, bit-field lengths,
etc. -- and these are all integer values.  As a result, the
language defines the concept of "integral constant expression"
(5.19p1).  The provision for initializers for static const
data members of integral and enum type is to allow class-scope
names to be used in integral constant expressions.  (Before this
was added to the language, people used unnamed enums to specify
class-scope integral constant values.)

There is no corresponding need for floating point constant
expressions.  The only reason for such is to get a static
instead of a dynamic initialization of a static object (5.19p2,
3.6.2p1).  That didn't seem a compelling enough reason to allow
floating point types to be inline initialized.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> Too bad we can't initialize static const members in the header for other
> builtin types, e.g. char, float, double, etc.. This seems natural to me
and
> I am surprised that it isn't already allowed.

Consider what would happen if the class header was included in more than one
compilation unit. This could easily lead to more than one creation of the
static member (one in each compilation unit). I suppose this is the reason
for not allowing it.

/Per



---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

You are allowed to initialise "static const"  "int"/"enum" members in the
header. All others must be initialised in the implementation.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Gary Hinger wrote:
>
> Does the Standard permit this code?
>
> struct S
> {
>     S();
>     S(int);
>     S(int,int);
>
>     static S const a();
>     static S const b(1);
>     static S const c(1,2);
> };
>
You can't initialize statics this way.
a is declared above as a static member function taking no args and returning a
const S.  The declarations of b and c are syntax errors.

struct S {
   S();
   S(int);
   S(int, int);
   static S const a;
   static S const b;
   static S const c;
};

S S::a;
S S::b(1);
S S::c(1,2);

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

I see. Thank you.

Too bad we can't initialize static const members in the header for other
builtin types, e.g. char, float, double, etc.. This seems natural to me and
I am surprised that it isn't already allowed.

Andrew J Robb <andrew@localhost.localdomain.screaming.net> wrote in message
news:39F2ADEF.466B5DD4@localhost.localdomain...
> You are allowed to initialise "static const"  "int"/"enum" members in the
> header. All others must be initialised in the implementation.
>
> ---
> [ 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.research.att.com/~austern/csc/faq.html                ]
> [ Note that the FAQ URL has changed!  Please update your bookmarks.     ]
>


---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

The standard actually allows "const integral or const enumeration" types
here, so you should be able to use char, short, long, unsigned long etc.

Followup question: why does the standard not allow floating-point types ?
I can't see why these should be any different to integral types.

- Phil

Gary Hinger wrote in message <39f47d27$1_2@news.nwlink.com>...
>I see. Thank you.
>
>Too bad we can't initialize static const members in the header for other
>builtin types, e.g. char, float, double, etc.. This seems natural to me and
>I am surprised that it isn't already allowed.
>
>Andrew J Robb <andrew@localhost.localdomain.screaming.net> wrote in message
>news:39F2ADEF.466B5DD4@localhost.localdomain...
>> You are allowed to initialise "static const"  "int"/"enum" members in the
>> header. All others must be initialised in the implementation.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Michael Schumacher wrote:

> Followup question: why does the standard not allow floating-point types ?
> I can't see why these should be any different to integral types.

I suppose it's because they didn't want to burden the compiler with having
to be able to do floating point computations.  It's hard to write a compiler that doesn't
do at least integer math internally.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Does the Standard permit this code?

struct S
{
    S();
    S(int);
    S(int,int);

    static S const a();
    static S const b(1);
    static S const c(1,2);
};

In gcc, the declaration of a compiles. The declaration of b produces an
error "storage size of S::b unknown". The declaration of c produces an
internal compiler error.



---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <39f0d222$1_2@news.nwlink.com>,
Gary Hinger <garyh@zipperint.com> wrote:
>Does the Standard permit this code?
>
>struct S
>{
>    S();
>    S(int);
>    S(int,int);
>
>    static S const a();
>    static S const b(1);
>    static S const c(1,2);
>};
>
>In gcc, the declaration of a compiles.

Right, it declares a function.

>The declaration of b produces an
>error "storage size of S::b unknown". The declaration of c produces an
>internal compiler error.

These two are errors, as you are trying to provide initializers
(in particular for a class based object) in the class.

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]