Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector

[H. S. Teoh]

On Thu, Jan 09, 2014 at 08:40:29AM +0000, digitalmars-d-bounces at puremagic.com wrote:
> On Thursday, 9 January 2014 at 07:07:29 UTC, Walter Bright wrote:
> >and it works without copying in D, it just returns s1. In C, I
> >gotta copy, ALWAYS.
> 
> Only if you write libraries, in an application you can set your own
> policies (invariants).

Yes, programming by convention, which falls flat as soon as you have a
large team on the project, and people don't know your conventions
(you'll be surprised how many "seasoned" programmers will just walk all
over your code writing what they're used to writing, with no thought to
read the code first and figure out how their code might fit in with the
rest). I see lots of this at my job, and it inevitably leads to
problems, because in C, people just *expect* the usual copying
conventions. Sure, if you're a one-man project, then you can remove some
of this copying, but rest assured that in a team project things will go
haywire, and inevitably you'll end up dictating that everyone must copy
everything because that's the only way to guarantee module X, which is
written by team B, doesn't do something screwy with our data.


> >(C's strings being 0 terminated also forces much extra copying,
> >but that's another topic.)
> 
> Not if you have your own allocator and split chopped strings (you
> can just overwrite the boundary character).

You can't do this if the caller still wishes to retain the original
string.


> >The point is, no matter how slow the GC is relative to malloc, not
> >allocating is faster than allocating, and a GC can greatly reduce
> >the amount of alloc/copy going on.
> 
> But since malloc/free is tedious c-programmers tend to avoid it by
> embedding objects in large structs and put a variable sized object
> at the end of it... Or have their own pool (possibly on the stack at
> the location where it should be released).
[...]

One thing I miss in D is a nice way to allocate structs with a
variable-length "static" array at the end. GCC supports this, probably
as an extension (I don't remember if the C standard specifies this). I
know I can just manually allocate this via core.gc and casts, but a
built-in solution would be really nice.


T

-- 
Sometimes the best solution to morale problems is just to fire all of the unhappy people. -- despair.com