Re: auto_ptr vs. boost shared_ptr
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());
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.
fine of the int *'s are not on the heap but statically allocated but
it is a pitfall someone that does not examine the actual code of
remove_if will not think of.
// For is a forward iterator.
template <class For,class Pred>
For remove_if(For begin,For end, Rred pred)
{
For last(begin);
while(begin != end)
{
if(!pred(*begin))
{
*last = *begin;
++last;
}
++begin;
}
return last;
}
looks like a reference implementation to me of remove_if. If your GC
handles overwrites like this, its ok, but using raw ptrs in any stl
container is a recipe for disaster, if the access to the container is
not controlled, and kept away from the 'user'.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]