<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 May 2013 09:57, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Friday, May 24, 2013 09:42:10 Manu wrote:<br>
> On 24 May 2013 09:02, Jonathan M Davis <<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>> wrote:<br>
> > 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>
> > We have std.typecons.RefCounted, which is basically a shared pointer.<br>
><br>
> I've always steered away from things like this because it creates a<br>
> double-indirection.<br>
> I have thought of making a similar RefCounted template, but where the<br>
> refCount is stored in a hash table, and the pointer is used to index the<br>
> table.<br>
> This means the refCount doesn't pollute the class/structure being<br>
> ref-counted, or avoids a double-indirection on general access.<br>
> It will be slightly slower to inc/decrement, but that's a controlled<br>
> operation.<br>
> I would use a system like this for probably 80% of resources.<br>
<br>
</div>We use smart pointers where I work and it's a godsend for avoiding memory<br>
problems. We almost never have them whereas the idiots who designed the older<br>
software used manual refcounting everywhere, and they had tons of memory<br>
problems. But while we need to be performant, we don't need to be performant<br>
on quite the level that you do. So, maybe it's more of a problem in your<br>
environment.<br>
<div class="im"><br>
> > Also, it should be visible in C++/D that D can really deal with<br>
> ><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>
> > delete is only used for GC memory, and manual memory management should<br>
> > really<br>
> > be done with malloc and free rather than explicitly freeing GC memory. But<br>
> > if<br>
> > you really want to risk blowing your foot off, you can always use destroy<br>
> > 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<br>
> > manage<br>
> > memory (e.g. I would assume that it would properly abstract doing malloc<br>
> > 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<br>
> > directly).<br>
><br>
> Custom allocators will probably be very useful, but if there's one thing<br>
> STL has taught me, it's hard to use them effectively, and in practise,<br>
> nobody ever uses them.<br>
<br>
</div>Well, as Andrei said, they're hard, which is why they aren't done yet. Another<br>
think to think about with regards to C++ though is the fact that its new and<br>
delete don't having anything to do with a GC, so it has a built-in nice way of<br>
allocating memory which is managed manually, whereas in D, we're forced to use<br>
emplace, which is a lot more of a hassle. Even simply having something like<br>
allocator.make!MyObj(args) and allocator.free(args) would really help out.<br>
There's no question though that they get hairier when you start having to<br>
worry about containers and internal allocations and the like. It's a tough<br>
problem.<br>
<div class="im"><br>
> One problem is the implicit allocation functions (array concatenation,<br>
> AA's, etc). How to force those to allocate somewhere else for the scope?<br>
<br>
</div>I would fully expect that they use the GC and only the GC as they're language<br>
constructs, and custom allocators are going to be library constructs. The<br>
allocators may provide clean ways to do stuff like concatenating arrays using<br>
their API rather than ~, but if you really want to manipulate arrays with<br>
slicing and concatenation and whatnot without the GC, I think that you're<br>
pretty much going to have to create a new type to handle them, which is very<br>
doable, but it does mean not using the built-in arrays as much, which does<br>
kind of suck. But for most programs, I would expect that simply managing the<br>
GC more intelligently for stuff that has to be GC allocated would solve the<br>
problem nicely. Kiith-Sa and others have managed to quite well at getting the<br>
GC to work efficiently by managing when it's enabled and gets the chance to run<br>
and whatnot. You have extremely stringent requirements that may cause problems<br>
with that (though Kiith-Sa was doing a game of some variety IIRC), but pretty<br>
much the only way to make it so that built-in stuff that allocates doesn't use<br>
the GC is to use your own version of druntime.<br>
<br>
Kiith-Sa had a good post on how to go about dealing with the GC in performant<br>
code a while back:<br>
<br>
<a href="http://forum.dlang.org/post/vbsajlgotanuhmmpnspf@forum.dlang.org" target="_blank">http://forum.dlang.org/post/vbsajlgotanuhmmpnspf@forum.dlang.org</a><br>
<br>
Regardless, we're not going to get away from some language features requiring<br>
the GC, but they're also not features that exist in C++, so if you really<br>
can't use them, you still haven't lost anything over C++ (as much as it may<br>
still suck to not be able to them), and there are still plenty of other great<br>
features that you can take advantage of.<br></blockquote><div><br></div><div style>/agree, except the issue I raised, when ~ is used in phobos.</div><div style>That means that function is now off-limits. And there's no way to know which functions they are...</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>