Re: Languages don't matter. A mathematical refutation

["G.B." <bauhaus@futureapps.invalid>]

On 10.04.15 01:35, Randy Brukardt wrote:
> But how to do tracing without a lot of overhead??

One lightweight way of allocating and tracing might be so
dumb that it is not always useful. But I don't know if
it is never useful, or not useful enough to be considered.
The point is to really request memory once, and then to do
almost nothing. Nothing new here (arena pools).

Imagine a procedure that manipulates a graph.
Or tons of matrices. Or a sequence of short messages.
You need "new T" for the objects(*).

1 - require the pool to have enough room for Max objects:
     one stretch of storage.

2 - make Allocate return the address of the next free
     storage element, etc.; remember the then next free
     storage element in the pool object.

3 - Deallocate does nothing.

When the region ends, Finalize of the pool frees memory.
So, I guess tracing overhead is one assignment for
keeping track of the next free storage element's address.

Depending on the algorithm, this might be wasteful or,
on the contrary, use no more memory than the algorithm
needs in any case. And the programmer does not need to
consider Unchecked_Deallocation and finalization of the
objects. (And one doesn't add a tag to all of the objects
of that one specific type that the algorithm is using!
1st level cache is a scarce resource… ;-)

That tie is inflexible anyway: Rather than turning some
final event in an objects life into its only catch all,
I'd find it more clear and more explicit to have objects
that can react to events, somewhat like POs can react to
interrupts. Freeing memory need not be an immediate
consequence of some object's finalization.

__
(*) With GCC, no large objects can be allocated on the
stack anymore.