In article <8uqebu$j5q$1@mulga.cs.mu.OZ.AU>,
  fjh@cs.mu.OZ.AU (Fergus Henderson) wrote:
> comeau@panix.com (Greg Comeau) writes:

> >James.Kanze@dresdner-bank.com wrote:
> >>In fact, the conversion may trap -- what should the compiler
> >>generate in such cases?

> >I'd have to look this all up, but I'm pretty sure it can do what it
> >wants at that point.

> Since the conversion occurs in a constant-expression, the program is
> ill-formed, and so a diagnostic is required.

> See 5[expr] paragraph 5:

>  |    -5- If during the evaluation of an expression, the result is not
>  |    mathematically defined or not in the range of representable
values for
>  |    its type, the behavior is undefined, unless such an expression
is a
>  |    constant expression (expr.const), in which case the program is
>  |    ill-formed.

That would be fine if the result were not in the range of
representable values for its type.  The operation in question is an
implicit type conversion of a long to char.  The results of the
conversion *are* in the range, by definition.  If char is unsigned,
they are defined as the value modulo UCHAR_MAX+1.  If char is signed,
they are implementation defined.  (Interesting: could an
implementation define the results to be ULONG_MAX, and then invoke
this paragraph to do whatever it wanted.)

See 4.7/3.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


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.     ]

In article <47hs0t0buv6mf3nb0jh275rhl09rc3qd1f@4ax.com>,
Eric Nagler  <ericnagler@earthlink.net> wrote:
>>(1) You haven't include <typeinfo>, so the definition of the
>>type_info class isn't visible at that point.
>
>Well, with or without <typeinfo> the Borland compiler 5.5.1 yields
>'long', whereas VC++ always yields 'char'.

Comeau will kick it out unless you #include <typeinfo>
(perhaps there should be some allowance for magic here,
but I'm certain the committee explicitly reviewed this
during the draft stage).

>>> int main()
>>> {
>>>   long const data = 123456789L;
>>>   foo<data>();
>>
>>(2) data does not fit in a char.
>
>Isn't this an implicit type conversion, even though it doesn't "fit"?

Yes, but what does it not fitting mean?  (BTW, Comeau generates
a warning here).

>So who is right: Borland, Microsoft, Metroworks???

Unfortunately, there two aspect here:
1) As Valentin pointed out, the code is ill-formed.  But
   compilers can continue translation and generate code.
2) The result of .name() is implementation defined.

Therefore it seems all compilers are correct.
I would prefer those that output "char" though
(Comeau C++ does BTW) as a QoI issue.

- 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.     ]

Greg Comeau wrote:
>
> In article <skjq0to2es960ncn4rcp63p9ihd96bbb2g@4ax.com>,
> Eric Nagler  <ericnagler@earthlink.net> wrote:
> >I was shocked, stunned, and amazed that this program printed "long". I
> >would have thought that the 'long' data type would be converted to
> >'char' when foo() is called. I guess that the type of a value-based
> >template parameter makes no difference whatsoever, provided that it's
> >integral. Your thoughts, please.
> >
> >#include <iostream>
> >
> >template <char x>
> >void foo()
> >{
> >  std::cout << typeid(x).name() << std::endl;      // long
> >}
> >
> >int main()
> >{
> >  long const data = 123456789L;
> >  foo<data>();
> >}
>
> Of course there is supposed to be a conversion from long to char,
> but of course too, what .name() returns is implementation-defined... :(

Therefore, the relevant test is typeid(x)==typeid(char). Unless I'm
missing something, that has to be true for a conforming implementation,
and is unlikely to be true for the implementation that gave him that
printout. Still - Eric, could you check to see what that test gives?

---
[ 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.     ]

James Kuyper wrote:
>
> Greg Comeau wrote:
> >
> > In article <skjq0to2es960ncn4rcp63p9ihd96bbb2g@4ax.com>,
> > Eric Nagler  <ericnagler@earthlink.net> wrote:
> > >I was shocked, stunned, and amazed that this program printed "long". I
> > >would have thought that the 'long' data type would be converted to
> > >'char' when foo() is called. I guess that the type of a value-based
> > >template parameter makes no difference whatsoever, provided that it's
> > >integral. Your thoughts, please.
> > >
> > >#include <iostream>
> > >
> > >template <char x>
> > >void foo()
> > >{
> > >  std::cout << typeid(x).name() << std::endl;      // long
> > >}
> > >
> > >int main()
> > >{
> > >  long const data = 123456789L;
> > >  foo<data>();
> > >}
> >
> > Of course there is supposed to be a conversion from long to char,
> > but of course too, what .name() returns is implementation-defined... :(
>
> Therefore, the relevant test is typeid(x)==typeid(char). Unless I'm
> missing something, that has to be true for a conforming implementation,
> and is unlikely to be true for the implementation that gave him that
> printout. Still - Eric, could you check to see what that test gives?

Given that the conversion caused an illegal program due to
overflow, AFAIK the compiler can return what it wants (because
since it's not compiling legal C++ anymore, it isn't bound by
the standard). Of course, a quality compiler which decides to
translate the code anyway would minimize the deviation of the
standard by giving true anyways.

Of course, if the constant is changed to 1L, the result
has to be the value true.

---
[ 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 <8uoros$ppt$1@nnrp1.deja.com>,
 <James.Kanze@dresdner-bank.com> wrote:
>In article <8ulamm$pa8$1@panix3.panix.com>,
>  comeau@comeaucomputing.com wrote:
>> In article <skjq0to2es960ncn4rcp63p9ihd96bbb2g@4ax.com>,
>> Eric Nagler  <ericnagler@earthlink.net> wrote:
>> >I was shocked, stunned, and amazed that this program printed
>> >"long"...
>> >template <char x>
>> >void foo()
>> >{
>> >  std::cout << typeid(x).name() << std::endl;      // long
>> >}
>> >...
>> >  long const data = 123456789L;
>> >  foo<data>();
>> Of course there is supposed to be a conversion from long to char,
>> but of course too, what .name() returns is implementation-defined...
>> :(
>
>As are the results of the conversion from long to char.

At least they usually are.

>In fact, the conversion may trap -- what should the compiler generate
>in such cases?

I'd have to look this all up, but I'm pretty sure it can
do what it wants at that point.

- 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.     ]

>Therefore, the relevant test is typeid(x)==typeid(char). Unless I'm
>missing something, that has to be true for a conforming implementation,
>and is unlikely to be true for the implementation that gave him that
>printout. Still - Eric, could you check to see what that test gives?

My contact at Borland/Inprise confirms that displaying 'long' is a
Borland bug.

---
[ 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 <3A0F7854.F4AFC7E3@wizard.net>,
James Kuyper  <kuyper@wizard.net> wrote:
>Greg Comeau wrote:
>> In article <skjq0to2es960ncn4rcp63p9ihd96bbb2g@4ax.com>,
>> Eric Nagler  <ericnagler@earthlink.net> wrote:
>> >I was shocked, stunned, and amazed that this program printed "long"....
>> >...
>> >template <char x>
>> >void foo()
>> >{
>> >  std::cout << typeid(x).name() << std::endl;      // long
>> >}
>> >...
>> >  long const data = 123456789L;
>> >  foo<data>();
>>
>> Of course there is supposed to be a conversion from long to char,
>> but of course too, what .name() returns is implementation-defined... :(
>
>Therefore, the relevant test is typeid(x)==typeid(char). Unless I'm
>missing something, that has to be true for a conforming implementation,
>and is unlikely to be true for the implementation that gave him that
>printout.

Ignoring the issue about the possible truncation of the long
(let's assume it's = 0L...), then yes, I believe that's
an accurate assessment, although that doesn't help Eric directly.

>Still - Eric, could you check to see what that test gives?

Eric, you still out there?

- 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.     ]

comeau@panix.com (Greg Comeau) writes:

>James.Kanze@dresdner-bank.com wrote:
>>In fact, the conversion may trap -- what should the compiler generate
>>in such cases?
>
>I'd have to look this all up, but I'm pretty sure it can
>do what it wants at that point.

Since the conversion occurs in a constant-expression, the program is
ill-formed, and so a diagnostic is required.

See 5[expr] paragraph 5:

 |    -5- If during the evaluation of an expression, the result is not
 |    mathematically defined or not in the range of representable values for
 |    its type, the behavior is undefined, unless such an expression is a
 |    constant expression (expr.const), in which case the program is
 |    ill-formed.

--
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 <8un7cf$7ud$1@panix3.panix.com>,
  comeau@comeaucomputing.com wrote:
> In article <47hs0t0buv6mf3nb0jh275rhl09rc3qd1f@4ax.com>,
> Eric Nagler  <ericnagler@earthlink.net> wrote:
> >>(1) You haven't include <typeinfo>, so the definition of the
> >>type_info class isn't visible at that point.
> >
> >Well, with or without <typeinfo> the Borland compiler 5.5.1 yields
> >'long', whereas VC++ always yields 'char'.

> Comeau will kick it out unless you #include <typeinfo> (perhaps
> there should be some allowance for magic here, but I'm certain the
> committee explicitly reviewed this during the draft stage).

There was an #include <iostream> at the top of the program, I think.
Maybe <iostream> includes <typeinfo>.  (I is allowed to, but not
required to.)

> >>> int main()
> >>> {
> >>>   long const data = 123456789L;
> >>>   foo<data>();

> >>(2) data does not fit in a char.

> >Isn't this an implicit type conversion, even though it doesn't "fit"?

> Yes, but what does it not fitting mean?  (BTW, Comeau generates
> a warning here).

Definitly permitted (but not required) by the standard:-).  From a
quality of implementation point of view, I like the warning.

> >So who is right: Borland, Microsoft, Metroworks???
>
> Unfortunately, there two aspect here:
> 1) As Valentin pointed out, the code is ill-formed.  But
>    compilers can continue translation and generate code.

I don't think the code is ill-formed.  I'm not sure what happens with
templates, but there is nothing ill-formed about assigning the value
to a char.  The results aren't specified, but that doesn't make the
program ill-formed.  I would expect the compiler to use the same value
to instantiate the template that I would receive if I assigned the
value to a char (for example).  For implementations where the
assignment would trap, I have no idea what the compiler should do.


> 2) The result of .name() is implementation defined.

> Therefore it seems all compilers are correct.
> I would prefer those that output "char" though
> (Comeau C++ does BTW) as a QoI issue.

In practice, I don't think that any compiler returns "long" for
typeid(char).name(), although it is certainly legal.  Rigorously
speaking, of course, we'd need to instantiate the template once on the
large value, and once on a value that fitted, and then verify that a
typeid of the two instantiation types was equal.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


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.     ]

In article <8upr9u$1vp$1@panix3.panix.com>,
  comeau@comeaucomputing.com wrote:
> In article <8uoros$ppt$1@nnrp1.deja.com>,
>  <James.Kanze@dresdner-bank.com> wrote:
> >In article <8ulamm$pa8$1@panix3.panix.com>,

> >> Of course there is supposed to be a conversion from long to char,
> >> but of course too, what .name() returns is
> >> implementation-defined...  :(

> >As are the results of the conversion from long to char.

> At least they usually are.

According to the C++ standard (4.7/3): "If the destination type is
signed, the value is unchanged if it can be represented in the
destination type; otherwise the value is implementation-defined."
>From memory, C90 said something similar, except that I think it says
undefined, rather than implementation-defined.  C99 states that
"Othersize, the new type is signed and the value cannot be represented
in it; either the result is implementation-defined or an
implement-defined signal is raised."

Interesting that all three standards say something different.  I think
that the wording in C99 is the result of a demand for interpretation.
C90 said that the *value* was undefined, but many people (myself
included) interpreted this as undefined behavior.

Anyway, according to the C++ standard, the *value* is
implementation-defined, which means that 1) the conversion must return
a value (no signalling allowed!), and 2) the compiler documentation
must specify it, either as a table, or more likely, by describing what
happens.  (Something along the lines of "This implemenation uses 2's
complement for negative integral values, with all bits significant.
In case of integral conversions where the value does not fit in the
destination type, the low order bits will be used as-is, with no
attempt to maintain sign or value.")

> >In fact, the conversion may trap -- what should the compiler generate
> >in such cases?

> I'd have to look this all up, but I'm pretty sure it can do what it
> wants at that point.

I just looked it up.  This is a difference between C and C++: in C,
and implementation can signal, in C++ no.  In C++, an implementation
could reasonably always return INT_MAX (or INT_MIN for negative
values).  Or even always 42.  Provided they document the fact.

Since they can't signal, the problem of what to do in this case is
clear: the template is instantiated, and the value seen is that of
whatever the implementation returns when converting the value to char.

Rest the problem: are foo< 100000 > and foo< 100001 > the same type,
or different types?  I'll vote for the same.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


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.     ]

In article <3A103A88.44352A8B@physik.tu-muenchen.de>,
  Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:

> Given that the conversion caused an illegal program due to overflow,
> AFAIK the compiler can return what it wants (because since it's not
> compiling legal C++ anymore, it isn't bound by the standard).

There is no overflow involved, at least in the sense the standard uses
overflow (as the results of an arithmetic operation).  There is an
integral type conversion.  If the value doesn't fit in the target
type, the results are defined by the standard for unsigned types, and
are implementation-defined for signed types.

In this case, the target type is char.  Whether char is signed or
unsigned is implementation-defined.

> Of course, a quality compiler which decides to translate the code
> anyway would minimize the deviation of the standard by giving true
> anyways.

A conformant compiler is required to translate the code, and to always
give true.  A quality compiler *will* generate a warning.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


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.     ]

On Mon, 13 Nov 2000 18:10:08 GMT, James Kuyper <kuyper@wizard.net>
wrote:

>> Of course there is supposed to be a conversion from long to char,
>> but of course too, what .name() returns is implementation-defined... :(
>
>Therefore, the relevant test is typeid(x)==typeid(char). Unless I'm
>missing something, that has to be true for a conforming implementation,
>and is unlikely to be true for the implementation that gave him that
>printout. Still - Eric, could you check to see what that test gives?

Adding this line to foo():
   std::cout << (typeid(x) == typeid(char)) << std::endl;
produces false for Borland, true for Microsoft.

---
[ 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 <8un1qi$2pfr$1@nef.ens.fr>,
  Valentin.Bonnard@free.fr (Valentin Bonnard) wrote:
> Eric Nagler  wrote:
> >>(1) You haven't include <typeinfo>, so the definition of the
> >>type_info class isn't visible at that point.

> > Well, with or without <typeinfo>

> Not surprising...

> > the Borland compiler 5.5.1 yields
> > 'long', whereas VC++ always yields 'char'.

> I am surprised. Very surprised. Even astonished.

> >>> int main()
> >>> {
> >>>   long const data = 123456789L;
> >>>   foo<data>();
> >>
> >>(2) data does not fit in a char.

> > Isn't this an implicit type conversion, even though it doesn't
> > "fit"?

> Of course there is one, but 123456789L doesn't fit into a char, so
> your program is ill-formed,

Are you sure?  Or is it just the results which are undefined (or
unspecified)?

> and gcc correctly reports that:

> quatramaran bonnard ~/C++/core $ g++ char-template-parameter.cc
> char-template-parameter.cc: In function `int main()':
> char-template-parameter.cc:13: warning: overflow in implicit constant
> conversion
> quatramaran bonnard ~/C++/core $

> Any compiler which doesn't report the error in the program is
> broken.

>From a quality of implementation point of view, I fully agree.
According to the standard, I don't think it is required.  Notice that
g++ only gives a warning.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


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.     ]

I was shocked, stunned, and amazed that this program printed "long". I
would have thought that the 'long' data type would be converted to
'char' when foo() is called. I guess that the type of a value-based
template parameter makes no difference whatsoever, provided that it's
integral. Your thoughts, please.

#include <iostream>

template <char x>
void foo()
{
  std::cout << typeid(x).name() << std::endl;      // long
}

int main()
{
  long const data = 123456789L;
  foo<data>();
}

---
[ 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 <skjq0to2es960ncn4rcp63p9ihd96bbb2g@4ax.com>, Eric Nagler
<ericnagler@earthlink.net> wrote:

| I was shocked, stunned, and amazed that this program printed "long". I
| would have thought that the 'long' data type would be converted to
| 'char' when foo() is called. I guess that the type of a value-based
| template parameter makes no difference whatsoever, provided that it's
| integral. Your thoughts, please.
|
| #include <iostream>
|
| template <char x>
| void foo()
| {
|   std::cout << typeid(x).name() << std::endl;      // long
| }
|
| int main()
| {
|   long const data = 123456789L;
|   foo<data>();
| }

Prints "char" for me (Metrowerks CodeWarrior Pro 6).

-Howard

---
[ 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.     ]

Eric Nagler  wrote:
> I was shocked, stunned, and amazed that this program printed "long". I
> would have thought that the 'long' data type would be converted to
> 'char' when foo() is called. I guess that the type of a value-based
> template parameter makes no difference whatsoever, provided that it's
> integral. Your thoughts, please.

Indeed, only the type declared in the template counts. But your program
is ill-formed for two reasons:

> #include <iostream>
>
> template <char x>
> void foo()
> {
>   std::cout << typeid(x).name() << std::endl;      // long
                           ^^^^^^
(1) You haven't include <typeinfo>, so the definition of the
type_info class isn't visible at that point.

> }
>
> int main()
> {
>   long const data = 123456789L;
>   foo<data>();

(2) data does not fit in a char.

> }

--

Valentin Bonnard

---
[ 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.     ]

>(1) You haven't include <typeinfo>, so the definition of the
>type_info class isn't visible at that point.

Well, with or without <typeinfo> the Borland compiler 5.5.1 yields
'long', whereas VC++ always yields 'char'.

>> int main()
>> {
>>   long const data = 123456789L;
>>   foo<data>();
>
>(2) data does not fit in a char.

Isn't this an implicit type conversion, even though it doesn't "fit"?

So who is right: Borland, Microsoft, Metroworks???

---
[ 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 <skjq0to2es960ncn4rcp63p9ihd96bbb2g@4ax.com>,
Eric Nagler  <ericnagler@earthlink.net> wrote:
>I was shocked, stunned, and amazed that this program printed "long". I
>would have thought that the 'long' data type would be converted to
>'char' when foo() is called. I guess that the type of a value-based
>template parameter makes no difference whatsoever, provided that it's
>integral. Your thoughts, please.
>
>#include <iostream>
>
>template <char x>
>void foo()
>{
>  std::cout << typeid(x).name() << std::endl;      // long
>}
>
>int main()
>{
>  long const data = 123456789L;
>  foo<data>();
>}

Of course there is supposed to be a conversion from long to char,
but of course too, what .name() returns is implementation-defined... :(

- 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.     ]

Eric Nagler  wrote:
>>(1) You haven't include <typeinfo>, so the definition of the
>>type_info class isn't visible at that point.
>
> Well, with or without <typeinfo>

Not surprising...

> the Borland compiler 5.5.1 yields
> 'long', whereas VC++ always yields 'char'.

I am surprised. Very surprised. Even astonished.

>>> int main()
>>> {
>>>   long const data = 123456789L;
>>>   foo<data>();
>>
>>(2) data does not fit in a char.
>
> Isn't this an implicit type conversion, even though it doesn't "fit"?

Of course there is one, but  123456789L doesn't fit into a
char, so your program is ill-formed, and gcc correctly
reports that:

quatramaran bonnard ~/C++/core $ g++ char-template-parameter.cc
char-template-parameter.cc: In function `int main()':
char-template-parameter.cc:13: warning: overflow in implicit constant
conversion
quatramaran bonnard ~/C++/core $



Any compiler which doesn't report the error in the program
is broken.

--

Valentin Bonnard

---
[ 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 <8ulamm$pa8$1@panix3.panix.com>,
  comeau@comeaucomputing.com wrote:
> In article <skjq0to2es960ncn4rcp63p9ihd96bbb2g@4ax.com>,
> Eric Nagler  <ericnagler@earthlink.net> wrote:
> >I was shocked, stunned, and amazed that this program printed
> >"long". I would have thought that the 'long' data type would be
> >converted to 'char' when foo() is called. I guess that the type of
> >a value-based template parameter makes no difference whatsoever,
> >provided that it's integral. Your thoughts, please.

> >#include <iostream>

> >template <char x>
> >void foo()
> >{
> >  std::cout << typeid(x).name() << std::endl;      // long
> >}

> >int main()
> >{
> >  long const data = 123456789L;
> >  foo<data>();
> >}

> Of course there is supposed to be a conversion from long to char,
> but of course too, what .name() returns is implementation-defined...
> :(

As are the results of the conversion from long to char.  In fact, the
conversion may trap -- what should the compiler generate in such
cases?

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


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.     ]

Eric Nagler <ericnagler@earthlink.net> writes:

|>  >(1) You haven't include <typeinfo>, so the definition of the=20
|>  >type_info class isn't visible at that point.

|>  Well, with or without <typeinfo> the Borland compiler 5.5.1 yields
|>  'long', whereas VC++ always yields 'char'.

|>  >> int main()
|>  >> {
|>  >>   long const data =3D 123456789L;
|>  >>   foo<data>();

|>  >(2) data does not fit in a char.

|>  Isn't this an implicit type conversion, even though it doesn't
|>  "fit"?

Yes. But the results of the conversion are not specified, and can result
in a trap.

Given that in this case, the converion is of a compile time constant
(and it must be, in order to instantiate a template), I would expect at
least a compiler warning.  I think, but I wouldn't swear to it, that the
compiler is allowed to generate an error, and refuse to compile the
program -- if the run-time behavior of the conversion traps, what value
should the compiler use?

|>  So who is right: Borland, Microsoft, Metroworks???

Whoever says char is certainly closest to the intent of the standard.
Since this *is* comp.STD.c++, however, I would be amiss if I didn't
point out that the standard makes no requirements as to the actual
contents of the string involved; there is no violation of the standard
if typeinfo<char>.name() returns "long".

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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.     ]