This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: noexcept move on containers (e.g. list)


On Wed, 18 Sep 2013, Daniel Krügler wrote:

On Wed, 18 Sep 2013, Daniel Krügler wrote:

On 18 September 2013 09:58, Jonathan Wakely <jwakely.gcc@gmail.com>
wrote:

[..]

Although as you're asking specifically about move constructors (which
I don't think we check any preconditions on anyway) I don't know why
the standard considers them to have narrow contracts.


I'm pretty sure that this wasn't the intention of N3279 to imply. To
my knowledge the reason why the move constructors of containers are
not noexcept, is because the default constructors aren't and this
again was due to some existing implementations that could throw (in
rare situations).


As far as I can see, an allocator's default constructor, if it exists, is
allowed to throw (as opposed to its move constructor which isn't), which
implies the same for a container using this allocator. So the default
constructor can't be made noexcept, while the move constructor could,
although that would prevent an implementation from using a short-string-like
optimization in those containers (I didn't check if that was already illegal
for other reasons).

Ah, yes, I think you are right: Presumably for that reason
allocator_traits::select_on_container_copy_construction has no
noexcept specifier either. On the other hand, allocator[_traits]'s
destroy function is also not noexcept and I believe that having no
guarantee that these latter functions never throw looks like a defect
of the library specification to me.

Yes, I wondered about that. Since destructors are guaranteed not to throw, I may have extrapolated that destroy wouldn't either in my latest patch... (though the code was already making this assumption in other places)

It would be good to add the corresponding line to the standard. Can you handle the new issue, Daniel? Or do you want me to try and write a few lines?

--
Marc Glisse


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]