Re: Allocators and exceptions

"Simon Wright" <simon.j.wright@xxxxxxx> wrote in message
news:m2abrro3f0.fsf@xxxxxxxxxx
"Randy Brukardt" <randy@xxxxxxxxxxxxxx> writes:
....
The "proper" way to handle this is to ensure that default initialize
of an object never propagates an exception, and then wrap the
allocator properly:

type Access_T is access all T;
procedure Free is new Unchecked_Deallocation (T, Access_T);
function Alloc_Object (...) return Access_T is
A_T : Access_T := new T; -- Default initialized.
begin
A_T.all := <constructor>;
return A_T;
exception
when others => Free(A_T); return null;
end Alloc_Object;

I guess I had misunderstood what's meant by 'constructor', becasue
this is just what I had in mind ... and there are far worse things to
leak than memory, such as locks, file handles, data structure
integrity etc, and those we can handle even in a constructor (ie
function returning a value of the type rather than a pointer to a new
value of the type).

The problem with this sort of construction (besides that it is clunky) is
that is doesn't work for limited types without breaking abstraction. OTOH,
the leak in this case doesn't bother me too much, because constructor
failure ought to be rare and it is also rare to be creating a lot of
objects -- so it usually doesn't matter. Moreover, safety critical
applications aren't going to be using allocators in the first place, and
very long-running applications are likely to have problems with memory
fragmentation even if they don't leak any memory -- unless they have a lot
more memory available than they're going to need. Still, the leak is
uncomfortable - it doesn't match Ada's goals.

Randy.


.

Relevant Pages

  • Re: new keyword
    ... Call constructor for object placed into allocated memory ... If an exception is thrown from the constructor, handle it, cleanup ... re-throw the exception up the stack. ... instantiate one in an available subblock. ...
    (microsoft.public.vc.mfc)
  • Re: is such exception handling approach good?
    ... here if you get a memory exception in m_pConn you get a memory leak in ... m_pBuff since the dtor will not be called. ... has been created you can't clean it up in your exception handler. ... of them in constructor; sometimes all of them. ...
    (microsoft.public.vc.language)
  • Re: new keyword
    ... all required memory (what happens or which exception is thrown depends ... configured to have "new" return NULL if it fails to allocate. ... by the underlying object's constructor will be destructed, ... memory allocated by "new" will be freed. ...
    (microsoft.public.vc.mfc)
  • Re: Memory Allocation: new int[s] vs. vector<int>p; p(s)
    ... The memory leak issue has to do with when destructors ... get called if an exception is thrown. ... then it occurs before Y's constructor has ... and hence Y's destructor won't get called. ...
    (comp.lang.cpp)
  • Re: exiting a constructor early
    ... what exactly happens to any dynamically allocated memory that was ... | obtained before the exception was thrown? ... but for memory that your object attempts to allocate in the constructor, ... you would have to somehow handle that memory in an appropriate handler, ...
    (alt.comp.lang.learn.c-cpp)