<div dir="ltr">On 24 May 2013 09:02, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thursday, May 23, 2013 22:02:05 QAston wrote:<br>
> I think that Phobos should have some support for manual memory<br>
> management. I don't mean clearing out the gc usage there, as it's<br>
> fairly obvious. I rather think about something like<br>
> unique_ptr/shared_ptr in the std. I think unique_ptr can't be<br>
> implemented without rval refs, also C++ sollutions may not fit<br>
> here. Anyways, now it's not so straightforward how to live<br>
> without gc so standard sollution would be really helpful.<br>
<br>
</div>We have std.typecons.RefCounted, which is basically a shared pointer.<br></blockquote><div><br></div><div style>I've always steered away from things like this because it creates a double-indirection.</div><div style>
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.</div><div style>This means the refCount doesn't pollute the class/structure being ref-counted, or avoids a double-indirection on general access.</div>
<div style>It will be slightly slower to inc/decrement, but that's a controlled operation.</div><div style>I would use a system like this for probably 80% of resources.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> Also, it should be visible in C++/D that D can really deal with<br>
> manual memory management conveniently - when I checked out Dlang<br>
> first time I felt very disappointed that "delete" operator is<br>
> deprecated. "So - they advertise one can code without GC, yet<br>
> they seem to deprecate the operator" - false claims discourage<br>
> people from using new languages.<br>
<br>
</div>delete is only used for GC memory, and manual memory management should really<br>
be done with malloc and free rather than explicitly freeing GC memory. But if<br>
you really want to risk blowing your foot off, you can always use destroy to<br>
destroy an object in GC memory and core.memory.GC.free to free it.<br>
<br>
Also, once we get custom allocators, it should be easier to manually manage<br>
memory (e.g. I would assume that it would properly abstract doing malloc and<br>
then emplacing the object in that memory so that you do something like<br>
allocator!MyObject(args) rather than having to deal with emplace directly).<br></blockquote><div><br></div><div style>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.</div>
<div style>One problem is the implicit allocation functions (array concatenation, AA's, etc). How to force those to allocate somewhere else for the scope?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888">
- Jonathan M Davis<br>
</font></span></blockquote></div><br></div></div>