shared array?
Jonathan M Davis via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Mon Sep 14 13:54:44 PDT 2015
On Monday, September 14, 2015 01:12:02 Ola Fosheim Grostad via Digitalmars-d-learn wrote:
> On Monday, 14 September 2015 at 00:41:28 UTC, Jonathan M Davis
> wrote:
> > Regardless, idiomatic D involves a lot more stack allocations
> > than you often get even in C++, so GC usage tends to be low in
>
> Really? I use VLAs in my C++ (a C extension) and use very few
> mallocs after init. In C++ even exceptions can be put outside the
> heap. Just avoid STL after init and you're good.
>From what I've seen of C++ and understand of typical use cases from other
folks, that's not at all typical of C++ usage (though there's enough people
using C++ across a wide enough spectrum of environments and situations that
there's obviously going to be quite a wide spread of what folks do with it).
A lot of C++ folks use classes heavily, frequently allocating them on the
heap. Major C++ libraries such as Qt certainly are designed with the idea
that you're going to be allocating as the program runs. And C++ historically
has been tooted fairly heavily by many folks as an OO language, in which
case, inheritance (and therefore heap allocation) are used heavily by many
programs. And with C++11/14, more mechanisms for safely handling memory have
been added, thereby further encouraging the use of certain types of heap
allocations in your typical C++ program - e.g. make_shared has become the
recommended way to allocate memory in most cases. And while folks who are
trying to get the bare metal performance that some stuff like games require,
most folks are going to use the STL quite a bit. And if they aren't, they're
probably using similar classes from a 3rd party library such as Qt. It's the
folks who are in embedded environments or who have much more restrictive
performance requirements who are more likely to avoid the STL or do stuff
like avoid heap allocations after the program has been initialized.
So, a _lot_ of C++ code uses the heap quite heavily, and I expect that very
little of it tries to allocate everything up front. I, for one, have never
worked on an application where that even made sense aside from something
very small. I know that applications like that definitely exist, but from
everything I've seen, I'd expect them to be the exception to the rule rather
than the norm.
Regardless, idiomatic D promotes ranges, which naturally help reduce heap
allocation. It also means using structs heavily and classes sparingly
(though there are plenty of cases where inheritance is required and thus
classes get used). And while arrays/strings get allocated on the heap,
slicing seriously reduces how often they need to be copied in memory, which
reduces heap allocations. So, idiomatic D encourages programs to be written
in a way that keeps heap allocation to a minimum. The big place that it
happens in most D programs is probably strings, but slicing helps
consderably with that, and even some of the string stuff can be made to live
on the stack rather than the heap (which is what a lot of Walter's recent
work in Phobos has been for - making string-based stuff work as lazy
ranges), reducing heap allocations for strings ever further.
C++ on the other hand does not have such idioms as the norm or as promoted
in any serious way. So, programmers are much more likely to use idioms that
involve a lot of heap allocations, and the language and standard library
don't really have much to promote idioms that avoid heap allocations (and
std::string definitely isn't designed to avoid copying). You can certainly
do it - and many do - but since it's not really what's promoted by the
language or standard library, it's less likely to happen in your average
program. It's much more likely to be done by folks who avoid the STL.
So, you _can_ have low heap allocation in a C++ program, and many people do,
but from what I've seen, that really isn't the norm across the C++ community
in general.
- Jonathan M Davis
More information about the Digitalmars-d-learn
mailing list