Re: deleting dynamically allocated objects in a container
Alf P. Steinbach /Usenet wrote:
* James Kanze, on 10.08.2010 13:07:
On Aug 9, 9:15 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
+use...@gmail.com> wrote:
* Kai-Uwe Bux, on 09.08.2010 21:24:
[...]
Following is my attempt: (I am using cout statements in the
ctor and dtor only for understanding purpose).
#include<cstdlib>
#include<iostream>
#include<vector>
#include<algorithm>
using namespace std;
class Test
{
public:
explicit Test(int arg = 0);
~Test();
private:
int val;
};
inline Test::Test(int arg) : val(arg)
{
cout<< "From Test ctor:"<< val<< endl;
}
inline Test::~Test()
{
cout<< "From Test dtor:"<< val<< endl;
}
inline void delete_pointer(Test*& arg)
{
delete arg;
arg = 0;
Purely formally, the above results in undefined behavior. (In
practice, I wouldn't worry about it.)
I am have problems spotting the UB, care to elaborate further?
That's about the container containing invalid pointer
values. That renders them non-copyconstructible and
non-assignable (since the required lvalue to rvalue
conversion is UB). Therefore, the container contains objects
that do not satisfy the conceptual requirements of the
container.
Perhaps that's why the OP sets the pointer to zero, which is
not an invalid pointer value: it's perfectly copyable.
Yes. But he deletes it before setting it to zero. So there is
a moment when the container contains an object which cannot be
copied without undefined behavior. In practice, I don't see any
way the above could actually fail; the standard says its UB if
the container contains an invalid pointer,
No, it doesn't.
Just to be clear, ?23.1/3 places a requirement on element /types/, that
they be copy constructible and assignable, and the word "type" is
explicitly used.
It does not place a requirement on the instances of those types. Such
instance requirements are only implicitly present as requirements for
operations. With no operations, no implicit requirements either.
Ok, let's assume that: no operations, no requirements. However, I am just
curious: would the following implementation of vector<T>::operator[] be
conforming:
template < typename T, typename A >
class vector {
...
value_type * __the_data_ptr; // stores the content
...
public:
...
reference operator[] ( size_type n ) {
// first do something to trigger lvalue to rvalue conversion:
__the_data_ptr[n];
// or enforce some copy construction
value_type value ( the_data_ptr[n] );
// then return:
return ( __the_data_ptr[n] );
}
...
};
So, would operator[] be allowed to trigger gratuitous copying? If so, at
least the sequence
delete v[i];
v[i] = 0;
has a problem. (However, the code of the OP would not have that problem,
although the solution posted by Daniel elsethread
Here is Stroustrup's solution (from TC++PL)
template<class T> T* delete_ptr(T* p) { delete p; return 0; }
void purge(deque<Shape*>& s)
{
transform(s.begin(), s.end() ,s.begin(), &delete_ptr);
}
looks as though sufficiently stupid implementations of transform() and
vector<T>::iterator::operator* could trigger the problem.)
[...]
Best
Kai-Uwe Bux
ps.: I also start wondering whether the assumption that invalid int* are
actually objects of type int* is well-founded. I.e.:
int* a = new int (3);
int* b = a;
delete a;
// does the lvalue b refer to an object of type int* ?
My reason to wonder is [4.1/1] which ought to imply that an lvalue to rvalue
conversion for b is UB. However, if b is an object of type int*, I don't see
how the wording would imply UB. If b is not an object of type int*, then the
issue about containers may not be about CopyConstructible at all: it might
be about a vector<T> whose elements are not objects of type T.