On 15 December 2017 at 21:19, François Dumont wrote: > Here is a patch to fix those failures of the latest report: > > UNRESOLVED: 23_containers/map/modifiers/extract.cc compilation failed to > produce executable > FAIL: 23_containers/set/modifiers/extract.cc (test for excess errors) > UNRESOLVED: 23_containers/set/modifiers/extract.cc compilation failed to > produce executable > FAIL: 23_containers/unordered_map/modifiers/extract.cc (test for excess > errors) > UNRESOLVED: 23_containers/unordered_map/modifiers/extract.cc compilation > failed to produce executable > FAIL: 23_containers/unordered_set/modifiers/extract.cc (test for excess > errors) > UNRESOLVED: 23_containers/unordered_set/modifiers/extract.cc compilation > failed to produce executable > > > Tested under Linux x86_64 Debug mode. > > Ok to commit ?
OK, thanks for fixing it. > Note that I don't understand this in _Rb_tree: > > using insert_return_type = _Node_insert_return< > conditional_t<is_same_v<_Key, _Val>, const_iterator, iterator>, > node_type>; > > Why the conditional_t part ? In Debug mode it is always using iterator and I > don't understand what represent this is_same_v<_Key, _Val> condition. is_same_v<_Keym _Val> is true for sets, false for maps. The condition means that the type uses _Rb_tree<>::const_iterator for sets, and _Rb_tree::iterator for maps. IIRC this is necessary because set::iterator is a typedef for set::const_iterator and that can only constructed from _Rb_tree<>::const_iterator, not from _Rb_tree<>::iterator. So for sets the member of _Rb_tree needs to return a const_iterator. There is no _Rb_tree::insert_return_type in Debug Mode, so you're comparing apples and oranges. The iterator in Debug Mode is either set::iterator (which is the same as set::const_iterator) or map::iterator, not _Rb_tree::iterator.
