C++Talk.NET

Oskar Enoksson · Guest

When working on a reference-counting smart pointer-class I stumbled on a
tricky situation I don't know how to solve:

I want to be able to implicitly convert a RefPtr<T> & into a const
RefPtr<const T> &. Such a conversion operator would allow me to
implement the standard rules of constness and pointers.

Ideally I would like to do have a "const-inheritance" as follows:

template<typename T>
struct RefPtr<T>;

template<typename T>
struct RefPtr<const T> {
/* ... */
};

template<typename T>
struct RefPtr: public const RefPtr<const T> {
/* ... */
};

Now, I know that this kind of "const-inheritance" is not allowed (but I
wonder why, because I have seen many other cases where this would have
been useful and I can't see any problems with allowing such a feature in
c++). Anyway, the next thing I tried is private inheritance and a
conversion operator member:

template<typename T>
struct RefPtr<T>;

template<typename T>
struct RefPtr<const T> {
/* ... */
};

template<typename T>
struct RefPtr: private RefPtr<const T> {
operator const RefPtr<const T> &() const { return *this; }
/* ... */
};

It turns out that the compilers I have tried (gcc 3.3.1 and Intel icc 8.0)
do accept this code, but the overloading of the implicit conversion
operator is silently ignored, so later on when trying to compile the line

RefPtr<int> i;
RefPtr<const int> j;
j = i;

I get compilation error (gcc 3.3.1):

error: `RefPtr<const int>' is an inaccessible base of `RefPtr<int>'

So, the only solution I have found is using membership instead of
inheritance as follows:

template<typename T>
struct RefPtr<T>;

template<typename T>
struct RefPtr<const T> {
/* ... */
};

template<typename T>
struct RefPtr: private RefPtr<const T> {
operator const RefPtr<const T> &() const { return const_ptr; }
/* ... */
private:
RefPtr<const T> const_ptr;
};

All member functions of RefPtr<const T> must now be re-implemented in
RefPtr<T> as wrappers calling the same member functions in the const_ptr
member object. This seems like an ugly solution, and potentially
inefficient (depending on the compilers optimization capabilities to
inline all wrapper functions and efficiently eliminate any unnecessary
copying of arguments and return values).

So, my question is, is there a more clever way than my solution?

Is there any particular reason for not allowing const inheritance?

Is there any particular reason for allowing but ignoring conversion
operators to protected base classes? IMHO this should either be disallowed
or it should be allowed and work as expected.

Thank you.

Regards
/Oskar

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jonathan Turkanis · Guest

"Oskar Enoksson" <enok (AT) lysator (DOT) liu.se> wrote

Oskar Enoksson · Guest

Jonathan Turkanis wrote:

David Baraff · Guest

Oskar Enoksson <enok_tabortmig (AT) lysator (DOT) liu.se> wrote

Jarkko Lempiainen · Guest

The following works in VC .NET 2003 atleast:

template<typename T_>
struct Ptr
{
template<typename U_> operator Ptr<U_>&()
{
sizeof(static_cast<U_*>((T_*)0)); // check for proper ptr conversion
return reinterpret_cast<Ptr(*this);
}
};

struct A{};
struct B: A {};
struct C {};

void foo1(const Ptr<const B>&) {}
void foo2(const Ptr<A>&) {}
void foo3(const Ptr<const A>&) {}
void foo4(const Ptr<C>&) {}

int main()
{
Ptr<B> p;
foo1(p); // ok
foo2(p); // ok
foo3(p); // ok
foo4(p); // error
return 0;
}

Jarkko

"David Baraff" <deb (AT) pixar (DOT) com> wrote

David Baraff · Guest

"Jarkko Lempiainen" <jarkko (AT) videotron (DOT) ca> wrote

Oskar Enoksson · Guest

Jarkko Lempiainen wrote:

Jarkko Lempiainen · Guest

Yes, you are absolutely right, but you could prevent such casts.
MI is evil anyway ;)

Jarkko

"David Baraff" <deb (AT) pixar (DOT) com> wrote

kanze@gabi-soft.fr · Guest

[email]deb (AT) pixar (DOT) com[/email] (David Baraff) wrote in message
news:<37483324.0402242020.5a7e8246 (AT) posting (DOT) google.com>...

Jarkko Lempiainen · Guest

Obviously you need both const & non-const versions of the implicit
conversion op. I just didn't bother to write both (: I don't see what
would be the problem with unrelated type though, because you
always check for the valid conversion. Could you explain with an
example how does it allow conversion that are not normally allowed?

I don't really see any advantages in the alternative you propose.
Infact your code _allows_ incorrect casts (i.e. the foo4 passes
with your code, which is wrong).

Jarkko

"Oskar Enoksson" <enok_tabortmig (AT) lysator (DOT) liu.se> wrote

Oskar Enoksson · Guest

Jarkko Lempiainen wrote:

Jarkko Lempiainen · Guest

I still have to see the compiler where the solution I
proposed doesn't work (: I think it's good to try to
follow the standard, but being a purist will probably
hurt you more than taking the hit of such an unlikely
pathological scenario.

Yet again you can prevent casts which require
pointer adjustment, if not in compile-time, atleast
in run-time. And if you like, you can always place
such non-standard constructs into nonstandard.h (:

I don't do this in my own smart pointer impl. though,
because if you really have to pass the ownership of
an object, you are probably ready to take the hit of
pump-up/pump-down ref counting anyway. Atleast
that's what I have found out in practice.

Jarkko

<kanze (AT) gabi-soft (DOT) fr> wrote

Jarkko Lempiainen · Guest

Ah, yes, you are absolutely right. For some reason I was completely
blind to the downcasting scenario (: You might want to have slight
improvement to your code though and change the return type of
Dummy to int and do:
sizeof(Dummy<TT>(p));
to make sure it's compile-time expression and doesn't end up to
the run-time code in debug builds/deep inlining.

Jarkko

"Oskar Enoksson" <enok_tabortmig (AT) lysator (DOT) liu.se> wrote

kanze@gabi-soft.fr · Guest

"Jarkko Lempiainen" <jarkko (AT) videotron (DOT) ca> wrote

Jarkko Lempiainen · Guest

Many serious C++ applications don't use MI in scenarios
where it would cause problems in the proposed solution.
I think MI is quite bad argument against use of the technique
anyway, because that's something that's usually avoidable
with composition. I'm not saying MI is totally useless, but
in many places I have seen it used, it is, and only adds
unnecessary complexities to class hierarchies.

So, if you use MI as your argument to reject an useful
techique, it's your call, but I find it quite weak and unpractical.
As I have said few times before, you can detect if someone
is trying to do implicit cast and force to the use of explicit
cast instead.

Jarkko

<kanze (AT) gabi-soft (DOT) fr> wrote