David Vandevoorde wrote:
> But (as several people pointed out before me) this is a very limited
> problem since it does not participate in interface elements (unlike,
> e.g., the `bool' type). Off hand, the only reason I can see for
> standardization is a slight improvement in readability (offset by the
> need to teach yet another C++ concept). In this case, I do not find
> that a persuasive argument.

Perhaps there are no reason why implicit_cast should be in the standard
(I don't think so, but let say there aren't any).

But is there any reason why it should not be std ?

Anyway I think the reasons are:

1) std name (readability); what you said about the need to learn one
more concept isn't IMO significant: when all the style of cast have
been learnt, everyone must understand that some may be implicit and
the others not.

2) to have all the others casts and not implicit_ is strange

3) It is needed (not to say it is strictly needed, but it will (could)
be used by *all* C++ programmers)

4..n) all arguments that apply to the other new-style cast apply here

I think the arguments against implicit_cast apply to reinterpret,
const, static and (less) to dynamic _casts, so there is no question
for me if they are valid: implicit is not that different from the
others.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Pablo Halpern wrote:
> Valentin Bonnard <bonnardv@pratique.fr> wrote:
> >implicit_cast<T>(x) is NOT standard (by the way, why ?).
>
> Why should it be. As Timo says, what is the point in explicitly casting
> something and then calling it *implicit*. Once you use implicit_cast<>
> it's not implicit anymore, is it? Maybe what you want is something like
> explicit_cast<>, which already exists. It's called static_cast<>. What
> would implicit_cast<> do that static_cast<> does not already do?

When I write implicit_cast, I want implicit_cast, not explicit_cast
(which can be static_cast, const_cast, reinterpet_cast or a
combination).

There are cases you want to convert<> to anothere type (not cast); for
example convert<float>(i)/j if i and j are long. (Or the other way
arround convert<float>(x)/y when w and y are float.)

The reason why I certainly don't want to use static_cast is that
static_cast<BaseType*>(&derived) where derived is of type int is
well-formed IMO.

BTW: what the result in this case ?
-----------------------------------

I can write my own convert (when I'll have the compiler) but it should
really be a standard cast/part of the library because else everyone
will give it different names (implicit_cast, safe_cast, convert) and
different definitions.

Also to have static/const/reinterpret casts and no implicit is
inconsistent.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>>>>> "VB" == Valentin Bonnard <bonnardv@pratique.fr> writes:
[...]
VB> I can write my own convert (when I'll have the compiler) but it
VB> should really be a standard cast/part of the library because else
VB> everyone will give it different names (implicit_cast, safe_cast,
VB> convert) and different definitions.

But (as several people pointed out before me) this is a very limited
problem since it does not participate in interface elements (unlike,
e.g., the `bool' type). Off hand, the only reason I can see for
standardization is a slight improvement in readability (offset by the
need to teach yet another C++ concept). In this case, I do not find
that a persuasive argument.

 Daveed



[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]