[orbitcpp-list] smartptr constructors follow-up
Status: Beta
Brought to you by:
philipd
|
From: Richard A. <ric...@ix...> - 2001-02-17 02:46:30
|
After doing a little more research on the templated copy constructors in
orbitcpp_smartptr.hh it looks like the CVS gcc compilers are actually
correctly
reporting a problem.
Here's the way things look to me at the moment. Please correct anything
that
I've got screwed up.
Since a non-const reference cannot be bound to an r-value, it isn't
possible to
have an implicit constructor called (as we do, see below) which takes a
non-const reference argument.
This sort of thing is used in the XXX-cpp-skells.cc code generated by
orbitcpp.
A typical example calls a method which takes a non-const
Something_out<T>
reference as a pameter, but a non-const Something_var<T> reference is
passed
(usually the result of a dynamic_cast). Since this results in an r-value
being
passed to the constructor, the compiler rejects it.
Eg.
_self->method( dynamic_cast<Something_var<T> &>(someVariable) );
where method is defined as
class someClass
{
...
returnType method( Something_out<T> & parameter );
}
The dynamic_cast< Something_var<T> & > results in a temporary which is
then passed to the constructor for Something_out<T>. This is only legal
if the
Something_out<T> constructor takes a const reference.
It may be possible to get around this by constructing a local variable
in the
cpp-skell code.
Eg.
Something_var<T> & localVar = dynamic_cast<Something_var<T> &
>(someVariable);
_self->methof(localVar);
Since localVar is not a temporary, the compiler should be happy.
Unfortunately I don't know my way around the code generation stuff
enough to
hack this. Any help would be greatly appreciated.
I'll do some quick hacks on cpp-skell code and check if this actually
solves the
problem. Otherwise the nasty const_cast<> kludge might have to stay in
smartptr.hh.
--
On a related note, libstdc++ is moving to merge with the gcc3 branch in
CVS in
the next couple of days (according to the libstdc++ list) so it looks
like a
gcc3 release will only be a matter of a couple of months away.
--
Rich
|