Re: deleting dynamically allocated objects in a container
Alf P. Steinbach /Usenet wrote:
* Kai-Uwe Bux, on 10.08.2010 18:12:
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] );
}
...
};
In general no, because [] shall have constant complexity, and with the
above, the complexity depends on the type T.
Hm, interesting point. I was under the impression that the requirements for
std::vector<T> are somewhat separate for each T. Have to think about this.
However you can always adjust the example to work around that.
True.
And then it's pedantically-formally allowed, just as a 1 GiB size for
'bool' is pedantically-formally allowed. Both means pedantically-formal
UB, like
int main() { bool b; }
because it just might exhaust the resources available.
Well, there still is a difference between UB on the level of the abstract
machine and UB because of resource limitations.
It's nothing to worry about.
I know that, you know that, you even know that I know that. Nobody ever
claimed that there is a reason to worry.
I get the feeling, you got the discussion the wrong way. This _never_ was
intended as a suggestion to change the code. James stated in his first post
that it is "purely formally" undefined behavior (right or wrong in the
assessment of UB, he left no doubt that there is nothing to worry about from
a practical point of view). Now, you introduce "pedantically-formal" UB.
Well, so be it.
I considered the whole point of the interpretation as hinting toward
suboptimal wording of the standard not hinting toward bad coding of the OP
or anybody else.
When we talk about UB we don't consider such things, because it is in the
end about practical real problems. If an actually used compiler or
standard library implementation starts exhbiting behavior like that, then
it might be in order to submit a Defect Report. Until then, common sense
rules. :-)
Then, maybe I should embark on the project: The C++ Compiler from Hell :-)
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.)
Yeah, but Stroustrup makes the valid assumption that such a sufficiently
stupid implementation will simply not be used.
Again, this is more about the wording of the standard than the quality of
code.
[...]
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.
Well the standard could have been more clear, yes. But I think in the end
it's just a question of practicality. Formal considerations can only go
some way, beyond a certain point treating the standard as a mathematically
rigorous document just yields absurdities, like, a pedantically-formally
possible implementation with 1 GiB 'bool' that would never be used in
practice.
Yes, the standard could be clearer. And, among other things, that one can
get into absurdities testifies to this.
So, (a) with a given standard, one has to use common sense to arrive at the
intent; and I don't think anybody ever stated that the intent of the
standard is to render the code UB. All that was stated is that the standard
_implies_ the code to be UB -- which you now agree to, though for completely
different reasons (after all, T* can also be 1G:-).
But (b), one can also watch out for spots in the standard that can be
improved. I think, this issue shows one. And I also think that C++0x will
improve upon the current state of affairs.
Best
Kai-Uwe Bux