By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,294 Members | 2,650 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,294 IT Pros & Developers. It's quick & easy.

basic question for vector

P: n/a
I have a vector which I save the pointer.

function()
{
std::vector <CMyData*> vpMyData;
vpMyData.push_back(new CMyData(0));
vpMyData.push_back(new CMyData(1));
vpMyData.push_back(new CMyData(2));
vpMyData.push_back(new CMyData(3));

//??????????????? Required ???????????//
delete vpMyData[0];
delete vpMyData[1];
delete vpMyData[2];
delete vpMyData[3];

}

Should I delete all memory before I leave the function?

Jan 7 '06 #1
Share this Question
Share on Google+
14 Replies


P: n/a
kathy wrote:
I have a vector which I save the pointer.

function()
Your function is missing a return type.
{
std::vector <CMyData*> vpMyData;
vpMyData.push_back(new CMyData(0));
vpMyData.push_back(new CMyData(1));
vpMyData.push_back(new CMyData(2));
vpMyData.push_back(new CMyData(3));

//??????????????? Required ???????????//
delete vpMyData[0];
delete vpMyData[1];
delete vpMyData[2];
delete vpMyData[3];

}

Should I delete all memory before I leave the function?


Yes. Otherwise you have a memory leak. Btw: You can also simply store the
objects instead of pointers. Then the memory is released automatically.

Jan 7 '06 #2

P: n/a
kathy wrote:
I have a vector which I save the pointer.

function()
{
std::vector <CMyData*> vpMyData;
vpMyData.push_back(new CMyData(0));
vpMyData.push_back(new CMyData(1));
vpMyData.push_back(new CMyData(2));
vpMyData.push_back(new CMyData(3));

//??????????????? Required ???????????//
delete vpMyData[0];
delete vpMyData[1];
delete vpMyData[2];
delete vpMyData[3];

}

Should I delete all memory before I leave the function?


Every object allocated dynamically by new operator must be deallocated
by delete operator. std::vector does not have any knowledge to
distinguish when you store objects and when you store pointers-to-objects.

Cheers
--
Mateusz Łoskot
http://mateusz.loskot.net
Jan 7 '06 #3

P: n/a
alternately you could create a new class that inherits from vector, and
provides a destructor that cleans up all the pointers. or don't use
pointers.

Jan 9 '06 #4

P: n/a
kathy wrote:
I have a vector which I save the pointer.

function()
{
std::vector <CMyData*> vpMyData;
vpMyData.push_back(new CMyData(0));
vpMyData.push_back(new CMyData(1));
vpMyData.push_back(new CMyData(2));
vpMyData.push_back(new CMyData(3));

//??????????????? Required ???????????//
delete vpMyData[0];
delete vpMyData[1];
delete vpMyData[2];
delete vpMyData[3];

}

Should I delete all memory before I leave the function?


Well, you should delete it when you're done using the vector. A couple
of suggestions to make this easier on yourself:

1. Use a "smart pointer" which will handle the deletion for you. There
are many flavors of smart pointers, which provide varying semantics
depending on your needs. There's std::auto_ptr, boost::shared_ptr,
boost::scoped_ptr, and boost::intrusive_ptr, for starters.

2. If you're dead set on using raw pointers, at least use std::for_each
when you want to do the deletions.

3. Read about the paradigm "Resource Acquisition Is Initialization," or
"RAII."

Luke

Jan 9 '06 #5

P: n/a

<hy**********@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
alternately you could create a new class that inherits from vector,


This can lead to trouble, since type 'std::vector's
destructor is not virtual.

-Mike
Jan 9 '06 #6

P: n/a
Mike Wahler wrote:
alternately you could create a new class that inherits from vector,


This can lead to trouble, since type 'std::vector's
destructor is not virtual.


This would only be a problem if a vector gets dynamically allocated, which
is usually not done.

Jan 10 '06 #7

P: n/a
|| 2. If you're dead set on using raw pointers, at least use
std::for_each
|| when you want to do the deletions.
At least use std::for_each!! Could you elaborate on this? Interesting

Jan 10 '06 #8

P: n/a
Rolf Magnus wrote:
This would only be a problem if a vector gets dynamically allocated, which
is usually not done.

Not necessarily:
union {
char buffer[sizeof(MyDerivedVector)];
void *align;
};

new (buffer) MyDerivedVector(...);
std::vector<T> *vec = reinterpret_cast<MyDerivedVector*>(buffer);
....
....
vec->~std::vector<T>(); // BAD
This is not dynamically *allocated*, it is dynamically *constructed*
:)

Just playing,
-shez-

Jan 10 '06 #9

P: n/a
ma740988 wrote:
|| 2. If you're dead set on using raw pointers, at least use
std::for_each
|| when you want to do the deletions.
At least use std::for_each!! Could you elaborate on this? Interesting


I believe he/she is referring to code similar to the following:
for_each(vpMyClass.begin(), vpMyClass.end(), DeleteObject());

Where DeleteObject() is a functor.

However, I recommend using the following method instead, which (IMHO)
is cleaner:
class DeleteObject
{
public:
template<typename T>
bool operator()(T& ptr)
{
delete &*ptr;
ptr = NULL;
return true;
}
};
Example usage:
vpMyClass.erase(remove_if(vpMyClass.begin(),
vpMyClass.end(),DeleteObject()), vpMyClass.end());
The above DeleteObject will work with any object type

Jan 10 '06 #10

P: n/a
Luke Meyers wrote:
kathy wrote:
I have a vector which I save the pointer.

function()
{
std::vector <CMyData*> vpMyData;
vpMyData.push_back(new CMyData(0));
vpMyData.push_back(new CMyData(1));
vpMyData.push_back(new CMyData(2));
vpMyData.push_back(new CMyData(3));

//??????????????? Required ???????????//
delete vpMyData[0];
delete vpMyData[1];
delete vpMyData[2];
delete vpMyData[3];

}

Should I delete all memory before I leave the function?


Well, you should delete it when you're done using the vector. A couple
of suggestions to make this easier on yourself:

1. Use a "smart pointer" which will handle the deletion for you. There
are many flavors of smart pointers, which provide varying semantics
depending on your needs. There's std::auto_ptr, boost::shared_ptr,
boost::scoped_ptr, and boost::intrusive_ptr, for starters.


auto_ptr can not be used with an STL container.
A compliant C++ compiler will fail to compile when attempting to
push_back on a container of auto_ptr's.

When creating a container of smart pointers, I recommend using a clone
smart pointer like cow_ptr or copy_ptr.
http://code.axter.com/cow_ptr.h
http://code.axter.com/copy_ptr.h

You can also consider using boost::ptr_vector, which is a container of
clonable pointers.

Jan 10 '06 #11

P: n/a
Axter wrote:
auto_ptr can not be used with an STL container.
A compliant C++ compiler will fail to compile when attempting to
push_back on a container of auto_ptr's.


I'm not so sure that this is a requirement, I thought it just
causes undefined behaviour (because auto_ptr does not
satisfy the requirements that the container type be Copyable).

Jan 10 '06 #12

P: n/a

|| The above DeleteObject will work with any object type
The underlying tenet then surrounds the use of a function object - or
something similar, not necessarily the use of a specific algorithm?

Jan 10 '06 #13

P: n/a

"Old Wolf" <ol*****@inspire.net.nz> skrev i meddelandet
news:11*********************@g49g2000cwa.googlegro ups.com...
Axter wrote:
auto_ptr can not be used with an STL container.
A compliant C++ compiler will fail to compile when attempting to
push_back on a container of auto_ptr's.


I'm not so sure that this is a requirement, I thought it just
causes undefined behaviour (because auto_ptr does not
satisfy the requirements that the container type be Copyable).

You are both right. :-)

There is no explicit requirement for a compiler diagnostic, but the
standards committee has worked hard to define auto_ptr such that it is
highly *probable* to fail to compile as a component of a standard
container.

Especially its copy constructor and assignment operator taking a
non-const reference, make almost all complers complain.
Bo Persson
Jan 10 '06 #14

P: n/a
Old Wolf wrote:
Axter wrote:
auto_ptr can not be used with an STL container.
A compliant C++ compiler will fail to compile when attempting to
push_back on a container of auto_ptr's.


I'm not so sure that this is a requirement, I thought it just
causes undefined behaviour (because auto_ptr does not
satisfy the requirements that the container type be Copyable).


IAW C++ standard, declaring a container of auto_ptr results in
undefined behavior.
However, IAW C++ standard adding anything to a container of auto_ptr
results in a compile error. That's why I specifically referred to
getting a compile error when calling push_back.
The standard does not explicitly states that calling push_back resutls
in a compile error.
However, if a compiler applies the STL container and auto_ptr
implementation described in the standard, then it would have no choice
but to produce a compile error when calling push_back.

The following is from an older thread which gives a good description
why a C++ compliant compiler must give a compile error when calling
push_back.
************************************************** ********************************************
STL Containers store contained types by value (value
semantics). It is therefore required that the contained type should at
least have a copy constructor and (or) assignment operator - depending
on operations performed and the container type. If you takes as
example, one of the sequence containers (vector or list), then you
would notice (in the std) that for modifiers type T is passed as (const

T&).

example (from std):
void push_back( const T& x ); //or..
iterator insert( iterator pos, const T& x );
It should therefore be impossible to use std::auto_ptr<X> as type T, as

auto_ptr's copy constructor (and assignment op) requires (X& x) as
argument. It does not meet the copy-constructable requirements of the
container.
************************************************** ********************************************

Jan 11 '06 #15

This discussion thread is closed

Replies have been disabled for this discussion.