This is the mail archive of the
mailing list for the libstdc++ project.
Re: Add std::unordered_* C++11 allocator support
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: François Dumont <frs dot dumont at gmail dot com>
- Cc: Paolo Carlini <paolo dot carlini at oracle dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 2 Apr 2013 22:41:56 +0100
- Subject: Re: Add std::unordered_* C++11 allocator support
- References: <51438861 dot 9010207 at gmail dot com> <5145A358 dot 4020104 at oracle dot com> <CAH6eHdQjrkLFa2rNZnq9ndkBs4sgZ4EXgxSWW=LX0kOK4i88Ww at mail dot gmail dot com> <515B41F5 dot 4040207 at gmail dot com>
On 2 April 2013 21:39, François Dumont wrote:
> Here is an updated, exception safe, version.
Gah, I was still reviewing the last one ;-)
Thanks, I'll go through this tomorrow.
> To validate it I have implemented a number of enhancements to the exception
> test framework, mostly to the basic safety test:
> - The allocator label is incremented throughout all tested methods rather
> than reseted to 0 before each method. Adding more tests I had the problem of
> a container containing memory allocated through a method with label N and
> detected as memory leak when checking an other method later.
> - I have added a check that there is no memory allocated left after all
> methods got tested. To make this assumption sure I prefer to make test_base
> a stateless class and instantiate everything in the run method. This way,
> once outside scope of instantiation, there should be nothing left.
> - I have added check on correct invocation of allocator construct/destroy.
> It is limited to C++11 mode, I will check if I can remove this limitation.
> - I have added check of copy assignment and move assignment for basic
> exception safety
> I plan to add a state information on the throw_allocator_base so that I
> can test exception safety on operations dealing with not equal allocators,
> does it sound ok ?
> I also face an issue regarding implementation of copy assignment
> operator. When allocators are not equal we need to release memory before
> reallocating everything once __alloc_on_copy has been called. The problem is
> that if this method or the allocation following throw we end up with a
> _Hashtable instance having no memory allocated.
Yet another reason why empty hashtables should not require allocation.
> I prefer not to call
> __alloc_on_copy the other way and prepare the _Hashtable for this situation.
> Some code was not expecting 0 buckets, like the % operation, so I had to
> make _Hashtable ready for that adding some __builtin_except calls. Doing so
> I have been able to leave the _Hashtable instance alloc free after a move
> and not reallocate a small number of buckets to surely free it just a little
> bit later.
Sounds good. I'll finish reviewing this ASAP.