On Nov 28, 5:22 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> Amal wrote:
> > But in this case I cannot call deallocate(L) explicitly before the
> > function returns. Do simulators release the storage after the
> > function returns?
>

It shouldn't matter that write may repeatedly reallocate L; L is an
inout parameter and (although it's not explicitly stated as such in
the LRM), 'write' ought to be managing the allocated storage and
updating L appropriately. The only thing that matters is the L that
you are leaving as garbage when you exit.

The "wrapper" above makes sense. Alternately you could return L
directly and rely on the caller to free L (admittedly ugly).

The LRM states that "An implementation may (but need not) deallocate
the storage occupied by an object created by an allocator, once this
object has become inaccessible." So I think the answer to your final
question is "maybe".

If you don't trust your implementation to deallocate L for you, I
don't think you have a much better solution that using the wrapper.

Also, depending on how you want your data formatted, you might also be
able to make creative use of the 'image attribute with catenation to
avoid dynamically allocated objects completely.

HTH,

- Kenn