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: Add std::unordered_* C++11 allocator support


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.


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