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

Manu turkeyman at gmail.com
Wed Jan 8 22:11:38 PST 2014


On 9 January 2014 13:08, Walter Bright <newshound2 at digitalmars.com> wrote:

> On 1/8/2014 12:23 PM, Benjamin Thaut wrote:
>
>> Additionaly programming with a GC often leads to a lot more allocations,
>>
>
> I believe that this is incorrect. Using GC leads to fewer allocations,
> because you do not have to make extra copies just so it's clear who owns
> the allocations.
>

You're making a keen assumption here that C programmers use STL. And no
sane programmer that I've ever worked with uses STL precisely for this
reason :P
Sadly, being conscious of eliminating unnecessary copies in C/C++ takes a
lot of work (see: time and money), so there is definitely value in
factoring that problem away, but the existing GC is broken. Until it
doesn't leak, stop the world, and/or can run incrementally, it remains no
good for realtime usage.
There were 2 presentations on improved GC's last year, why do we still have
the lamest GC imaginable? I'm still yet to hear any proposal on how this
situation will ever significantly improve...

*cough* ARC...

For example, if you've got an array of char* pointers, in D some can be GC
> allocated, some can be malloc'd, some can be slices, some can be pointers
> to string literals. In C/C++, the array has to decide on an ownership
> policy, and all elements must conform.
>
> This means extra copies.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140109/7fc39d42/attachment.html>


More information about the Digitalmars-d mailing list