D 2015/2016 Vision?

[Paulo Pinto via Digitalmars-d]

On Wednesday, 7 October 2015 at 12:56:32 UTC, bitwise wrote:
> On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto wrote:
>> On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise 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
>
> Still no ;)
>
> It's a Texture. It's meant to be seen on the screen for a 
> while, not destroyed in the same scope which it was created.
>
> In games though, we have a scene graph. When things happen, we 
> often chip off a large part of it while the game is running, 
> discard it, and load something new. We need to know that what 
> we just discarded has been destroyed completely before we start 
> loading new stuff when we're heavily constrained by memory. And 
> even in cases where we aren't that constrained by memory, we 
> need to know things have been destroyed, period, for non-memory 
> resources. Also, when using graphics APIs like OpenGL, we need 
> control over which thread an object is destroyed in, because 
> you can't access OpenGL resources from just any thread. Now, 
> you could set up some complicated queue where you send textures 
> and so on to(latently) be destroyed, but this is just 
> complicated. Picture a Hello OpenGL app in D and the hoops some 
> noob would have to jump through. It's bad news.
>
> Also, I should add, that a better example of the Texture thing 
> would be a regular Texture and a RenderTexture. You can only 
> draw to the RenderTexture, but you should be able to apply both 
> to a primitive for drawing. You need polymorphism for this. A 
> struct will not do.
>
>     Bit

I guess you misunderstood the // Somewhere in the call stack

It is meant as the logical region where that scene graph block 
you refer to is valid.

As for OpenGL being complex, fear not, Vulkan, Metal and DX 12 
are here to help (ca 600 LOC for a triangle). :)

And both Java and .NET do offer support such type of queues as 
well.

Anyway I was just explaining what is possible when one embraces 
the tools GC languages offer.

In general, I advocate any form of automatic memory/resource 
management. With substructural type systems now being my 
favorite, but they still have an uphill battle for adoption.

Also as a note, Microsoft will be discussing their proposed C++ 
solution with the Rust team.

--
Paulo