<div class="gmail_quote">On 6 March 2012 15:10, Timon Gehr <span dir="ltr"><<a href="mailto:timon.gehr@gmx.ch">timon.gehr@gmx.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On 03/06/2012 01:27 PM, Manu wrote:</div><div class="im"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
concatenation, etc performs bucket loads of implicit GC<br>allocations<br></blockquote><br></div>a~b<br><br>Nothing implicit about that.<br></blockquote><div><br></div><div>That is the very definition of an implicit allocation. What about the concatenation operator says that an allocation is to be expected?</div>
<div>And what if you do a sequence of concatenations: a ~ b ~ c, now I've even created a redundant intermediate allocation. Will it be cleaned up immediately?</div><div>Is there a convenient syntax to concatenate into a target buffer (subverting the implicit allocation)? If the syntax isn't equally convenient, nobody will use it.</div>
<div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
This is my single biggest fear in D. I have explicit control within my<br>own code, but I wonder if many D libraries will be sloppy and<br>over-allocate all over the place, and be generally unusable in many<br>applications.<br>
</div></blockquote><br>IMHO this fear is unjustified. If the library developers are that sloppy, chances are that the library is not worth using, even when leaving all memory allocation concerns away. (It is likely that you aren't the only programmer familiar with some of the issues.)</blockquote>
<div><br></div><div>I don't think it is unjustified, this seems to be the rule in C/C++ rather than the exception, and there's nothing in D to suggest this will be mitigated, possibly worsened...</div><div>Many libraries which are perfectly usable in any old 'app' are not usable in a realtime or embedded apps purely due to its internal design/allocation habits.</div>
<div>Hopefully the D library authors will be more receptive to criticism... but I doubt it. I think it'll be exactly as it is in C/C++ currently.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
Consider C strings. You need to keep track of ownership of it. That<br> often means creating extra copies, rather than sharing a single copy.<br><br><br></div><div class="im">Rubbish, strings are almost always either refcounted<br>
</div></blockquote><br>Technically, refcounting is a form of GC.</blockquote><div><br></div><div>Not really, it doesn't lock up the app at a random time for an indeterminate amount of time.</div><div><br></div><div><br>
</div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">or on the stack for<br>
dynamic strings, or have fixed memory allocated within structures. I<br>don't think I've ever seen someone duplicating strings into separate<br>allocations liberally.<br></blockquote><br></div>It is impossible to slice a zero-terminated string without copying it in the general case and refcounting slices is not trivial.<br>
</blockquote><div><br></div><div>This is when stack buffers are most common in C.</div><div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
Who actually uses shared_ptr? Talking about the stl is misleading... an</div><div class="im"><br>overwhelming number of C/C++ programmers avoid the stl like the plague<br>(for these exact reasons). Performance oriented programmers rarely use<br>
</div><div class="im">STL out of the box, and that's what we're talking about here right?<br></div></blockquote><br>Possibly now you are the one who is to provide supporting statistics.</blockquote><div><br></div>
<div>Touche :)</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If you're not performance oriented, then who cares about the GC either?<br></blockquote><br></div>There is a difference between not performance oriented and performance agnostic. Probably everyone cares about performance to some extent.<br>
</blockquote></div><br><div>True.</div><div><br></div><div><br></div>On 6 March 2012 15:13, Dmitry Olshansky <span dir="ltr"><<a href="mailto:dmitry.olsh@gmail.com">dmitry.olsh@gmail.com</a>></span> wrote:<br><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 06.03.2012 16:27, Manu wrote:</div><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Phobos/druntine allocate liberally - the CRT almost never allocates<br>
</blockquote>
<br></div>
It's just most of CRT has incredibly bad usability, partly because it lack _any_ notion of allocators. And policy of using statically allocated shared data like in localtime, srand etc. shown remarkably bad M-T scalability.<br>
</blockquote><div><br></div><div>I agree to an extent. Most C API's tend to expect you to provide the result buffer, and that doesn't seem to be the prevailing pattern in D.</div><div>Some might argue it's ugly to pass a result buffer in, and I agree to an extent, but I'll take it every time over the library violating my apps allocation patterns.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Who actually uses shared_ptr?</div>
</blockquote>
<br>
Like everybody? Though with c++11 move semantics a unique_ptr is going to lessen it's widespread use. And there are ways to spend less then 2 proper memory allocations per shared_ptr, like keeping special block allocator for ref-counters.<br>
More importantly smart pointers are here to stay in C++.</blockquote><div><br></div><div>Everybody eh.. :)</div><div>Well speaking from within the games industry at least, there's a prevailing trend back towards flat C or C-like C++, many lectures and talks on the topic. I have no contact with any C++ programmers that use STL beyond the most trivial containers like vector. Many games companies re-invent some stl-ish thing internally which is less putrid ;)</div>
<div>Additionally, I can't think of many libraries I've used that go hard-out C++. Most popular libraries are very conservative, or even flat C (most old stable libs that EVERYONE uses, zlib, png, jpeg, mad, tinyxml, etc). Havoc, PhysX, FMod, etc are C++, but very light C++, light classes, no STL, etc.</div>
<div>Unreal used to use STL... but they fixed it :P</div></div>