digitalmars.D.learn - How will std.allocator change how we program in D?
- 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
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.
Oct 02 2015
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.
Oct 02 2015
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
Oct 03 2015
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.
Oct 03 2015