Re: non destructable pointer
In article <44bbbd3a$0$27037$626a54ce@news.free.fr>, loufoque
<loufoque@remove.gmail.com> wrote:
Hotlips wrote :
In our current system we have a need to hand out pointers, either as
interface pointers or arrays of pointers (we cannot directly hold
references in an STL container). Some of the pointers will be
pointing
to statically allocated (not on the heap) objects, meaning a
Boost.SharedPointer or just a simple "delete" is a no-go!
To indicate that we are planning to introduce a NonDeletePtr<> that
will prevent deletion and indicate that memory handling is not an
issue
for the recieving part.
You should consider separately the cases with pointers pointing to
statically allocated objects and pointers pointing to heap allocated
objects.
For the first one, I think using a container of pointers is simple
and
is a good solution.
For the second one, it depends why you use dynamic allocation. If
it is
for polymorphism then there are a lot of nice solutions.
Using shared_ptr, as advised by the others, will only introduce
unnecessary overhead because of the refcounting you don't need as you
don't need to free the data.
Providing raw pointers to heap allocated data in your API is a bad
idea
because the receiving part will have to handle memory, but it's ok to
use them if they only reference other objects which memory is properly
handled.
Therefore I personally think there is no need to use a custom
wrapper to
indicate there is no memory management to do, because anyway when
using
a C++ library you should never expect to have to manage the memory
provided by the library.
Surely you can solve the OP's problem without shared_ptr. But it is
an existing solution, that solves the problem with the least low level
programming and allows the user to return a shared_ptr and not worry
that the user is using 100 ptrs to your resource or only one. I don't
recommend raw ptrs in non node based stl containers, but they can be so
used with extreme care....
If the shared_ptr solution is 'too slow' [use a profiler] then some
other solution that is less heavy is needed. Only then. It is better to
concentrate on the solution of the problem than to micro-optimize ahead
of time.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]