Re: Allocators and exceptions

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 11 Wrz, 17:33, Adam Beneschan <a...@irvine.com> wrote:

> It sure seemed to me that one could create an example in which, due to
> a default initialization on a component that contains a function call
> that does some interesting stuff, the automatic reclamation Maciej is
> asking for would lead to a dangling reference or something just as
> bad.

No, there is no such risk. The object that failed to initialized
simply does not exist.

> Maybe something involving a self-pointer in a limited record
> (just to tie it into another thread!).

This limited record does not exist. Its presumably dangling self-
pointer does not exist, neither.
The access to the would-be object is never exposed out of the
allocator, so there is no way for anybody else to get the dangling
pointer.

The possible scenario where it could break could for example involve
the pool: the allocator calls Allocate on the pool and there the pool
registers the access value somewhere; then the initialization fails,
leading to roll-back that includes the call to Deallocate on the same
pool. The pool reclaims memory without unregistering the previously
exposed access value, leading to dangling pointer.

But this is not the problem of the discussed scheme, but rather the
problem of the pool - the same problem would happen with regular new
+Unchecked_Deallocation.

> But I'm still guessing that someone
> could come up with an example that shows that this idea won't work.

For your information, C++ works like that for as long as it has
operator new. If you come up with an example showing that this idea
doesn't work and it's not due to artificially broken environment, I
will ask you to share your findings widely.

Please show me a scheme where the idea breaks, but at the same time
where regular new+Unchecked_Deallocation doesn't.

--
Maciej Sobczak
http://www.msobczak.com/