[Dune] Transition from SmartPointer to shared_ptr

Markus Blatt Markus.Blatt at iwr.uni-heidelberg.de
Wed Oct 14 18:31:17 CEST 2009


On Wed, Oct 14, 2009 at 05:06:17PM +0200, Oliver Sander wrote:
> When transitioning from SmartPointer to shared_ptr, though, you have to be
> careful, because the two classes do not quite behave the same.  There 
> are two
> easy differences: the type SmartPointer::MemberType becomes 
> shared_ptr::element_type,
> und the method SmartPointer::count() is shared_ptr::use_count().  More 
> problematic
> is the following change:  The default constructor of SmartPointer 
> allocates an
> element, and hence returns a dereferenceable pointer.  
> Default-constructing a
> shared_ptr instead creates a pointer pointing to NULL.  This is fairly 
> consistent with
> regular C pointer which, when default constructed, do not reliably point 
> anywhere.
> However, if you rely on the SmartPointer default constructor allocating 
> memory
> (as for example, the SmartPointer unit test did),  THIS CHANGE WILL BREAK
> YOUR CODE.


This is indeed very problematic. Did I miss it or was this never
mentioned before hand? I vaguely recall that you said shared_ptr is a
direct copy of SmartPointer...

No this puts the whole discussion about the transistion into  a
another light. I would have objected if I had known this beforehand.

Anyway I was not very convinced why this change was useful. But as it
was considered minor and nobody told anything  about the semantics
change, I just kept my doubts to myself.

I cannot anymore. Maybe we should have a general discussion about
moving to tr1 and why it is useful and worth the additional
work. (At least with tuples we started this change and it was never 
finished, because there is a long tail of containers that behave like
a tuple, and therefore should be usable with the tuple TMPs).

IMHO all these changes lead to problems with the backwards
compatibility of our code. Or does everybody check his code without
tr1 enabled? (I know that I usually don't!) Can we really be sure that
Dune still works with gcc-3.4? Maybe, but if someone addresses the
fixed size Dune::array with the tuple TMPs it will be broken.

Back to the change of smartpointer:

Of course I rely on the behaviour of the old implementation!
Hopefully nobody changed ArrayList which used the old smartpointer and
relied on it. Otherwise parallel ISTL is broken :/

Regards,

Markus




More information about the Dune mailing list