D 2015/2016 Vision?
Paulo Pinto via Digitalmars-d
digitalmars-d at puremagic.com
Wed Oct 7 01:10:37 PDT 2015
On Wednesday, 7 October 2015 at 07:35:05 UTC, ponce wrote:
> On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto wrote:
>>
>> That no, but this yes (at least in C#):
>>
>> using (LevelManager mgr = new LevelManager())
>> {
>> //....
>> // Somewhere in the call stack
>> Texture text = mgr.getTexture();
>> }
>> --> All level resources gone that require manual management
>> gone
>> --> Ask the GC to collect the remaining memory right now
>>
>> If not level wide, than maybe scene/section wide.
>>
>> However I do get that not all architectures are amendable to
>> be re-written in a GC friendly way.
>>
>> But the approach is similar to RAII in C++, reduce new to
>> minimum and allocate via factory functions that work together
>> with handle manager classes.
>>
>> --
>> Paulo
>
> This is similar to Scoped!T in D. But this is not composable
> either.
> You cannot have a "using()" field in a class object, much like
> you cannot have a Scoped!T field in D. In C#, you still have to
> implement IDispose interface AFAIK.
If you reduce everything to just using(), yes you are right.
However, with a bit of functional programming flavor you don't
really need to implement IDispose.
Just have a wrapper function own the resource.
withLevelManager (mgr => {
//..
Texture text = mgr.getTexture();
});
And when one is able to use languages that offer syntax sugar for
closures as last parameter, it can be improved to
withLevelManager {
//..
Texture text = it.getTexture();
};
No need to implement any interface, just like a RAII handler
implementation in C++.
Of course, this assumes all resources that were allocated via the
level manager are going to die after the scope ends. If any
reference to any of them is kept somewhere else, then something
bad will happen when it gets eventually used again.
Unless I am missing something, at least in the GC languages I am
used to, there isn't a problem with the member fields as long all
resources that require deterministic release follow a similar
pattern. Like with the _ptr<>() classes in C++, new should only
exist in the deepest layers for such classes.
I guess a problem with D is the bugs that interactions between
classes and structs still have.
--
Paulo
More information about the Digitalmars-d
mailing list