Re: Making a smart pointer which works with incomplete types
Alf P. Steinbach wrote:
* Kai-Uwe Bux:
Alf P. Steinbach wrote:
* Kai-Uwe Bux:
Alf P. Steinbach wrote:
* James Kanze:
On Sep 7, 4:11 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* Kai-Uwe Bux:
Alf P. Steinbach wrote:
* Kai-Uwe Bux:
Alf P. Steinbach wrote:
* Juha Nieminen:
Then it occurred to me: Is there any reason this pointer
cannot be
static? Like this:
//------------------------------------------------------------------
template<typename Data_t>
class SmartPointer
{
...
static void(*deleterFunc)(Data_t*);
...
public:
SmartPointer(Data_t* d): data(d)
{
deleterFunc = &deleter;
}
...
};
template<typename Data_t>
void(*SmartPointer<Data_t>::deleterFunc)(Data_t*) = 0;
//------------------------------------------------------------------
This way the pointer to the deleter will be stored in the
program only
once, and most importantly it will not increment the size of
the smart pointer.
This feels so glaringly obvious to me now that I really
wonder why
this wasn't suggested to me to begin with. Is there some error
here I'm missing?
Yeah. Successive smart pointer instantiations can change the
common deleter func pointer.
[snip]
How?
Sorry, I reacted to the static pointer. As I wrote use a template
parameter instead. The only valid reason for having a pointer to
that function is to change the pointer, and that's apparently done
in the constructor body,
Really? Then a smart pointer working with incomplete types
(in the sense above) either does not qualify as a valid
reason or there must be a way without that (static) pointer.
Which is it? and if it is the second, which way of making a
smart pointer work with incomplete types do you have in
mind?
Consider the following:
template< typename T >
void destroy( T* );
template< typename T >
class SmartPointer
{
...
public:
~SmartPointer() { if( ... ) { destroy( myReferent ); } }
};
It achieves the same as the original code without any static
pointer.
No. With the original code, you can delete the pointer in a
context where the type is incomplete. with your code, you
can't.
Well, when you say something like that then you start me thinking if I
may have overlooked something, e.g something really basic. You force
me to actually code up a test case and check it. With at least two
different compilers.
Could you post the code? I have a little trouble deciding when and
where to put the definition for the template
template< typename T >
void destroy( T* );
Sigh.
Following is the code for James' comments.
Although this uses template parameter (which is what I recommended for
ease of use) it is trivial to remove that feature, requiring a litte
more client code.
<code file="sp.h">
#ifndef SP_H
#define SP_H
template< typename T >
void destroy( T* );
template< typename T, void (*doDestroy)(T*) = &destroy<T> >
class SmartPtr
{
private:
T* myReferent;
SmartPtr( SmartPtr const& );
SmartPtr& operator=( SmartPtr const& );
public:
SmartPtr( T* p ): myReferent( p ) {}
~SmartPtr() { doDestroy( myReferent ); }
};
#endif
</code>
<code file="x.cpp">
#include "sp.h"
class X;
X* newX();
void deleteX( X* );
int main()
{
SmartPtr<X, deleteX> p( newX() );
}
</code>
<code file="y.cpp">
#include <iostream>
using namespace std;
class X
{
private:
X( X const& );
X& operator=( X& );
public:
X() { cout << "X::<init>" << endl; }
~X() { cout << "X::<destroy>" << endl; }
};
X* newX() { return new X; }
void deleteX( X* p ) { delete p; }
</code>
It appears that you introduce a trade-off. You eliminate the pointer at
the cost of increasing the conceptual requirements for X, in particular,
a function deleteX (or some specialization of destroy(X*)) has to exist.
Or some overload of a function called by generic implementation, or e.g.
TR1's facility for unique_ptr, or whatever.
It's not a trade-off.
You can't destroy something without having available a destruction
operation, so you need that anyhow (only exception is if you're content
with assuming trivial destructor (and anyway I'm not even sure if that's
allowed, never needed it)).
There is a difference between having a destruction operation and having a
name for it. There is an obvious destruction, namely
T::~T();
which does not work for incomplete types since it assumes (as you point out)
the trivial destructor.
I
leave it up to Juha to judge whether this meets his requirements. In any
case, I think his original solution with a static pointer to a deleter
has not been demonstrated to be absurd.
Some comments made in this thread were absurd. Juha's implementation,
adding a static pointer to the destruction operation, was simply
nonsensical, completely needless complexity. I'm not sure whether absurd =
nonsensical, but anyhow, this is almost as silly a debate as one might
encounter in Microsoft groups, except that here I know the folks I'm
talking to have, on earlier occasions, repeatedly exhibited signs of
intelligence, so I'm completely bewildered.
Maybe I can ease you bewilderment a little. The way I understood Juha's
challenge is to write a drop in replacement for the following template
(which is viewed as a little too bulky):
#include <tr1/memory>
template < typename T >
class smart_ptr {
std::tr1::shared_ptr<T> t_ptr;
public:
smart_ptr ( T* ptr = 0 )
: t_ptr ( ptr )
{}
smart_ptr ( smart_ptr const & other )
: t_ptr ( other.t_ptr )
{}
T & operator* ( void ) const {
return ( *t_ptr );
}
T * operator-> ( void ) const {
return ( t_ptr.operator->() );
}
};
Note that smart_ptr<X> will work as expected as long as X is complete at the
point in the program where smart_ptr<X> is constructed (TR1 guarantees
that).
"Drop in replacement" is supposed to mean that the alternative
implementation should behave like the provided implementation in all cases
(I would like to say in all test cases, but we were not given any).
I think the implementation you suggest falls short because it
requires "deleteX" do be defined. (Whether you call that a conceptual
requirement, whether it creates overhead or not, all that is immaterial:
important is just that it allows one to write a test case where your
implementation behaves observably different.)
Best
Kai-Uwe Bux