Valentin Bonnard wrote:
>
> Timo Geusch wrote (in c.l.c.m):
> >
> > I just checked my copy of the C++ draft standard I have and did not find
> > any reference to an implicit_cast. IMHO, implicit cast are those cast
> > performed by the compiler all by itself. That's why I suppose there should
> > not be any keyword/operator for explicitly calling for a cast. (Kind of
> > confusing, isn't it ? EXPLICITLY ordering the compiler to execute an
> > IMPLICIT cast 8-)).
>
> implicit_cast<T>(x) is NOT standard (by the way, why ?).
>
> With a good compiler, you can easily define one:
>
> template <class From, class To>
> inline To  implicit_cast<To>(From x) // I'm not sure about the synatx
>                                      // my compiler doesn't support
> {                                    // that anyway
>     return x;
> }

This will not work as expected, if protection comes into play:

class A {};

void f(A* a);

class B: private A
{
  B();
};

B::B()
{
  f(this); // ok, B is an A in the scope of B
  f(implicit_cast<A*>(this)); // error: in the scope of implicit_cast
                              // B is not an A (private inheritance!)
}

Now, should implicit_cast<A,B> be made a friend of B?
No, because then you can do

void g()
{
  B* b;
  f(b); // error: B is not (publicly) an A
  f(implicit_cast<A*>(b)); ok: implicit_cast<A,B> is friend of B
};

The solution I see would be:

template<class To> inline To implicit_cast(To t) { return t; }

so that the cast is performed in the callers scope instead of the
scope of implicit_cast itself. If I understand templates correctly,
this will still allow you to call it as implicit_cast<To>(my_object),
forcing my_object being casted to type To in the caller's scope.

This template differs from the previous solution, as you now are able
to call implicit_cast(my_object), which would not do any cast, but just
make a copy of your object (or a slicing, if you call it as
implicit_cast(*BasePtr), where BasePtr points to an derived type).
---
[ 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                             ]

Chelly Green <chelly@eden.com> wrote:

>Pablo Halpern wrote:
>>
>> Once you use implicit_cast<> it's not implicit anymore, is it?
>
>OK, so maybe it should be called
>explicit_cast_even_though_it_only_involves_implicit_conversions<>? or
>explicit_implicit_cast<>? Those don't seem much better.
>
>> Maybe what you want is something like explicit_cast<>, which already
>> exists.
>
>Not to my knowledge.
>
>> It's called static_cast<>.
>
>Sorry, we DO NOT want static_cast<>! Conversions through static_cast<>
>are not safe. static_cast<Derived*> (base_pointer) is invalid if
>base_pointer doesn't point to Derived (or something derived from that).
>An implicit_cast<> is illegal in this case.

I see. Unfortunately I did not see the other thread with a similar
subject line until *after* I had responded. I now see the need for
something like implicit_cast<>. I really hate that name, though, and
would prefer something like convert<> or convert_cast<> or
conversion_cast<>. Whether it is in the library as a template or built
into the core language doesn't much matter (although I would hate to
have to say "using std::conversion_cast").

Given the lateness of the standardization process, we might need a
different outlet for this and similar frustrations. Perhaps somebody
could organize an on-line committee that would maintain a library of
quasi-standard libraries like conversion_cast<> and auto_array_ptr<>.
Somehow, the committee would have to be empowered to make autocratic
decisions about what went into the library after limited debate so that
the whole thing doesn't become another ISO standardization effort.
Perhaps discussing the contents of this library could be added to the
charter of comp.std.c++ or else a new newsgroup could be created. I
prefer the former, since much of the content of the library would be
things that "should" have been in the standard but didn't make it.
Example: STL-compatable hash set and map containers.

The advantage of such a quasi-standard library is that we get naming and
usage conventions. We wouldn't have one outfit using implict_cast<> and
another using conversion_cast<>, etc. Life would have been easier if we
had had this for bool a long time ago.

Any volunteers? Any ideas about how such a thing might work?

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
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         ]
[ 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                             ]

Valentin Bonnard wrote:
>
> Timo Geusch wrote (in c.l.c.m):
> >
> > I just checked my copy of the C++ draft standard I have and did not find
> > any reference to an implicit_cast. IMHO, implicit cast are those cast
> > performed by the compiler all by itself. That's why I suppose there should
> > not be any keyword/operator for explicitly calling for a cast. (Kind of
> > confusing, isn't it ? EXPLICITLY ordering the compiler to execute an
> > IMPLICIT cast 8-)).
>
> implicit_cast<T>(x) is NOT standard (by the way, why ?).
>
> With a good compiler, you can easily define one:
>
> template <class From, class To>
> inline To  implicit_cast<To>(From x) // I'm not sure about the synatx
>                                      // my compiler doesn't support
> {                                    // that anyway
>     return x;
> }
>
> The problem is that if everyone define its implicit_cast there will be
> multiple-defined errors, so I think it should be standard.
>
> I thing even static_cast, const_cast and dynamic_cast can be defined
> by the user.
>
> Example:
>
> template <class To>
> inline To*  const_cast<To*>(const volatile To* x)
> {
>     return (To*)x;
> }

No, this does not do the same thing as const_cast. const_cast only
allows you to change const and volative qualifiers. This version permits
you to convert to a different pointer type as well:

class Base
{
};

class Derived : public Base
{
};

const Base *bp = new Derived;
Derived *dp = const_cast<Derived *>(bp);

This invocation of const_cast is not permitted under the working paper,
because it changes the type that the pointer points to as well as
changing const-ness. It is perfectly legal with the template proposed
above.
 -- Pete
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Valentin Bonnard <bonnardv@pratique.fr> wrote:

>Timo Geusch wrote (in c.l.c.m):
>>
>> I just checked my copy of the C++ draft standard I have and did not find
>> any reference to an implicit_cast. IMHO, implicit cast are those cast
>> performed by the compiler all by itself. That's why I suppose there should
>> not be any keyword/operator for explicitly calling for a cast. (Kind of
>> confusing, isn't it ? EXPLICITLY ordering the compiler to execute an
>> IMPLICIT cast 8-)).
>
>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?

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Pablo Halpern wrote:
>
> Valentin Bonnard <bonnardv@pratique.fr> wrote:
>
> >Timo Geusch wrote (in c.l.c.m):
> >>
> >> I just checked my copy of the C++ draft standard I have and did not find
> >> any reference to an implicit_cast. IMHO, implicit cast are those cast
> >> performed by the compiler all by itself. That's why I suppose there should
> >> not be any keyword/operator for explicitly calling for a cast. (Kind of
> >> confusing, isn't it ? EXPLICITLY ordering the compiler to execute an
> >> IMPLICIT cast 8-)).
> >
> >implicit_cast<T>(x) is NOT standard (by the way, why ?).
>
> Why should it be.

As was discussed, there are subtleties to implementing it correctly, and
picking a name for it.

> As Timo says, what is the point in explicitly casting
> something and then calling it *implicit*.

Because it only involves implicit conversions. It is modeled after the
other cast operators for consistency.

> Once you use implicit_cast<> it's not implicit anymore, is it?

OK, so maybe it should be called
explicit_cast_even_though_it_only_involves_implicit_conversions<>? or
explicit_implicit_cast<>? Those don't seem much better.

> Maybe what you want is something like explicit_cast<>, which already exists.

Not to my knowledge.

> It's called static_cast<>.

Sorry, we DO NOT want static_cast<>! Conversions through static_cast<>
are not safe. static_cast<Derived*> (base_pointer) is invalid if
base_pointer doesn't point to Derived (or something derived from that).
An implicit_cast<> is illegal in this case.

> What would implicit_cast<> do that static_cast<> does not already do?

OK, fine, what would static_cast<>, const_cast<>, reinterpret_cast<> do
that an old-style cast cannot already do? To answer your question, an
implicit_cast<> does not allow operations that static_cast<> does allow.
This is the whole reason the new cast operators were introduced, so why
leave out the totally safe one? But as I have said in other messages,
the functional-style cast should be an implicit_cast<>, and *not* do any
other unsafe casts (static_cast<>, reinterpret_cast<>, const_cast<>).
Hopefully compilers will warn about non-implicit_cast<> functional-style
casts in the future.

--
Chelly Green | chelly@eden.com | C++ - http://www.eden.com/~chelly
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/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.

There are two places where I would use such an operation.
The first is to explicitly select one from a group of overloaded
functions:

 long FromScreenDistanceToLocalDistance( long screenDistance );
 double FromScreenDistanceToLocalDistance( double screenDistance );

 double accurateLocalDistance
  = FromScreenDistanceToLocalDistance(
   implicit_cast< double >( longScreenDistance ));

The second is similar, to explicitly select a template:

 template< class T >
 T FromScreenDistanceToLocalDistance( T screenDistance );

 double accurateLocalDistance
  = FromScreenDistanceToLocalDistance(
   implicit_cast< double >( longScreenDistance ));

In this example explicit specification of the template parameter
would also work, but I'm sure more complicated examples could be
concocted (eg when only the last of many template parameters would
need to be given) where implicit_cast is useful.

The main point here is that to write such code, I must use a cast.
static_cast will work, but will obscure my intent.

(I'm still not sure that this is an argument for putting it in the
language.)

Regards,
Garth A. Dickie
---
[ 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                             ]

Timo Geusch wrote (in c.l.c.m):
>
> I just checked my copy of the C++ draft standard I have and did not find
> any reference to an implicit_cast. IMHO, implicit cast are those cast
> performed by the compiler all by itself. That's why I suppose there should
> not be any keyword/operator for explicitly calling for a cast. (Kind of
> confusing, isn't it ? EXPLICITLY ordering the compiler to execute an
> IMPLICIT cast 8-)).

implicit_cast<T>(x) is NOT standard (by the way, why ?).

With a good compiler, you can easily define one:

template <class From, class To>
inline To  implicit_cast<To>(From x) // I'm not sure about the synatx
                                     // my compiler doesn't support
{                                    // that anyway
    return x;
}

The problem is that if everyone define its implicit_cast there will be
multiple-defined errors, so I think it should be standard.

I thing even static_cast, const_cast and dynamic_cast can be defined
by the user.

Example:

template <class To>
inline To*  const_cast<To*>(const volatile To* x)
{
    return (To*)x;
}

--

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
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]