Hi,

There is a certain structure that I need and I am planning to implement
but I wanted to make sure nothing similar that already exists.

My main objective is to have a vector that mainly carries pointers and
in it destructor, it would delete those pointers.

so it would be auto_vector<Class1 * autoVec;
autoVec.push_back(new Class1());

and somewhere in ~auto_vec there would be a delete for all memebers.

My question is, is there anything in STL that already does this
funtionality? and does anyone see any potential issues with this.

Thanks.

My question is, is there anything in STL that already does this
funtionality? and does anyone see any potential issues with this.

There no such array class that would handle the deletion of inserted
objects itself, however ther is a template class names auto_ptr which
deletes the pointed object once it goes out of scope.

Now the technique that you are probably supposed to use is, to fill a
vector with auto_ptrs, however u still cant be sure if the user of your
class will keep another instance of the pointer, so the object in fact
would not get destroyed when it is erased from your array.

The other way is to just write a wrapper of standard vector class which
deletes the objects in its erase, pop and clear functions.

greets
Ivan Leben

ivan.leben@gmail.com wrote:

Now the technique that you are probably supposed to use is, to fill a
vector with auto_ptrs, however u still cant be sure if the user of your
class will keep another instance of the pointer, so the object in fact
would not get destroyed when it is erased from your array.

You can't have a vector of auto_ptrs. It's undefined behavior, but
probably won't even compile (if you're lucky).

Best regards,

Tom

On 10 Nov 2006 13:53:56 -0800, "Karim" <karim.elsaid@gmail.comwrote:

>There is a certain structure that I need and I am planning to implement
>but I wanted to make sure nothing similar that already exists.
>My main objective is to have a vector that mainly carries pointers and
>in it destructor, it would delete those pointers.

That's probably not a perfect solution. Your destructor cannot know if
the pointed-to objects have been allocated with 'new' before.

>so it would be auto_vector<Class1 * autoVec;
autoVec.push_back(new Class1());
>
>and somewhere in ~auto_vec there would be a delete for all memebers.
>
>My question is, is there anything in STL that already does this
>funtionality?

No

>and does anyone see any potential issues with this.

Maybe the following approximates your requirements:
http://www.codeproject.com/vcpp/stl/ptr_vecto.asp
http://sourceforge.net/projects/ptr-vector/

Best wishes,
Roland Pibinger

In article <1163195636.132623.134380@e3g2000cwe.googlegroups. com>,
"Karim" <karim.elsaid@gmail.comwrote:

Hi,
>
There is a certain structure that I need and I am planning to implement
but I wanted to make sure nothing similar that already exists.
>
My main objective is to have a vector that mainly carries pointers and
in it destructor, it would delete those pointers.
>
so it would be auto_vector<Class1 * autoVec;
autoVec.push_back(new Class1());
>
and somewhere in ~auto_vec there would be a delete for all memebers.
>
My question is, is there anything in STL that already does this
funtionality? and does anyone see any potential issues with this.

* There is:

std::vector<std::tr1::shared_ptr<T

which isn't exactly what you want, but it is somewhat close. Substitute
boost::shared_ptr for std::tr1::shared_ptr if you don't have the tr1
version.

http://www.boost.org/libs/smart_ptr/shared_ptr.htm

* There is the boost Pointer Container Library which sounds very close
to what you want:

http://www.boost.org/libs/ptr_contai...container.html

* Looking to the future, for C++0X I believe there will be:

std::vector<std::unique_ptr<T>>

which is roughly equivalent to vector<auto_ptr<T>except that it works.

http://www.open-std.org/jtc1/sc22/wg...56.html#Additi
on%20-%20Class%20template%20unqiue_ptr

If you still want to write your own, the issues are:

* What are the copy semantics? I.e. what happens when you copy
construct or assign one of these things.

* Will you try to emulate move semantics (which is awkward, but mostly
doable in today's C++)? Move semantics essentially means transferring
ownership of the pointers.

For example, auto_ptr has no copy semantics. It does have move
semantics, but uses copy syntax to accomplish the move semantics (which
is why it is fundamentally unsafe).

-Howard

Karim wrote:

Hi,
>
There is a certain structure that I need and I am planning to implement
but I wanted to make sure nothing similar that already exists.
>
My main objective is to have a vector that mainly carries pointers and
in it destructor, it would delete those pointers.
>
so it would be auto_vector<Class1 * autoVec;
autoVec.push_back(new Class1());
>
and somewhere in ~auto_vec there would be a delete for all memebers.
>
My question is, is there anything in STL that already does this
funtionality? and does anyone see any potential issues with this.
>
Thanks.
>

Austria C++ "Pointer" does what you want but its semantics are unusual
so be careful. It's like std::auto_ptr but allows implicit transfer of
pointers which can lead to many unexpected results - use with care !

http://austria.sourceforge.net/dox/h..._1Pointer.html

Roland Pibinger wrote:

On 10 Nov 2006 13:53:56 -0800, "Karim" <karim.elsaid@gmail.comwrote:

>
That's probably not a perfect solution. Your destructor cannot know if
the pointed-to objects have been allocated with 'new' before.

Well, that would be part of the interface requirements that are supposed to
be well-documented, just like for std::auto_ptr or any other auto-deleting
smart pointers.

On Sat, 11 Nov 2006 09:40:40 +0100, Rolf Magnus <ramagnus@...de>
wrote:

>Roland Pibinger wrote:

>
>Well, that would be part of the interface requirements that are supposed to
>be well-documented, just like for std::auto_ptr or any other auto-deleting
>smart pointers.

Right, that' s more a design question than an implemetation or
documentation question. A generic container (or any generic component)
that works only with 'newed' objects is not really elegant. IMHO, good
design is characterized by symmetry between allocation and
deallocation, i.e. the allocator shall also be the de-allocator.

Best wishes,
Roland Pibinger