• Taylor Hillegeist (5/5) Oct 02 2015 I do not come from a c++ background. but have looked at what
• Laeeth Isharc (12/17) Oct 02 2015 others will give better answers. I suppose containers (I think
• Jonathan M Davis via Digitalmars-d-learn (27/32) Oct 03 2015 That's very much an open question. It's too early to tell, I think. Anot...
• Rikki Cattermole (17/22) Oct 03 2015 All of my code here uses it: https://github.com/rikkimax/alphaPhobos

Taylor Hillegeist <taylorh140 gmail.com> writes:

I do not come from a c++ background. but have looked at what 
allocators do for c++. I know in D the standard for memory 
management is garbage collection and if we want to manage it 
ourselfs we have to do things like  nogc. I was just curious how 
the std allocator will change how we do things.

Laeeth Isharc <spamnolaeeth nospamlaeeth.com> writes:

On Friday, 2 October 2015 at 23:54:18 UTC, Taylor Hillegeist 
wrote:
 I do not come from a c++ background. but have looked at what 
 allocators do for c++. I know in D the standard for memory 
 management is garbage collection and if we want to manage it 
 ourselfs we have to do things like  nogc. I was just curious 
 how the std allocator will change how we do things.

others will give better answers.  I suppose containers (I think 
one of Andrei's next projects) will make a big difference.  you 
can look at the following, which is used by EMSI in production 
(and now based on Andrei's allocator), a company whose work was 
recently profiled by the New York Times.

https://github.com/economicmodeling/containers

btw you use nogc if you want to be sure you are not allocating by 
mistake (or track down rogue allocations you hadn't thought 
about).  and it gives users of your code confidence.  but if you 
don't allocate much, you don't absolutely need to use nogc.

Jonathan M Davis via Digitalmars-d-learn writes:

On Friday, October 02, 2015 23:54:15 Taylor Hillegeist via Digitalmars-d-learn
wrote:
 I do not come from a c++ background. but have looked at what
 allocators do for c++. I know in D the standard for memory
 management is garbage collection and if we want to manage it
 ourselfs we have to do things like  nogc. I was just curious how
 the std allocator will change how we do things.

That's very much an open question. It's too early to tell, I think. Another
major factor is that Walter and Andrei are considering adding some kind of
reference counting to the language (not ARC, I don't think, and it won't be
required - just in addition to what we have now), and that would have a big
impact on this sort of thing as well. I fully expect that exceptions will
eventually be reference-counted, and it may become normal for them not to be
GC-allocated as a result. But we'll have to wait and see.

Another issue is std.container (or probably std.collections ultimately,
since it's being redone, and we don't want to conflict with what's currently
there), since that will end up using the allocators, and the impact of that
could be far-reaching. For many programs, it'll probably be the only place
that allocators get used though, simply because many folks are likely to
just not worry that much about the GC and memory management until it
actually becomes a problem for them. The folks that have stricter
performance requirements will likely start using the allocators quite a bit
though.

Certainly, now that we have std.experimental.allocator, more code is going
to be written which tries to avoid the GC, and as that's done, I expect that
more idioms will come of it. The way that the allocators have been written
is somewhat novel and unique, but I don't know how much that will affect
their usage. In the long run though, I suspect that allocators will get used
in D more than they're typically used in C++ - if nothing else because the
GC is the default in D, and plenty of folks want to avoid the GC whether
they actually need to or not, whereas C++'s default is manual memory
management.

- Jonathan M Davis

Rikki Cattermole <alphaglosined gmail.com> writes:

On 03/10/15 12:54 PM, Taylor Hillegeist wrote:
 I do not come from a c++ background. but have looked at what allocators
 do for c++. I know in D the standard for memory management is garbage
 collection and if we want to manage it ourselfs we have to do things
 like  nogc. I was just curious how the std allocator will change how we
 do things.

All of my code here uses it: https://github.com/rikkimax/alphaPhobos
With any luck it will all be destined for Phobos.

The biggest set of changes is visible with the image library and URI.
https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/uri.d

You care far more about not allocating because of it. Atleast that was 
my goal.
Something I'm definitely recently started getting into is ref counting.
https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/platform.d#L16

So both the memory can be exposed and deallocated when it is no longer used.
But generally you won't care one bit about allocators.
https://github.com/rikkimax/alphaPhobos/blob/master/source/app.d#L39

The only reason you need to care is if you want a very specific set of 
life time of all memory created in a api and know/care when it dies.
Also if you got some clever way to allocate, too would matter.
But this may be different for somebody else. It is just my limited 
experience.