Re: Making a smart pointer which works with incomplete types
* 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)).
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.
Cheers & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?