Re: auto_ptr vs. boost shared_ptr
Carl Barron wrote:
In article <1153217452.851018.186990@s13g2000cwa.googlegroups.com>,
kanze <kanze@gabi-soft.fr> wrote:
Carl Barron wrote:
James Kanze <kanze.james@neuf.fr> wrote:
vector< shared_ptr< int > > v1; // OK.
vector< auto_ptr< int > > v2; // Undefined Behavior, but
probably a
compile error.
True, but most of the time, I find that raw pointers are
best here. Of course, I usually use the Boehm collector, so
I don't need a surrogate for garbage collection.
Does your GC handle things like
struct larger_than_10
{
bool operator () (int *p) {return *p > 10;}
};
struct create_ptr()
{
int i;
create_ptr():i(1){};
int * operator () () {return new int(i++);}
};
struct kill
{
void operator () (int *x) {delete x;}
};
int main()
{
std::vector<int *> data;
std::generate_n(std::back_inserter(data),1000,create_ptr());
std::vector<int *>::iterator last =
std::remove_if
(
data.begin(),
data.end(),
larger_than_10()
);
std::for_each(last,data.end(),kill());
Concentrating on the GC issues, I missed this first go around.
The for_each here likely results in undefined behavior (and the
remove_if creates a number of memory leaks).
In the general case; in this specific case, given that the
actual contents were sorted, and all of the objects to be
removed were at the end, the remove_if is actually a no-op. Any
time the remove_if is not a no-op, however, this code won't
work.
data.erase(last,data.end());
}
remove_if blindly overwrites the int *'s so the deleted
ones are either never deleted until the os takes over, or
are deleted mutliple times.
There can be a problem in that data.erase() doesn't actually
free memory. It calls the "destructor" on the freed
elements, and a destructor on a pointer is a no-op. The
results are that the memory corresponding to any pointers
between last and data.end() will not be freed until the
vector itself is destroyed.
To date, this has not been a problem in my code; my vectors
tend to grow, and never shrink. But it's not hard to
imagine cases were it could be a problem. Somewhere on my
to do list are the modifications in the g++ implementation
of the standard library to ensure that pointers in
conceptually raw memory are effectively nulled.
Since std::vector is not required and usually does not actually
release the memory from an erase
It is, in fact, required to not release the memory. (Actually,
it is required to not invalidate any iterators or references to
objects in front of the erase. But this requirement pretty much
effectively means that it cannot release any memory.)
but keeps it in the reserved space then there is no problem
here.
It is in the sense that garbage collection won't recover the
memory the erased pointers points to. It's fairly easy to
modifiy std::vector, however, so that it will.
It is the deletion of the contained ptr that was my
concerned.
Do you mean the for_each with kill? Since the values in the
pointers behind the return value of remove_if aren't really
specified (they are valid pointers, and in fact, are equal to
something that was in the vector before the remove_if, but
that's all you can say about them).
I'm still not really sure exactly what you were asking. Was the
undefined behavior here intentional, and the question, if I use
garbage collection instead of the for_each with kill, would it
work, then the answer is yes, at least in the sense that you
will have no undefined behavior, and no leaked memory once the
vector itself is destroyed.
Vector normally shrink[end-begin decreases] but capacity is
not reduced until the vector is destructed Just wondering
about pitfalls and <algorithm>.
From what I understand, the only cases where shrinking capacity
is legal are destruction, swap and assignment (and I'm not sure
about assignment). If garbage collection is used, and you have
long lived vectors whose size is typically significantly less
than the maximum size they have had, you probably need to modify
vector so that it zaps the memory of removed objects.
I definitely do not recommend returning any access of a vector
of raw ptrs to the user,
I wouldn't exclude it as an absolute rule, but it's true that I
can't see very many cases where it would be acceptable. For
that matter, I don't think there is anywhere in my code where I
expose a vector of pointers---raw or otherwise---to clients.
A class that is reasonably careful can use ptrs. I also note
anyone using an stl container should be wary of using
<algorithm> and assuming no problems can occur. <algorithm>
is 'value based' and usage of a modifying algorithm is a
possible hidden bug, not that vector <T *> is unusable.
You just have to remember that pointers are objects, just like
anything else.
perhaps recipe for disaster is a liitle too strong. But if I
hardly ever use a vector of raw ptrs because of memory
management problems I don't want to consider.
It depends. I can't think of a case with vector, but I do have
cases of deque, and a lot of maps and sets with raw pointers.
Whether memory management is an issue or not depends on the use:
a frequent pattern in my code is a map to pointers to static
objects (generally more or less functional objects)---it's a
more versatile and more dynamic replacement for a switch. (You
can dispatch on strings, and not just integral constants; you
can add cases by loading a dynamic object; etc.)
Other times---in the deque in MessageQueue, for example---, the
memory management is an issue. It's not always obvious that
there are alternatives, however: the MessageQueue interface
cries out for auto_ptr (or unique_ptr, if that's added to the
standard), since it very definitly implies a transfer of
ownership, and the client does not have a right to access the
object once he has passed it to us. And since I also have to
return an auto_ptr, I can't use shared_ptr in the container.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]