John Carmack applauds D's pure attribute

[Dmitry Olshansky]

On 06.03.2012 18:10, Manu wrote:
> On 6 March 2012 15:10, Timon Gehr <timon.gehr at gmx.ch
> <mailto: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?

Just make an enhancement request ;)
Anyway it's good point as long as GC stays sloppy.

> 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
> <mailto: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,
...pointer and it's supposed length and then do something sucky if it 
doesn't fit, like truncate it (strncpy I'm looking at you!).

and that doesn't seem to be the prevailing pattern in D.

There are better abstractions then "pass a buffer".

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

Take into account how much discipline and manpower it took. Yet I 
remember the gory days when libpng segfaulted quite often ;)


> Havoc, PhysX, FMod, etc are C++, but very light C++, light classes, no
> STL, etc.

Havoc is pretty old btw, back in the days STL implementation + c++ 
compiler combination used to be slow and crappy, partly because of poor 
inlining. Here comes so-called "abstraction cost" it's almost the other 
way around nowdays.

> Unreal used to use STL... but they fixed it :P


-- 
Dmitry Olshansky