On 2/6/14, 9:54 AM, Frustrated wrote:
Any time you hard code code something you are also creating
constraints. If people build something on top of what you have
built they inherit those constrains.
Nice thought.
So, why not create a design pattern that allows one, at compile
time, to use any specific memory management technique they want
for the runtime and library(and user code)?
We have a very powerful mechanism for what could be called "statically
deferred committal": templates. Phobos did a great job at not committing
to e.g. range representation or string representation. It seems to me we
have a clean shot at applying the wealth of knowledge and experience we
accumulated with that, to deferring approaches to allocation.
e.g., switches could be used to recompile the source when a
different pattern is desired or libraries could be created that
use different methods. e.g., phobos64GC.lib.
That won't even be necessary with templates. It would be necessary if we
have some sort of global flag dictating a fundamental fork.
To make any of this work, and work efficiently, one must abstract
what is common between all memory management techniques.
Since allocation is always explicitly defined, it is easy to
handle. Which every memory management technique is used, it
would be called/notified on allocation. The deallocation is the
tricky part. (reallocation is another potential issue)
Yah, std.allocator aims at formalizing that (in an untyped manner).
For manual memory management the deallocation is explicitly
called by the user. This in and of itself is significant and
either allows the compiler to know that manual memory management
is used or to replace it with automatic management if desired.
e.g.,
{
auto a = new!strategy A;
release a; // <- explicit deallocation: replaced with
strategy.explicitDeallocation(a);
}
vs
{
auto a = new!strategy A;
// implicit deallocation: compiler inserts
strategy.scopeDeallocation(a);
}
I don't think this works. The scope of "strategy" and "a" may be
unrelated. More importantly a may be escaped (e.g. by passing it to
functions etc) unbeknownst to "strategy", which in fact suggests that
the strategy must be somehow known by "a" independently.
(Stopped reading here.)
Andrei
