Boost logo

Boost :

Subject: Re: [boost] Request for help in porting colony to boost from experienced container boost dev
From: Soul Studios (matt_at_[hidden])
Date: 2015-08-28 05:45:28


> That would Ion. See
> https://github.com/boostorg/container/blob/master/meta/libraries.json
> for contact details.

Cool, thanks!

>
> When someone supplies a stateless allocator, like std::allocator<T>,
> the sizeof(allocator) is still 1 and thus the size of your container
> object is increased by 1 when it doesn't need to be. The EBCO (or
> compressed_pair) can be used here to make sure that empty allocators
> do not add the extra +1 byte to your container object storage. This is
> also a commonly used technique in C++ standard library
> implementations, as well as in many Boost libraries that support
> custom allocators and custom deleters.

If you could help me with some basic code here, I'd appreciate it-
I understand what you're saying, but am unsure whether you're meaning to
wrap the allocator instance, or something else entirely.

>> My general feeling is more in line with Mike Acton's in that if something
>> throws, you've got a problem anyway - peaceably unrolling isn't really
>> helping anyone.
>
> You're actually misunderstanding Mike completely, and out of context.

I'm pretty sure I'm not - I watched the entirety of his Data Driven
Design speech at cppcon - several times - and if you watch that he's
very specific.

> Writing generic code around T (value type) or A (allocator type)
> requires that you handle things like this. As I mentioned, the C++
> standard library containers do this. So do Boost library containers.
> If you do things like both allocate and construct, and construction
> throws, and the user of your library has no way to deallocate what
> you've allocated, it completely alienates them using your container in
> any of their generic code where they support T types whose
> constructors can throw, etc.

That's fine, it's just not something I immediately felt was important,
but I can see that it is for boost-
thanks again,
Matt


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk