Boost logo

Boost :

Subject: Re: [boost] ASIO into the standard (was: Re: C++ committee meeting report)
From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2014-07-08 19:09:19


On 8 July 2014 23:44, Niall Douglas wrote:
> On 8 Jul 2014 at 17:03, Jonathan Wakely wrote:
>
>> On 5 July 2014 21:00, Niall Douglas wrote:
>> > I am grateful for the clarification, but I think my original
>> > statement was correct yes? STL containers don't have a noexcept move
>> > constructor in C++ 11 due to allocators?
>>
>> No, that's not correct.
>>
>> It's because some implementations either need at least one node even
>> in an empty container (which requires the moved-from object to
>> allocate memory after it's move from) or because debugging "safe STL"
>> implementations perform memory allocation during a move.
>>
>> Although those reasons are related to memory allocation, they're not
>> to do with Allocators, the same reasons would apply if everything used
>> malloc().
>
> I think we might be at cross purposes here due to my sloppy phrasing.
>
> I didn't mean that allocators per se are at fault, I did mean that
> the present design of STL allocators are at fault.

And I still disagree.

Some implementations want to allocate memory in their move
constructors. Memory allocation might fail and throw an exception. I
don't see how the STL allocator design has any bearing on that.

> If they had a
> different design the issues you mentioned wouldn't constrain
> noexcept, though they probably would constrain something else even
> more important.
>
> For example, a better allocator design could guarantee that zero
> sized allocations always succeed, or that known temporary allocations
> always use alloca(), or guarantee non-relocating reallocs, or copy on
> write page table duplicate maps. That sort of thing. Such flexibility
> would eliminate the constraints the present design imposes upon their
> users.

But would have no effect on whether move constructors that allocate
memory can throw.


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