cast ambiguities

[Arno]

Hello,

I want to write classes, which can be used as interchangeably as
possible. The background is that they are smartpointers, which should
implicitly cast between each other.

As a toy example, let's take two classes A and B:

struct A {
A() {}
A( A const& a ) {}
};

struct B {
B() {}
B( B const& b ) {}
operator A() { return ... };

// adding either one of the two following
// lines breaks the program
// with VC++ 7.1, reason: ambiguous cast.
// Why???
// operator A const&() { return ... };
// operator A &() { return ... };
};

A func1() {
B b;
return b; // cast through B::operator A()
}

The above works, but adding either one of the two extra casts breaks
the compilation.

These casts would be useful, for example for:

func2( A const& );

func3() {
B b;
func2( b ); // reference cast here, no need to copy
}

What am I missing?

Thanks,

Arno

[Josh Mcfarlane]

Arno wrote:

Hello,

I want to write classes, which can be used as interchangeably as
possible. The background is that they are smartpointers, which should
implicitly cast between each other.

As a toy example, let's take two classes A and B:

What are the differences between class A and class B?

If they are the same in practice, class A and B should be one class.

If one is derived from the other, there should be no need to cast.

If they are not derived from each other, and not the same, then it's
not safe to use them interchangably.

Have you considered creating a base class C for both and then
inheriting A and B from C, and having it return a pointer to C? This
should allow you to do the operations you want to, but otherwise you're
dealing with a problem. Sure, you can cast a pointer value to an array
of chars, but does that make the information or valid? You have to have
a connection between the data, otherwise you have a very big chance of
running into undefined behavior.

[Arno]

The code above is just for demonstration. The actual code is a smart
pointer library. template< class T> Ref<T> is a smart pointer, which
should be able to implicitly cast to Ref<S> if type T is derived from
type S. In addition, Ref is implementing reference-counting.

I would be able to save some reference counts if I would not have to
create copies during casting. Ref<T> and Ref<S> must still be distinct
types, so they are type-checkable at compile time.

[mlimber]

Arno wrote:

The code above is just for demonstration. The actual code is a smart
pointer library. template< class T> Ref<T> is a smart pointer, which
should be able to implicitly cast to Ref<S> if type T is derived from
type S. In addition, Ref is implementing reference-counting.

I would be able to save some reference counts if I would not have to
create copies during casting. Ref<T> and Ref<S> must still be distinct
types, so they are type-checkable at compile time.

Can you use a templatized constructor? Compare this code from
boost::shared_p tr:

template<class T> class shared_ptr
{
// ...
public:
template<class Y>
shared_ptr(shar ed_ptr<Y> const & r);
// ...
};

Cheers! --M

[Arno]

I can and I did up to now. What I do not like about it is that even
trivial casts require copying, like:

struct B {};
struct A: public B {};

func( const Ref<B>& b ) {
....
}

main() {
Ref<A> a=newObj A();
func( a );
}

Internally, Ref <> stores a simple pointer, so the binary
representations of Ref<A> and Ref<B> are identical. For the case above,
the cast could really be a no-op. But this does not work, the templated
constructor B::B() or A::operator B() is called (really no big
difference) and a copy is made, which requires some reference counting.
Reference counting is no biggie in single-threaded systems, but if you
get multithreaded and every count must be interlocked...

[Heinz Ozwirk]

"Arno" <as******@thi nk-cell.com> schrieb im Newsbeitrag
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

Hello,

I want to write classes, which can be used as interchangeably as
possible. The background is that they are smartpointers, which should
implicitly cast between each other.

As a toy example, let's take two classes A and B:

struct A {
A() {}
A( A const& a ) {}
};

struct B {
B() {}
B( B const& b ) {}
operator A() { return ... };

// adding either one of the two following
// lines breaks the program
// with VC++ 7.1, reason: ambiguous cast.
// Why???
// operator A const&() { return ... };
// operator A &() { return ... };
};

A func1() {
B b;
return b; // cast through B::operator A()
}

The above works, but adding either one of the two extra casts breaks
the compilation.

These casts would be useful, for example for:

func2( A const& );

func3() {
B b;
func2( b ); // reference cast here, no need to copy
}

Why don't you remove B::operator A and add operator A& or operator A const&
instead. You can almost(?) allways use a const ref where a value is
required.

HTH
Heinz

[Arno]

Yes, so I thought. But it does not work when casting return values!

A func() {
B b;
return b;
}

only compiles if there is a B::operator A() or a A::A(const B&). If
there is only a B::operator A&() or B::operator A const&() the compiler
complains of having to do two casts for "return b" in the function
above. And if B::operator A() exists in addition, it complains about
ambiguity... I just don't understand the rules well enough...

Arno

[Alf P. Steinbach]

* Arno:

I can and I did up to now. What I do not like about it is that even
trivial casts require copying, like:

struct B {};
struct A: public B {};

func( const Ref<B>& b ) {
...
}

main() {
Ref<A> a=newObj A();
func( a );
}

Internally, Ref <> stores a simple pointer, so the binary
representations of Ref<A> and Ref<B> are identical. For the case above,
the cast could really be a no-op. But this does not work, the templated
constructor B::B() or A::operator B() is called (really no big
difference) and a copy is made, which requires some reference counting.
Reference counting is no biggie in single-threaded systems, but if you
get multithreaded and every count must be interlocked...

Let's use the names Base and Derived instead of B and A.

If the Ref smart pointer class is re-seatable (i.e. you can make a Ref point
to something new after initialization) , then Ref<Derived> should not behave as
if derived from Ref<Base>, because if it did, then you could erronously make a
Ref<Derived> point to a Base instance. Isn't it great that the language, in
practice, prevents that error? And thus shows you what goes on behind the
scenes in languages with transparent re-seatable object references.

That said, in some other contexts there is a need for wrapping a hierarchy of
classes in a parallell hierarchy, and this is a largely unsolved problem in
the sense that one must employ case-specific trade offs: no general solution.
And this is the problem when Ref is not re-seatable. Without cranking my
hind-brain too much I think the closest one can come to a general solution, in
C++, is virtual inheritance from a pure interface hierarchy, which is a bit
awkward in that it introduces a third parallell class hierarchy, and it also
introduces an inefficiency that may or may not be significant (I'm not sure).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?