On Thursday, 6 February 2014 at 21:17:24 UTC, Andrei Alexandrescu
wrote:
On 2/6/14, 12:51 PM, Frustrated wrote:
On Thursday, 6 February 2014 at 20:24:55 UTC, Andrei
Alexandrescu
wrote:
On 2/6/14, 12:01 PM, Frustrated wrote:
See the other post about this. scopeDeallocation meant to
simply
signal that the scope of a has ended but not necessarily
there
are no references to a.
So that's a struct destructor.
Andrei
Well, except it hooks into the memory allocation strategy.
I'm not saying that what I outlined above is perfect or the way
to go but just an idea ;)
If new had some way to pass an "interface" that contained the
allocation strategy details and one had the notation like
new!MyManualAllocator A;
then I suppose A's destructor could call MyManualAllocator's
"scopeDeallocator" method and you wouldn't need an implicit
call
there.
What is MyManualAllocator - type or value?
I should emphasize that obsessing over the syntax is
counterproductive. Call a blessed function and call it a day.
It would be more of an abstract type. Something special template
aggregate that the compiler accesses to get code to "hook" in to
the memory management parts of the code the compiler needs, but
has delegated specifics to the "user".
For example,
When the compiler is parsing code and comes across the new
keyword, it has hard coded what to do. Instead, if it delegated
what to do to the code itself(that somebody writes external to
the compiler) then it is more robust.
It is exactly analogous to interfaces, classes vs non-oop
programming. e.g., suppose we wanted a very generic compiler
where the programmer could add his own keywords. Instead of hard
coding the "actions" of the keywords we would delegate
responsibility to the user and provide hooks. When the parser
finds the keyword it simply calls code external to the compiler
instead of hard coded internal code. Of course it can get
complicated real quick but essentially that is what I am talking
about with memory management here. The compiler delegates exactly
what to do external code but provides the necessary hooks to
properly deal with it.
One can argue that we already have the ability to do that by
overriding new and using destructors but these are not general
enough as `new` is hard coded and destruction is not generic
enough.
The only way I can describe it properly is that it it would be
nice to plug and play specific memory management allocators into
the "compiler" so that almost anyone can achieve what they want.
To do this requires more support from the compiler as is, it uses
a hard coded version.
It is exactly analogous to this:
int x = 3; // <-- 3 is hard coded, not generic. Once compiled we
can't change it.
int x = file.read!int("settings.txt", 0); // <-- generic, x is
not fixed at compile time to a specific value. If we need to
change x we can do so.
Now apply the same logic as above but to the compiler and memory
management. Right now D is at the first case(D being X and the GC
being 3) and we want to get to the second case(the text file
being being a specific memory allocation method). file.read then
is what needs to be come up with, which is the way to decouple
the memory allocation scheme and the compiler's dependence on it.
I have no solution to the above... just ideas that may lead to
other ideas and hopefully a feasible solution.
