Anthony Williams <anthwil@nortelnetworks.com> escribi=F3 en el mensaje de
noticias 9qe55n$n8mb1$1@ID-49767.news.dfncis.de...
> [SNIP]
> > >
> > >template<typename T>
> > >void f(T&){}
> > >
> > >void myfunc()
> > >{
> > >    f(static_cast<const int&>(3)); //C
> > >}
> > >
>
> [SNIP]
>
> Given this paragraph, I accept that lines A (and thus D) and B ignore t=
he
> const (so B and D are errors), however I maintain that line C should be
> legal, returning a reference to a temporary lvalue with the value 3.
>
The problem is not in the static_cast<>.
f() takes a no-const reference. You can't bind a const reference to a
non-const reference.


--
Fernando Cacciola
Sierra s.r.l.
fcacciola@gosierra.com
www.gosierra.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                ]

> "Fernando Cacciola" <fcacciola@gosierra.com> wrote in message
news:9ql3rs$ovhaa$1@ID-44132.news.dfncis.de...
>
> Anthony Williams <anthwil@nortelnetworks.com> escribi    en el mensaje de
> noticias 9qe55n$n8mb1$1@ID-49767.news.dfncis.de...
> > [SNIP]
> > > >
> > > >template<typename T>
> > > >void f(T&){}
> > > >
> > > >void myfunc()
> > > >{
> > > >    f(static_cast<const int&>(3)); //C
> > > >}
> > > >
> >
> > [SNIP]
> >
> > Given this paragraph, I accept that lines A (and thus D) and B ignore
the
> > const (so B and D are errors), however I maintain that line C should be
> > legal, returning a reference to a temporary lvalue with the value 3.
> >
> The problem is not in the static_cast<>.
> f() takes a no-const reference. You can't bind a const reference to a
> non-const reference.

f() is a template. If you pass it a const reference to X, T will be deduced
to be "const X".

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optoelectronics
The opinions expressed in this message are not necessarily those of my
employer



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

Anthony Williams <anthwil@nortelnetworks.com> escribi=F3 en el mensaje de
noticias 9qm1kr$ou59d$1@ID-49767.news.dfncis.de...
> > "Fernando Cacciola" <fcacciola@gosierra.com> wrote in message
> news:9ql3rs$ovhaa$1@ID-44132.news.dfncis.de...
> >
> > Anthony Williams <anthwil@nortelnetworks.com> escribi=F3 en el mensaj=
e de
> > noticias 9qe55n$n8mb1$1@ID-49767.news.dfncis.de...
> > > [SNIP]
> > > > >
> > > > >template<typename T>
> > > > >void f(T&){}
> > > > >
> > > > >void myfunc()
> > > > >{
> > > > >    f(static_cast<const int&>(3)); file://C
> > > > >}
> > > > >
> > >
> > > [SNIP]
> > >
> > > Given this paragraph, I accept that lines A (and thus D) and B igno=
re
> the
> > > const (so B and D are errors), however I maintain that line C shoul=
d
be
> > > legal, returning a reference to a temporary lvalue with the value 3.
> > >
> > The problem is not in the static_cast<>.
> > f() takes a no-const reference. You can't bind a const reference to a
> > non-const reference.
>
> f() is a template. If you pass it a const reference to X, T will be
deduced
> to be "const X".
>
> Anthony
>
Yes, you are right! I overlooked that...(I was so sure that the
static_cast<> should worked that I tried to find the problem somewhere el=
se)
But then, IMHO, you are right: Line C should be legal.

BTW: Borland C++ 5.5.1. seems to agree with Comeau:

int const& cr =3D static_cast<int const&>(3) ; // says: "Cannot cast from
'int' to 'const int&'.

The strange thing is that these lines compile OK in Borland:

int v =3D 3 ;
int const& cr2 =3D static_cast<int const&>(v) ; // says: "Cannot cast fro=
m
'int' to 'const int&'.
int const& i(3);

Regards,

--
Fernando Cacciola
Sierra s.r.l.
fcacciola@gosierra.com
www.gosierra.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                ]

In article <9q6and$macsu$1@ID-49767.news.dfncis.de>,
Anthony Williams <anthwil@nortelnetworks.com> wrote:
>I recently submitted the following code to Comeau C++ Online, which I
>believe should compile OK:
>
>#include <string>
>
>template<typename T>
>void f(T&){}
>
>const int makeConstInt(); //A
>const std::string makeConstString();
>
>void myfunc()
>{
>    f(static_cast<const int>(3)); //B
>    f(static_cast<const int&>(3)); //C
>    f(makeConstInt()); //D
>    f(static_cast<const std::string>(std::string()));
>    f(static_cast<const std::string&>(std::string()));
>    f(makeConstString());
>}
>
>However, Comeau C++ disagrees with me, flagging the lines A,B,C and D marked
>above, on the basis that the "const" on the return type of makeConstInt() is
>ignored, as is the const in "static_cast<const int>", and that
>"static_cast<const int&>" requires an lvalue.
>
>Note that the corresponding lines using "std::string" instead of "int" are
>accepted without question.
>
>Unsurprisingly, Comeau Support stood by their compiler, saying that "this is
>what the Standard says", but were not forthcoming about where.

Well, too be fair, we said a bit more than just that.
But yes, we didn't cite what the Standard said or not.

>5.2.9p2 says:
>"An expression e can be explicitly converted to a type T using a static_cast
>of the form static_cast<T>(e) if the declaration "T t(e);" is wellformed,
>for some invented temporary variable t (8.5). The effect of such an explicit
>conversion is the same as performing the declaration and initialization and
>then using the temporary variable as the result of the conversion."
>
>and
>
>const int& i(3);
>
>is legal, so I don't see why static_cast<const int&>(3) should fail (line
>C). I also don't see where it says that the const is ignored on the return
>type of makeConstInt(), or in static_cast<const int>. Am I missing
>something?

This is true, but as mentioned in our email to you, there are other
issues interacting with it.  Perhaps one underlying theme here is
that even though a const qualified type is distinct from a non-const
qualified type, the represenatation is the same.   So, things follow
from that, like const being ignorable in some cases since it really
ends up having no meaning in some contexts.

For instance, a const'd constant doesn't buy you much.
It should probably even be illegal, but C allows it to be
ignored too, and so here we are.  As well, a whammy that
gets thrown atop all of this is that in C++ we have references,
which are lvalues while at the same time have class based rvalues
which can be considered manipulatable objects (blech) at
some levels.   This means that sometimes the return value
qualifier is significant while other times (with say an int)
is not.

Anyway, some of these sections may help: 3.9.3p1, 3.10p2, 3.10p5
and 3.10p9.   There's probably some others.   There's also probably
aspects to this which is not explicitly stated.
--
Greg Comeau         export ETA: December
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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

In article <9q6and$macsu$1@ID-49767.news.dfncis.de>, Anthony Williams
<anthwil@nortelnetworks.com> writes
>I recently submitted the following code to Comeau C++ Online, which I
>believe should compile OK:
>
>#include <string>
>
>template<typename T>
>void f(T&){}
>
>const int makeConstInt(); //A

const on a value return type has no meaning if the type is a built-in
one. There is significance where a member function returns a UDT by
value.

>const std::string makeConstString();

So it is fine here. It means that only const member functions of string
can be applied directly to the return value.

>
>void myfunc()
>{
>    f(static_cast<const int>(3)); //B
Yes, this is where things begin to look counter intuitive. Unfortunately
there is no such thing as a const value for a built-in type. const is a
property of an lvalue.

>    f(static_cast<const int&>(3)); //C
I am not sure what that one would mean. References are lvalues, '3' is
an rvalue, how do you cast an rvalue to an lvalue?


>    f(makeConstInt()); //D
Same problem as earlier.
>    f(static_cast<const std::string>(std::string()));
>    f(static_cast<const std::string&>(std::string()));
>    f(makeConstString());
>}
>
>However, Comeau C++ disagrees with me, flagging the lines A,B,C and D marked
>above, on the basis that the "const" on the return type of makeConstInt() is
>ignored, as is the const in "static_cast<const int>", and that
>"static_cast<const int&>" requires an lvalue.
>
>Note that the corresponding lines using "std::string" instead of "int" are
>accepted without question.

Yes because there are, IMO, crazy differences between builtin types and
UDTs (actually I exaggerate, they make perfectly good sense they are
just counter intuitive.) That mean that user defined value types can do
things that builtin value types cannot.

>
>Unsurprisingly, Comeau Support stood by their compiler, saying that "this is
>what the Standard says", but were not forthcoming about where.
>
>5.2.9p2 says:
>"An expression e can be explicitly converted to a type T using a static_cast
>of the form static_cast<T>(e) if the declaration "T t(e);" is wellformed,
>for some invented temporary variable t (8.5). The effect of such an explicit
>conversion is the same as performing the declaration and initialization and
>then using the temporary variable as the result of the conversion."

Yes, and if memory serves me correctly exactly that clause came up as a
problem somewhere else recently.

>
>and
>
>const int& i(3);
>
>is legal, so I don't see why static_cast<const int&>(3) should fail (line
>C).

Well tell me what it would mean. please.

Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

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

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:YFmDtKAYD2x7Eweh@ntlworld.com...
> I am not sure what that one would mean. References are lvalues, '3' is
> an rvalue, how do you cast an rvalue to an lvalue?

Well 8.5.3/5 would indicate that a temporary would be created,
copy-initialized from the rvalue, and the reference would bind to the
temporary.

void f(const int&);
int main()
{
    f(1);
}

Clearly does this conversion implicitly.

Further, considering the rvalue/lvalue rules for the expression passed to
static_cast in 5.2.9/2 "The expression e is used as an lvalue if and only if
the initialization uses it as an lvalue."  I'm not sure this is a
disallowed,

As reference initialization from an rvalue is explicitly supported, I'm not
sure why you think this is disallowed in the case of static_cast (I'd lean
towards this being allowed as specified in the standard currently.)

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

"Greg Comeau" <comeau@panix.com> wrote in message
news:9qc7v6$764$1@panix3.panix.com...
> In article <9q6and$macsu$1@ID-49767.news.dfncis.de>,
> Anthony Williams <anthwil@nortelnetworks.com> wrote:
> >I recently submitted the following code to Comeau C++ Online, which I
> >believe should compile OK:
> >
> >#include <string>
> >
> >template<typename T>
> >void f(T&){}
> >
> >const int makeConstInt(); //A
> >const std::string makeConstString();
> >
> >void myfunc()
> >{
> >    f(static_cast<const int>(3)); //B
> >    f(static_cast<const int&>(3)); //C
> >    f(makeConstInt()); //D
> >    f(static_cast<const std::string>(std::string()));
> >    f(static_cast<const std::string&>(std::string()));
> >    f(makeConstString());
> >}
> >
> >However, Comeau C++ disagrees with me, flagging the lines A,B,C and D
marked
> >above, on the basis that the "const" on the return type of makeConstInt()
is
> >ignored, as is the const in "static_cast<const int>", and that
> >"static_cast<const int&>" requires an lvalue.
> >
> >Note that the corresponding lines using "std::string" instead of "int"
are
> >accepted without question.
> >
> >Unsurprisingly, Comeau Support stood by their compiler, saying that "this
is
> >what the Standard says", but were not forthcoming about where.
>
> Well, too be fair, we said a bit more than just that.

I was summarizing (perhaps too harshly)

> But yes, we didn't cite what the Standard said or not.
>
> >5.2.9p2 says:
> >"An expression e can be explicitly converted to a type T using a
static_cast
> >of the form static_cast<T>(e) if the declaration "T t(e);" is wellformed,
> >for some invented temporary variable t (8.5). The effect of such an
explicit
> >conversion is the same as performing the declaration and initialization
and
> >then using the temporary variable as the result of the conversion."
> >
> >and
> >
> >const int& i(3);
> >
> >is legal, so I don't see why static_cast<const int&>(3) should fail (line
> >C). I also don't see where it says that the const is ignored on the
return
> >type of makeConstInt(), or in static_cast<const int>. Am I missing
> >something?
>
> This is true, but as mentioned in our email to you, there are other
> issues interacting with it.  Perhaps one underlying theme here is
> that even though a const qualified type is distinct from a non-const
> qualified type, the represenatation is the same.   So, things follow
> from that, like const being ignorable in some cases since it really
> ends up having no meaning in some contexts.

Just because things have the same representation doesn't make them
equivalent. I can invent other cases where const has no discernible meaning,
but is not ignorable.

> For instance, a const'd constant doesn't buy you much.
> It should probably even be illegal, but C allows it to be
> ignored too, and so here we are.  As well, a whammy that
> gets thrown atop all of this is that in C++ we have references,
> which are lvalues while at the same time have class based rvalues
> which can be considered manipulatable objects (blech) at
> some levels.   This means that sometimes the return value
> qualifier is significant while other times (with say an int)
> is not.

I can cope with literals have non-const type, though I wish they didn't.
However, it really seems incongruous for cv qualifiers to be ignored
inconsistently - either an rvalue return value has its cv qualifier ignored
or it does not, either a "value" function argument has its cv qualifier
ignored or it does not.

> Anyway, some of these sections may help: 3.9.3p1, 3.10p2, 3.10p5
> and 3.10p9.   There's probably some others.   There's also probably
> aspects to this which is not explicitly stated.

Thanks.

3.10p9 is the crucial one for me:

"Class rvalues can have cv-qualified types; non-class rvalues always have
cv-unqualified types. ..."

At least now I have something concrete to argue with <G>

Given this paragraph, I accept that lines A (and thus D) and B ignore the
const (so B and D are errors), however I maintain that line C should be
legal, returning a reference to a temporary lvalue with the value 3.

As stated above, I find this rule "crazy" - either cv-qualifiers are
significant on rvalues or they are not, this half-way house just makes
writing generic template code that bit harder, as there are detectable
differences between UDTs and builtin types.

This is an issue I really think we should sort out for the next revision of
the standard - the interaction of cv qualifiers, literals and rvalues seems
quite unintuitive and inconsistent.

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optoelectronics
The opinions expressed in this message are not necessarily those of my
employer



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

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:YFmDtKAYD2x7Eweh@ntlworld.com...
> In article <9q6and$macsu$1@ID-49767.news.dfncis.de>, Anthony Williams
> <anthwil@nortelnetworks.com> writes
> >I recently submitted the following code to Comeau C++ Online, which I
> >believe should compile OK:
> >
> >#include <string>
> >
> >template<typename T>
> >void f(T&){}
> >
> >const int makeConstInt(); //A
>
> const on a value return type has no meaning if the type is a built-in
> one. There is significance where a member function returns a UDT by
> value.
>
> >const std::string makeConstString();
>
> So it is fine here. It means that only const member functions of string
> can be applied directly to the return value.
>
> >
> >void myfunc()
> >{
> >    f(static_cast<const int>(3)); //B
> Yes, this is where things begin to look counter intuitive. Unfortunately
> there is no such thing as a const value for a built-in type. const is a
> property of an lvalue.
>
> >    f(static_cast<const int&>(3)); //C
> I am not sure what that one would mean. References are lvalues, '3' is
> an rvalue, how do you cast an rvalue to an lvalue?

Const lvalues can always be bound to an rvalue, it just may involve an
intermediate temporary.

> >    f(makeConstInt()); //D
> Same problem as earlier.
> >    f(static_cast<const std::string>(std::string()));
> >    f(static_cast<const std::string&>(std::string()));
> >    f(makeConstString());
> >}
> >
> >However, Comeau C++ disagrees with me, flagging the lines A,B,C and D
marked
> >above, on the basis that the "const" on the return type of makeConstInt()
is
> >ignored, as is the const in "static_cast<const int>", and that
> >"static_cast<const int&>" requires an lvalue.
> >
> >Note that the corresponding lines using "std::string" instead of "int"
are
> >accepted without question.
>
> Yes because there are, IMO, crazy differences between builtin types and
> UDTs (actually I exaggerate, they make perfectly good sense they are
> just counter intuitive.) That mean that user defined value types can do
> things that builtin value types cannot.
>
> >
> >Unsurprisingly, Comeau Support stood by their compiler, saying that "this
is
> >what the Standard says", but were not forthcoming about where.
> >
> >5.2.9p2 says:
> >"An expression e can be explicitly converted to a type T using a
static_cast
> >of the form static_cast<T>(e) if the declaration "T t(e);" is wellformed,
> >for some invented temporary variable t (8.5). The effect of such an
explicit
> >conversion is the same as performing the declaration and initialization
and
> >then using the temporary variable as the result of the conversion."
>
> Yes, and if memory serves me correctly exactly that clause came up as a
> problem somewhere else recently.
>
> >
> >and
> >
> >const int& i(3);
> >
> >is legal, so I don't see why static_cast<const int&>(3) should fail (line
> >C).
>
> Well tell me what it would mean. please.

Exactly the same as

const int otherwise_unnamed_temporary(3);
const int& i(otherwise_unnamed_temporary);

and

static_cast<const int&>(otherwise_unnamed_temporary)

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optoelectronics
The opinions expressed in this message are not necessarily those of my
employer



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

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message news:<YFmDtKAYD2x7Eweh@ntlworld.com>...
> In article <9q6and$macsu$1@ID-49767.news.dfncis.de>, Anthony Williams
> <anthwil@nortelnetworks.com> writes
> >5.2.9p2 says:
> >"An expression e can be explicitly converted to a type T using a static_cast
> >of the form static_cast<T>(e) if the declaration "T t(e);" is wellformed,
> >for some invented temporary variable t (8.5). The effect of such an explicit
> >conversion is the same as performing the declaration and initialization and
> >then using the temporary variable as the result of the conversion."
>
> Yes, and if memory serves me correctly exactly that clause came up as a
> problem somewhere else recently.
>
> >
> >and
> >
> >const int& i(3);
> >
> >is legal, so I don't see why static_cast<const int&>(3) should fail (line
> >C).
>
> Well tell me what it would mean. please.

Exactly what the paragraph cited above says?

--
Peter Dimov
Multi Media Ltd.

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

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message news:<YFmDtKAYD2x7Eweh@ntlworld.com>...
> In article <9q6and$macsu$1@ID-49767.news.dfncis.de>, Anthony Williams
> <anthwil@nortelnetworks.com> writes
> >5.2.9p2 says:
> >"An expression e can be explicitly converted to a type T using a static_cast
> >of the form static_cast<T>(e) if the declaration "T t(e);" is wellformed,
> >for some invented temporary variable t (8.5). The effect of such an explicit
> >conversion is the same as performing the declaration and initialization and
> >then using the temporary variable as the result of the conversion."

[snip]

> >
> >and
> >
> >const int& i(3);
> >
> >is legal, so I don't see why static_cast<const int&>(3) should fail (line
> >C).
>
> Well tell me what it would mean. please.

Are you saying that the last sentence of 5.2.9p2 which you quoted
above is not explicit enough? Or what?

Mark Williams

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

"Anthony Williams" <anthwil@nortelnetworks.com> wrote in message news:<9qe55n$n8mb1$1@ID-49767.news.dfncis.de>...
[...]
> As stated above, I find this rule "crazy" - either cv-qualifiers are
> significant on rvalues or they are not, this half-way house just makes
> writing generic template code that bit harder, as there are detectable
> differences between UDTs and builtin types.
>
> This is an issue I really think we should sort out for the next revision of
> the standard - the interaction of cv qualifiers, literals and rvalues seems
> quite unintuitive and inconsistent.

I agree. Here's a proposal:

"For the purposes of reference binding, rvalues are considered const."

--
Peter Dimov
Multi Media Ltd.

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

I recently submitted the following code to Comeau C++ Online, which I
believe should compile OK:

#include <string>

template<typename T>
void f(T&){}

const int makeConstInt(); //A
const std::string makeConstString();

void myfunc()
{
    f(static_cast<const int>(3)); //B
    f(static_cast<const int&>(3)); //C
    f(makeConstInt()); //D
    f(static_cast<const std::string>(std::string()));
    f(static_cast<const std::string&>(std::string()));
    f(makeConstString());
}

However, Comeau C++ disagrees with me, flagging the lines A,B,C and D marked
above, on the basis that the "const" on the return type of makeConstInt() is
ignored, as is the const in "static_cast<const int>", and that
"static_cast<const int&>" requires an lvalue.

Note that the corresponding lines using "std::string" instead of "int" are
accepted without question.

Unsurprisingly, Comeau Support stood by their compiler, saying that "this is
what the Standard says", but were not forthcoming about where.

5.2.9p2 says:
"An expression e can be explicitly converted to a type T using a static_cast
of the form static_cast<T>(e) if the declaration "T t(e);" is wellformed,
for some invented temporary variable t (8.5). The effect of such an explicit
conversion is the same as performing the declaration and initialization and
then using the temporary variable as the result of the conversion."

and

const int& i(3);

is legal, so I don't see why static_cast<const int&>(3) should fail (line
C). I also don't see where it says that the const is ignored on the return
type of makeConstInt(), or in static_cast<const int>. Am I missing
something?

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optoelectronics
The opinions expressed in this message are not necessarily those of my
employer


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