Re: Inheritance based type conversion and private inheritance
Am 24.04.2011 07:45, schrieb Matthias Hofmann:
Hello everybody!
I have just been playing around a little with inheritance based type
conversion and I am using Microsoft Visual C++ 2005 Express Edition to
compile the following code:
template<typename T>
class SmartPtr
{
T* m_ptr;
public:
SmartPtr( T* ptr = 0 )
: m_ptr( ptr ) {}
~SmartPtr()
{ delete m_ptr; }
template<typename U>
operator SmartPtr<U>()
{
// An accessible conversion from type
// pointer-to-T to type pointer-to-U
// must exist for this to compile.
return SmartPtr<U>( m_ptr );
}
};
class Base
{
// Required for polymorphic deletion,
// though this is just a side issue.
virtual ~Base() {}
};
Are you sure that this is the way how you wrote your code? Note that the destructor of base is private here, so there is no chance to delete a pointer to Base or to Derived within the SmartPtr. In the following, I assume that Base::~Base() was actually declared as public, else you could not compile anything of your code.
// Note private inheritance.
class Derived : Base {};
int main()
{
// Error: A conversion from Derived* to
// Base* exists, but is not accessible.
SmartPtr<Base> ptr_err ( new Derived );
Error is OK.
// Compiles fine.
SmartPtr<Derived> ptr_d ( new Derived );
OK.
// Compiles fine.
SmartPtr<Base> ptr_b = ptr_d;
Not OK.
return 0;
}
When SmartPtr<Derived>::operator SmartPtr<Base>() is instantiated, an upcast
from Derived* to Base* is performed. This compiles fine, although the
conversion from Derived* to Base* should not be accessible within the
instantiation of that member function template.
Note that SmartPtr<T>::operator SmartPtr<U>() is not a friend of Derived,
which inherits privately from Base. The first line of code in main() does
the same thing as the conversion operator, but my compiler rejects it.
Is this a compliance issue with my compiler? And if not, why does the upcast
work within the conversion operator, but not outside of it?
The compiler is defect and should not accept your very last initialization.
I assume you are aware that above definition of a smart-pointer does not ensure a single owner-ship responsibility and is therefore broken.
HTH & Greetings from Bremen
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]