John Carmack applauds D's pure attribute

[Manu]

On 6 March 2012 15:10, Timon Gehr <timon.gehr at gmx.ch> wrote:

> On 03/06/2012 01:27 PM, Manu wrote:
>
>> concatenation, etc performs bucket loads of implicit GC
>> allocations
>>
>
> a~b
>
> Nothing implicit about that.
>

That is the very definition of an implicit allocation. What about the
concatenation operator says that an allocation is to be expected?
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?
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.

This is my single biggest fear in D. I have explicit control within my
>> own code, but I wonder if many D libraries will be sloppy and
>> over-allocate all over the place, and be generally unusable in many
>> applications.
>>
>
> 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.)


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...
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.
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.



>    Consider C strings. You need to keep track of ownership of it. That
>>    often means creating extra copies, rather than sharing a single copy.
>>
>>
>> Rubbish, strings are almost always either refcounted
>>
>
> Technically, refcounting is a form of GC.


Not really, it doesn't lock up the app at a random time for an
indeterminate amount of time.


or on the stack for
>> dynamic strings, or have fixed memory allocated within structures. I
>> don't think I've ever seen someone duplicating strings into separate
>> allocations liberally.
>>
>
> It is impossible to slice a zero-terminated string without copying it in
> the general case and refcounting slices is not trivial.
>

This is when stack buffers are most common in C.

Who actually uses shared_ptr? Talking about the stl is misleading... an
>>
>> overwhelming number of C/C++ programmers avoid the stl like the plague
>> (for these exact reasons). Performance oriented programmers rarely use
>> STL out of the box, and that's what we're talking about here right?
>>
>
> Possibly now you are the one who is to provide supporting statistics.


Touche :)


If you're not performance oriented, then who cares about the GC either?
>>
>
> There is a difference between not performance oriented and performance
> agnostic. Probably everyone cares about performance to some extent.
>

True.


On 6 March 2012 15:13, Dmitry Olshansky <dmitry.olsh at gmail.com> wrote:

> On 06.03.2012 16:27, Manu wrote:
>
>>   Phobos/druntine allocate liberally - the CRT almost never allocates
>>
>
> 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.
>

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.
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.


Who actually uses shared_ptr?
>>
>
> 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.
> More importantly smart pointers are here to stay in C++.


Everybody eh.. :)
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 ;)
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.
Unreal used to use STL... but they fixed it :P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120306/a047e705/attachment.html>