nested allocators for containers

[Sean Middleditch]

Ryan,

Regarding the custom allocator interface you needed in embedded for objects inside containers, have you seen the C++11 allocator improvements for this feature? Namely:

uses_allocator: http://en.cppreference.com/w/cpp/memory/uses_allocator

scoped_allocator_adaptor: http://en.cppreference.com/w/cpp/memory/scoped_allocator_adaptor

The interface seems a little obtuse but it sounds like it would support your needs and then some. I don't usually run into nested containers or allocated objects in my work so I've never really investigated these.

[Ryan Ruzich]

It's *oh so very close*, but not quite.  The problem comes into the dirty details in the nesting.  See https://isocpp.org/wiki/faq/cpp11-library#scoped-allocator

1.) To pass the allocator down to containers contained, you have to drop std::String and use just basic_string.  Other types also degenerate when using allocators like this.

2.) I could very well be using it wrong, or not understanding it correctly.  There very well *could* be a way to do this currently in the STL.  It's non-obvious from digging through the types and containers currently, but I'm going over it with a fine toothed comb.

I'm thinking something like this could be nice:

Or std::vector<myComplexType, PoolAllocator> myVec;

myVec.allocator(MyPoolAllocatorInstance);

std::Vector fails to specialize if myComplexType doesn't support .allocator(PoolAllocator>, etc.

Or std::vector<myComplexType, StackAllocator> myVec;

No need to associate myVec with an instance..it can just use the default StackAllocator.

Allocation strategies are complicate..I'm not sure what should be in the standard, what should be in the library, and what should be in user land, but it should be pretty easy to write and support a custom user allocator in the STL.  I could be silly stupid and just don't see an easy way.

[Sean Middleditch]

On Tuesday, September 16, 2014 12:22:52 PM UTC-7, Ryan Ruzich wrote:

It's *oh so very close*, but not quite.  The problem comes into the dirty details in the nesting.  See https://isocpp.org/wiki/faq/cpp11-library#scoped-allocator

1.) To pass the allocator down to containers contained, you have to drop std::String and use just basic_string.  Other types also degenerate when using allocators like this.

2.) I could very well be using it wrong, or not understanding it correctly.  There very well *could* be a way to do this currently in the STL.  It's non-obvious from digging through the types and containers currently, but I'm going over it with a fine toothed comb.

Perhaps we should ask STL or Marshal or another implementer? Surely they'd have knowledge about the ins and outs at least through test cases if nothing else.

[Ryan Ruzich]

Got a reply back from STL.  I'll paraphrase, since I didn't ask for his permission to repost, but he joked that even he doesn't understand scoped_allocator.  I think people are still churning the allocator model, for good, bad, or ugly.  It's probably too much to bite off for a first pass. I did come up with a hacky pattern for a unique ptr to control the lifetime of an object created on an aligned buffer with placement new.  

[Patrice Roy]

The person to ask is Alisdair Meredith. He has a thorough understanding of this topic. I could not find online information on this last year, but I got everything I needed from his talks at cppcon, namely:

Part I : https://www.youtube.com/watch?v=YkiYOP3d64E
Part II : https://www.youtube.com/watch?v=Q5kyiFevMJQ

He goes into a lot of detail, but I guess that what you guys are looking for.

[Jonathan Wakely]

On Tuesday, 26 May 2015 03:43:00 UTC+1, Patrice Roy wrote:

The person to ask is Alisdair Meredith. He has a thorough understanding of this topic. I could not find online information on this last year, but I got everything I needed from his talks at cppcon, namely:

Part I : https://www.youtube.com/watch?v=YkiYOP3d64E
Part II : https://www.youtube.com/watch?v=Q5kyiFevMJQ

He goes into a lot of detail, but I guess that what you guys are looking for.

What exactly is the question?

 

Le lundi 22 septembre 2014 08:35:48 UTC-4, Ryan Ruzich a écrit :

Got a reply back from STL.  I'll paraphrase, since I didn't ask for his permission to repost, but he joked that even he doesn't understand scoped_allocator.  I think people are still churning the allocator model, for good, bad, or ugly.  It's probably too much to bite off for a first pass. I did come up with a hacky pattern for a unique ptr to control the lifetime of an object created on an aligned buffer with placement new.  

On Tuesday, September 16, 2014 11:26:31 PM UTC-4, Sean Middleditch wrote:

On Tuesday, September 16, 2014 12:22:52 PM UTC-7, Ryan Ruzich wrote:

It's *oh so very close*, but not quite.  The problem comes into the dirty details in the nesting.  See https://isocpp.org/wiki/faq/cpp11-library#scoped-allocator

1.) To pass the allocator down to containers contained, you have to drop std::String and use just basic_string.  Other types also degenerate when using allocators like this.

Right. If you want "string with custom allocator" then it can't be std::string.

Is that a problem?

 

2.) I could very well be using it wrong, or not understanding it correctly.  There very well *could* be a way to do this currently in the STL.  It's non-obvious from digging through the types and containers currently, but I'm going over it with a fine toothed comb.

 To do what?

[Jonathan Wakely]

On Tuesday, 26 May 2015 03:43:00 UTC+1, Patrice Roy wrote:

The person to ask is Alisdair Meredith. He has a thorough understanding of this topic. I could not find online information on this last year, but I got everything I needed from his talks at cppcon, namely:

Part I : https://www.youtube.com/watch?v=YkiYOP3d64E
Part II : https://www.youtube.com/watch?v=Q5kyiFevMJQ

He goes into a lot of detail, but I guess that what you guys are looking for.

http://accu.org/content/conf2012/JonathanWakely-CXX11_allocators.pdf gives an overview of the same material.

(I've just noticed slide 46 should be talking about POCS and swapping, not POCMA and moving, which was the subject of the previous slide ... copy & paste errors from preparing the slides at the last minute).