RE: [boost] plain pointers and shared_ptr

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-03-26 09:08:57

From: E. Gladyshev [mailto:egladysh_at_[hidden]]
> 
> >Typically, the
> > only reason you are 
> > forced to pass around a plain pointer is some legacy
> > code or system 
> > programming interface you can't control, and even
> > that is pretty rare.
> 
> I don't think that it is pretty rare.  If you worked
> on huge and multi-team projects, then I am sure 
> you know that inter-module API's are specified 
> in C much more often than in C++.  It is especially

Not at all.  Perhaps in your environment, that is the case, but there are
many projects that are strictly C++.

> important if the project has many DLL's or some of
> the client code has to be C.
> It is never a wise solution to export C++
> classes from DLL's (remember name mangling...etc.)

Since when?  I used to do it frequently and I know the developers here that
do NT work do it.

> Let's get practical :).

What's impractical about using strictly C++?

> > The latest version of boost::shared_ptr can handle
> > this. When you 
> > construct a shared_ptr, you can pass in a function
> > that is used to 
> > destroy the object instead of the default "delete".
> > Here's one way to do 
> > it.
> > 
> >      #include <boost/shared_ptr.hpp>
> >      void do_nothing(int*) { }
> >      int g_x;
> >      int main()
> >      {
> >          boost::shared_ptr<int> tmp(&g_x,
> > do_nothing);
> >      }
> 
> No, I don't think your suggestion will work
> with my example because foo() will have to
> know to use do_nothing() as well, but
> it has not idea what deleter to use.
> Just try it for yourself and remember 
> we are looking for a generic solution.
> 
> > Once you've had some experience with smart pointers,
> > you'll find that 
> > it's best to have very few interfaces that use plain
> > pointers, so the 
> > first problem you mentioned becomes a non-problem.
> 
> Unfortunately our experience has nothing
> to do with the real life requirements. 
> In most cases we don't have the total control 
> over how the project interfaces are defined.
> I am sure you are well aware of that.

It seems that each time someone tells you that there is no way to portably
determine whether memory was allocated using ::new, malloc, some user- or
system-defined heap, or the stack, so there's no way for shared_ptr to know
how to release memory, and they suggest alternatives, you simply throw out
additional requirements which disallow the suggestion.

So, here's the deal.  You can't, portably, ascertain whether how memory was
allocated when you have only a raw pointer to the memory.  Given that fact,
you have only these choices:

  - always use shared_ptr's (thus every "pointer" carries its deletion logic
with it)
  - manage some collection of pointers allocated in the various ways so when
your smart pointer class tries to release it, it will know whether to call
free, delete, some other function, or do nothing.
  - use garbage collection software and don't free memory yourself
  - never delete/free in a function taking a raw pointer argument

I might have missed an option or two, but the one that isn't available is to
have shared_ptr automatically determine how or whether to release the
memory.

Rob
Susquehanna International Group, LLP
http://www.sig.com