Re: Safe reuse of allocated storage
On Feb 7, 11:53 am, Juan Pedro Bolivar Puente <raskolni...@es.gnu.org>
wrote:
The Rules As Written make new and malloc special to the compiler and
language, and basically disallow general purpose memory allocators
written on top of system allocators (like new and malloc). This is
despite well accepted practice to the contrary, such as various open
source general purpose pooling memory allocators. I find it hard to
fathom that the C and C++ standards really intended to prohibit
general purpose userland pooling memory allocators.
I don't understand why the technique exposed by the OP would be
unsuitable to build such pooling memory allocator. All you have to do it
to keep the pointer in the pool as raw void*, something that actually
you should be doing anyway to keep generated code bloat low.
I don't understand what the void* has to do with anything. Let me
explain with the following (incomplete) program:
#include <new>
#include <stddef.h>
class UserspaceAllocator
{
public:
void* alloc(size_t );
void free(void* );
};
int main()
{
UserspaceAllocator alloc;
struct Foo { Foo(int& x) : x_(x) {} int& x_; };
int x, y;
void* p = alloc.alloc(sizeof(Foo));
Foo* foo = new(p) Foo(x);
foo -> ~Foo();
alloc.free(p);
// Line A
p = alloc.alloc(sizeof(Foo)); // Line B
foo = new(p) Foo(y); // Line C
return foo->x_;
}
Let's assume that the userspace allocator returns the same piece of
memory for both allocation requests.
Now, let's look at the text of N3225 - 3.8/7:
If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied,
The object's lifetime ends at line A. The storage is not reused at
line A, and it is not released at line A. Releasing memory has a very
specific definition in the C++ standard which means that the memory is
returned to "the system" ala std::free, operator delete, and so on.
Simply returning it to a userspace memory allocator isn't the same.
That's what the "reuse" is meant to cover. (At least, I'm pretty sure.
That appears to be the only sensible reading.)
a pointer that pointed to the original object [...] can be used to manipulate the new object, if:
Now, it's a little unclear here. Do they mean pointer value, or
pointer variable, or pointer object? At lines B and C, I have the same
pointer variable, the same pointer object, and under this thought
experiment the same pointer value as we assumed that the userspace
memory allocator returned the same piece of memory for both allocation
requests. So, while it is vague, I satisfy all reasonable
interpretations.
[...]
- the type of the original object is not const-qualified, and, if a class type, does not contain any non-static data member whose type is const-qualified or a reference type, and
Well, damn. Our type Foo has a non-static data member whose type is a
reference type. As I don't satisfy this bullet, I don't satisfy "a
pointer that pointed to the original object [...] can be used to
manipulate the new object, if:", which means that I cannot use that
pointer to manipulate the new object. This means that using the
pointer to manipulate the new object is undefined behavior. Thus my
(incomplete) program above has undefined behavior when the userspace
allocator returns the same piece of memory for both allocation
requests, and thus a general purpose userspace pooling memory
allocator cannot be written in C++ under the draft standard N3225.
You might be able to weasel your way out by saying that the two
pointer values aren't the same pointer value, even though they have
the same bit representation. You could argue that the data flow which
led to the pointer value, such as whether it came from a memberof
expression or an explicit cast, affects the pointer value (as was just
done on comp.std.c by some person), but I really don't like such
reasoning. I don't like it because it doesn't appear anywhere in the
standard AFAIK, and because it violates the community's general
understanding of what it means to say two pointer values are
equivalent.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]