D on next-gen consoles and for game development

[Manu]

On 24 May 2013 09:02, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Thursday, May 23, 2013 22:02:05 QAston wrote:
> > I think that Phobos should have some support for manual memory
> > management. I don't mean clearing out the gc usage there, as it's
> > fairly obvious. I rather think about something like
> > unique_ptr/shared_ptr in the std. I think unique_ptr can't be
> > implemented without rval refs, also C++ sollutions may not fit
> > here. Anyways, now it's not so straightforward how to live
> > without gc so standard sollution would be really helpful.
>
> We have std.typecons.RefCounted, which is basically a shared pointer.
>

I've always steered away from things like this because it creates a
double-indirection.
I have thought of making a similar RefCounted template, but where the
refCount is stored in a hash table, and the pointer is used to index the
table.
This means the refCount doesn't pollute the class/structure being
ref-counted, or avoids a double-indirection on general access.
It will be slightly slower to inc/decrement, but that's a controlled
operation.
I would use a system like this for probably 80% of resources.

> Also, it should be visible in C++/D that D can really deal with
> > manual memory management conveniently - when I checked out Dlang
> > first time I felt very disappointed that "delete" operator is
> > deprecated. "So - they advertise one can code without GC, yet
> > they seem to deprecate the operator" - false claims discourage
> > people from using new languages.
>
> delete is only used for GC memory, and manual memory management should
> really
> be done with malloc and free rather than explicitly freeing GC memory. But
> if
> you really want to risk blowing your foot off, you can always use destroy
> to
> destroy an object in GC memory and core.memory.GC.free to free it.
>
> Also, once we get custom allocators, it should be easier to manually manage
> memory (e.g. I would assume that it would properly abstract doing malloc
> and
> then emplacing the object in that memory so that you do something like
> allocator!MyObject(args) rather than having to deal with emplace directly).
>

Custom allocators will probably be very useful, but if there's one thing
STL has taught me, it's hard to use them effectively, and in practise,
nobody ever uses them.
One problem is the implicit allocation functions (array concatenation,
AA's, etc). How to force those to allocate somewhere else for the scope?


> - Jonathan M Davis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130524/f0c3e21a/attachment.html>