Hi
I'd like to propose this patch to avoid std::distance calls. In a number
of situation in algos we already have the size of the buffer we need so
we shouldn't have to compute it again.
I don't think there is any abi concern for this inline constructor,
isn't there ?
*
Hi
Here is this patch again, I consider all your remarks and also made
some changes considering feedback on rbtree patch.
* include/bits/stl_vector.h
(struct _Vector_base<>::_Vector_impl_data): New.
(struct _Vector_base<>::_Vector_impl): Inherit from latter.
On 04/06/2018 23:09, Jonathan Wakely wrote:
On 04/06/18 22:13 +0200, François Dumont wrote:
Hi
I'd like to propose this patch to avoid std::distance calls. In a
number of situation in algos we already have the size of the buffer
we need so we shouldn't have to compute it again.
Just one
es),
the way should provide speedup.
Thanks.
On 24/01/2018 18:23, François Dumont wrote:
Hi
It sounds like a very sensitive change to make but nothing worth figures.
Do you have any bench showing the importance of the gain ?
At least the memory usage optimization is obvious.
O
We reset safe iterator state a lot, quite annoying when debugging.
Comitted as trivial.
2018-06-07 François Dumont
* src/c++11/debug.cc
(_Safe_iterator_base::_M_detach()): Reset state only if needed.
(_Safe_iterator_base::_M_detach_single()): Likewise
On 26/06/2018 18:03, Jonathan Wakely wrote:
On 18/06/18 23:01 +0200, François Dumont wrote:
Hi
I abandon the idea of providing Debug algos, it would be too much
code to add and maintain. However I haven't quit on reducing Debug
mode performance impact.
So this patch make use
On 27/06/2018 02:13, Jonathan Wakely wrote:
On 26/06/18 17:03 +0100, Jonathan Wakely wrote:
On 18/06/18 23:01 +0200, François Dumont wrote:
Hi
I abandon the idea of providing Debug algos, it would be too
much code to add and maintain. However I haven't quit on reducing
Debug mode
On 27/06/2018 22:02, Jonathan Wakely wrote:
On 27/06/18 21:25 +0200, François Dumont wrote:
On 27/06/2018 02:13, Jonathan Wakely wrote:
On 26/06/18 17:03 +0100, Jonathan Wakely wrote:
On 18/06/18 23:01 +0200, François Dumont wrote:
Hi
I abandon the idea of providing Debug algos
Commited attached patch.
It fixes the missing noexcept qualification on a __gnu_debug::vector<>
constructor.
2018-06-27 François Dumont
* include/bits/stl_vector.h
(struct _Vector_base<>::_Vector_impl_data): New.
(struct _Vector_base<>::_Vector_impl): I
r<>, _Sequence>&)): New.
Ok to commit ?
On 02/07/2018 13:57, Jonathan Wakely wrote:
On 01/07/18 21:20 +0200, François Dumont wrote:
Here is a new proposal between yours and mine.
It is still adding a function to wrap what __niter_base unwrap, I
called it __nwrap_iter for
the right thing, no matter the original
iterator type.
I eventually found no issue in the testsuite, despite the
std::equal change. I might have had a local invalid test.
Ok to commit ?
François
On 27/06/2018 22:02, Jonathan Wakely wrote:
On 27/06/18 21:25 +0200, François Dumont wrote
Hi
If not told otherwise I'll commit attached patch tomorrow.
Already discussed here:
https://gcc.gnu.org/ml/libstdc++/2017-10/msg00053.html
François
diff --git a/libstdc++-v3/include/bits/stl_map.h b/libstdc++-v3/include/bits/stl_map.h
index a4a026e..2b8fd27 100644
---
Hi
std::rotate already returns the expected iterator so there is no
need for calls to std::advance/std::distance.
Tested under Linux x86_64, ok to commit ?
François
diff --git a/libstdc++-v3/include/bits/stl_algo.h b/libstdc++-v3/include/bits/stl_algo.h
index e10a692..9c1b2d4 100644
---
Hi
Here is the patch I eventually would like to commit.
Tested under Linux x86_64, ok for trunk ?
François
On 17/04/2018 22:34, François Dumont wrote:
Yes, I also think there is no rush to fix this issue.
I had already written a test for a different purpose using
On 02/05/2018 13:49, Jonathan Wakely wrote:
On 01/05/18 21:56 +0200, François Dumont wrote:
Hi
If not told otherwise I'll commit attached patch tomorrow.
Please do not commit it, see below.
Already discussed here:
https://gcc.gnu.org/ml/libstdc++/2017-10/msg00053.html
There's
On 26/10/2017 19:09, Jonathan Wakely wrote:
On 26/10/17 18:55 +0200, Daniel Krügler wrote:
2017-10-26 7:51 GMT+02:00 François Dumont <frs.dum...@gmail.com>:
Hi
We once talk about rename the __cxx1998 namespace into something
less
C++98 biased. Here is the patch to do so.
Hi
When restoring versioned namespace feature I forgot to check for
the pretty printer tests which are now broken.
Here is the patch to fix those. Tested under Linux x86_64 normal
and versioned namepace modes, ok to commit ?
François
diff --git
Hi
I plan to commit attached patch to fix the __gnu_debug::string
undefined macro.
Is it ok the way I used some tests to now validate
__gnu_debug::string on check-debug ?
François
diff --git a/libstdc++-v3/include/debug/string b/libstdc++-v3/include/debug/string
index
Hi
Bug confirmed, limited to range insertion on unordered_set and
unordered_map.
I had to specialize _M_insert_range for those containers. Now this
method maintains the theoretical number of elements to insert which is
used only if an insertion takes place.
I also took this
Hi
Here is an updated patch.
Tested under Linux x86_64.
Ok to commit ?
François
On 21/08/2017 21:15, François Dumont wrote:
Following feedback on std::list patch this one had the same problem of
unused code being deleted. So here is a new version.
Ok to commit ?
François
On 16/01/2018 01:20, Jonathan Wakely wrote:
On 15/01/18 22:32 +0100, François Dumont wrote:
On 15/01/2018 13:29, Jonathan Wakely wrote:
In fact it introduces a serious regression because of this line:
- vector(vector&& __x) noexcept
- : _Base(std::move(__x)) { }
+
On 24/01/2018 18:53, Petr Ovtchenkov wrote:
On Wed, 24 Jan 2018 17:39:59 +0100
François Dumont <frs.dum...@gmail.com> wrote:
Hi
I'd like to propose this new debug check. Comparing with non-eos
istreambuf_iterator sounds like an obvious coding mistake.
I propose it d
Hi
I'd like to propose this new debug check. Comparing with non-eos
istreambuf_iterator sounds like an obvious coding mistake.
I propose it despite the stage 1 as it is just a new debug check,
it doesn't impact the lib in normal mode.
Tested under Linux x86_64, ok to commit ?
As you know, buffered merge is far speed then (split, rotate, and
merge two sub-arrays) (PR c++/83938 gives the profiling figures),
the way should provide speedup.
Thanks.
On 24/01/2018 18:23, François Dumont wrote:
Hi
It sounds like a very sensitive change to make but nothing wo
Hi
As we just bump version namespace it might be interesting to do the
following change now. What do you think ?
François
diff --git a/libstdc++-v3/include/bits/forward_list.h b/libstdc++-v3/include/bits/forward_list.h
index 56b3ac5..05abd43 100644
---
Hi
Here is a patch to fix some pretty printer check errors when
running those tests with _GLIBCXX_DEBUG.
I introduced a special rendered for the std::forward_list iterator
which is similar to the one used for the std::list and so used
inheritance, I hope it is not a problem for
On 06/02/2018 20:16, François Dumont wrote:
On 05/02/2018 18:16, Jonathan Wakely wrote:
Wouldn't it make more sense to simply make __aligned_buffer identical
to __aligned_membuf for the versioned-namespace? Then at least the
conditional code is only in one place.
Yes, __aligned_buffer
On 05/02/2018 18:16, Jonathan Wakely wrote:
On 01/02/18 22:48 +0100, François Dumont wrote:
Hi
As we just bump version namespace it might be interesting to do
the following change now. What do you think ?
I'd rather not make the code harder to read in all those places just
On 20/02/2018 20:59, Jonathan Wakely wrote:
On 8 February 2018 at 06:10, François Dumont wrote:
On 06/02/2018 20:16, François Dumont wrote:
On 05/02/2018 18:16, Jonathan Wakely wrote:
Wouldn't it make more sense to simply make __aligned_buffer identical
to __aligned_membuf for the versioned
Now backported to branch.
On 24/12/2017 08:55, Jonathan Wakely wrote:
On 19 December 2017 at 21:33, François Dumont wrote:
Hi
I plan to apply attached patch tomorrow to fix those _GLIBCXX_DEBUG
failures:
FAIL: 23_containers/map/modifiers/insert/dr2354.cc (test for excess errors)
FAIL
Hi
Here is a patch to avoid definition of invalid operators on the
Debug mode safe iterator type depending on its category.
Even if it is limited to the Debug mode code I would like to have a
feedback before committing. Especially on the following points:
- _Safe_tagged_iterator:
On 10/08/2018 13:26, Ville Voutilainen wrote:
On 10 August 2018 at 13:47, Jonathan Wakely wrote:
Doing a test like this with TSan should be the absolute minimum
required for any change to the mutex locking policy.
Agreed. Concurrency code is something that our test suite is not
well-equipped
Here is a patch to improve Debug mode safe iterator move semantic.
To summarize where we used to have N mutex locks we now have N - 1.
For instance move constructor used to lock mutex twice, now it only does
it once. Note that move constructor or move assignment operator are
currently
Here is the new proposal. It is indeed possible to keep _Safe_iterator
and just add a _Category template parameter to it.
I introduce a friend declaration to access container _Base nested
typedef from the safe iterator.
I review the safe const_iterator constructor from safe iterator. I now
This test fails when using 'make check-debug' because it redefines
_GLIBCXX_DEBUG. Using dg-options fixes this problem.
Committed as trivial.
François
diff --git a/libstdc++-v3/testsuite/25_algorithms/copy/86658.cc b/libstdc++-v3/testsuite/25_algorithms/copy/86658.cc
index 600747a..dd4f7ba
This patch implements P0646R1 for Debug mode containers.
It fixes tests:
23_containers/forward_list/operations/remove_cxx20_return.cc
23_containers/forward_list/operations/unique_cxx20_return.cc
23_containers/list/operations/remove_cxx20_return.cc
.
On 20/08/2018 22:26, François Dumont wrote:
This patch implements P0646R1 for Debug mode containers.
It fixes tests:
23_containers/forward_list/operations/remove_cxx20_return.cc
23_containers/forward_list/operations/unique_cxx20_return.cc
23_containers/list/operations/remove_cxx20_return.cc
Now that _Safe_iterator has been revisited I would like to cleanup its
operators to make them globals and inline friends as much as possible.
This patch transform operator-(const _Safe_iterator<>&, difference_type)
and operator+(const _Safe_iterator<>&, difference_type) into global
namespace
On 22/08/2018 23:45, Jonathan Wakely wrote:
On 22/08/18 23:08 +0200, François Dumont wrote:
Only operator== and != remains outside _Safe_iterator because all my
attempts to make them inline friends failed. I understand that an
inline friend within a base class is not a very clean design
I missed a test that was failing because of this patch. So I revert a
small part of it and here is the new proposal.
Tested under Linux x86_64, ok to commit ?
François
On 24/07/2018 12:22, François Dumont wrote:
Hi
Any chance to review this patch ?
François
On 06/06/2018 18:39
On 21/08/2018 11:33, Jonathan Wakely wrote:
On 18/08/18 22:31 +0200, François Dumont wrote:
Here is the new proposal. It is indeed possible to keep
_Safe_iterator and just add a _Category template parameter to it.
While this is still a large patch (obviously, because it's changing a
lot!) I
The last optimizations that get disabled when Debug mode is enable are
the algo specializations for std::deque iterators.
This patch move those algos in std namespace as they should even when
Debug mode is enable so that they get considered even when calls are
made with the namespace
On 28/08/2018 21:04, Jonathan Wakely wrote:
On 23/08/18 22:59 +0200, François Dumont wrote:
On 22/08/2018 23:45, Jonathan Wakely wrote:
On 22/08/18 23:08 +0200, François Dumont wrote:
Only operator== and != remains outside _Safe_iterator because all
my attempts to make them inline friends
On 28/08/2018 21:04, Jonathan Wakely wrote:
On 23/08/18 22:59 +0200, François Dumont wrote:
On 22/08/2018 23:45, Jonathan Wakely wrote:
On 22/08/18 23:08 +0200, François Dumont wrote:
Only operator== and != remains outside _Safe_iterator because all
my attempts to make them inline friends
Ping.
On 08/06/2018 07:54, François Dumont wrote:
Gentle reminder.
On 27/05/2018 19:25, François Dumont wrote:
Still no chance to review it ?
I'd like this one to go in before submitting other algo related patches.
* include/bits/stl_algo.h
(__rotate(_Ite, _Ite, _Ite
Hi
It has already been noticed that there are 2 ebo helpers in the
lib. Here is a patch to use 1.
* include/bits/ebo_helper.h: New.
* include/Makefile.am: Add latter.
* include/Makefile.in: Regenerate.
* include/bits/hashtable_policy.h: Adapt.
*
Hi
Any chance to review this patch ?
François
On 06/06/2018 18:39, François Dumont wrote:
Hi
I review and rework this proposal. I noticed that the same idea to
limit buffer size within inplace_merge also apply to stable_sort.
I also change the decision when buffer is too
Thanks for all those explanations. It helped me to find the solution.
So here is the final patch with all operators inline friends.
Tested under Linux x86_64.
* include/debug/safe_iterator.h
(_Safe_iterator<_It, _Seq, std::random_access_iterator_tag>::_Self):
New.
the pass int
value do not match the deque value type.
Ok to commit ?
François
On 09/06/2018 10:07 PM, François Dumont wrote:
On 09/04/2018 02:59 PM, Jonathan Wakely wrote:
template
void
- fill(const _Deque_iterator<_Tp, _Tp&, _Tp*>& __first,
- const _Deque_ite
On 09/04/2018 02:59 PM, Jonathan Wakely wrote:
template
void
- fill(const _Deque_iterator<_Tp, _Tp&, _Tp*>& __first,
- const _Deque_iterator<_Tp, _Tp&, _Tp*>& __last, const _Tp&
__value)
+ fill(const _GLIBCXX_STD_C::_Deque_iterator<_Tp, _Tp&, _Tp*>&
__first,
+ const
could get it from here whatever
the mode activated.
François
On 09/07/2018 06:30 PM, François Dumont wrote:
I realized that I was not checking the Debug implementations.
Doing so also have the advantage to show clearly which overload of the
algos is being used. If it is using the correct Debug
On 08/28/2018 09:00 PM, Jonathan Wakely wrote:
On 25/08/18 22:44 +0200, François Dumont wrote:
The last optimizations that get disabled when Debug mode is enable
are the algo specializations for std::deque iterators.
This patch move those algos in std namespace as they should even when
Debug
This patch improves the assertion message generated in 2
__gnu_debug::string constructors giving the assertion context thanks to
the __FUNCTION__ macro.
Was:
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/string:56:
const _CharT* __gnu_debug::__check_string(const
On 08/03/2018 19:11, Jonathan Wakely wrote:
This caused a new regression for:
std::forward_list flst;
std::forward_list::iterator flstiter0;
// { dg-final { note-test flstiter0 {non-dereferenceable iterator for
std::forward_list}} }
$1 = {_M_node = 0x0}
got: $1 = {_M_node = 0x0}
FAIL:
On 08/03/2018 19:11, Jonathan Wakely wrote:
This caused a new regression for:
std::forward_list flst;
std::forward_list::iterator flstiter0;
// { dg-final { note-test flstiter0 {non-dereferenceable iterator for
std::forward_list}} }
$1 = {_M_node = 0x0}
got: $1 = {_M_node = 0x0}
FAIL:
On 06/03/2018 22:21, Jonathan Wakely wrote:
@@ -575,10 +586,12 @@ class StdDebugIteratorPrinter:
# and return the wrapped iterator value.
def to_string (self):
base_type = gdb.lookup_type('__gnu_debug::_Safe_iterator_base')
+itype = self.val.type.template_argument(0)
Hi
Following PR 78420 patch I realized that we can use similar
technique to have assertions in string_view implementations.
I also rename testsuite files expected to XFAIL as they should have
a trailing '_neg'. It fixes 4 XPASS when run in debug mode
Note that I also try to use
Hi
While working on something else on libstdc++ I started having a
test failing because of the missing comma overload protection in
deque.tcc. So I looked for other similar places in the code and here is
a patch to fix the places I found.
Let me know if it is still time to commit.
On 20/03/2018 19:20, Jonathan Wakely wrote:
On 17 March 2018 at 09:01, Jonathan Wakely wrote:
Native configuration is x86_64-pc-linux-gnu
=== libstdc++ tests ===
Running target unix/-std=gnu++11/-D_GLIBCXX_ASSERTIONS
=== libstdc++ Summary for
Working on iterator == operator I noticed that a comparison in
_Safe_iterator was inconsistent.
* include/debug/debug.h
(_Safe_iterator<>(const _Safe_iterator<_MutableIterator,>& __x)):
Compare __x base iterator with a default initialized iterator of the
same type.
Tested under
This patch makes extensive use of C++11 direct init in
__debug::forward_list.
Doing so I also try to detect useless creation of safe iterators in
debug implementation. In __debug::forward_list there are severals but I
wonder if it is worth fixing those. Most of them are like this:
Here is the patch for _Bit_iterator and _Bit_const_iterator operators.
I noticed that _Bit_reference == and < operators could be made inline
friend too. Do you want me to include this change in the patch ?
* include/bits/stl_bvector.h (_Bit_iterator_base::operator==): Replace
member
I started considering PR libstdc++/68303.
First thing was to write a dedicated performance test case, it is the
unordered_small_size.cc I'd like to add with this patch.
The first runs show a major difference between tr1 and std
implementations, tr1 being much better:
On 10/15/2018 12:10 PM, Jonathan Wakely wrote:
On 15/10/18 07:23 +0200, François Dumont wrote:
This patch extend usage of C++11 direct initialization in
__debug::vector and makes some calls to operator - more consistent.
Note that I also rewrote following expression in erase method
On 10/15/2018 11:36 AM, Jonathan Wakely wrote:
On 12/10/18 18:25 +0200, François Dumont wrote:
Here is the patch for _Bit_iterator and _Bit_const_iterator operators.
I noticed that _Bit_reference == and < operators could be made inline
friend too. Do you want me to include this cha
On 10/15/2018 11:58 AM, Jonathan Wakely wrote:
On 11/10/18 22:46 +0200, François Dumont wrote:
This patch makes extensive use of C++11 direct init in
__debug::forward_list.
Doing so I also try to detect useless creation of safe iterators in
debug implementation. In __debug::forward_list
() + (__first.base() - _Base::cbegin()), this };
The latter version was building 2 safe iterators and incrementing 1 with
the additional debug check inherent to such an operation whereas the new
version just build 1 safe iterator with directly the expected offset.
2018-10-15 François Dumont
* include
On 10/15/2018 12:07 PM, Jonathan Wakely wrote:
On 09/10/18 07:11 +0200, François Dumont wrote:
Here is the communication for my yesterday's patch which I thought
svn had failed to commit (I had to interrupt it).
Similarly to what I've done for associative containers here is a
cleanup
Current build of libstdc++ with --enable-symvers=gnu-versioned-namespace
fails (at least under Linux) because of:
In file included from
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/memory_resource:39,
from
As reported in another mail a symbol is missing.
This patch update test framework so that the problem is obvious and fix it.
* testsuite/util/testsuite_containers.h
(forward_members_unordered<>::forward_members_unordered
(const value_type&)): Add local_iterator pre and post
On 10/18/2018 10:34 PM, Jonathan Wakely wrote:
On 18/10/18 22:12 +0200, François Dumont wrote:
Current build of libstdc++ with
--enable-symvers=gnu-versioned-namespace fails (at least under Linux)
because of:
In file included from
/home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu
I plan to commit the attached patch this week if not told otherwise.
This is to generalize usage of C++11 direct initialization in unordered
containers.
It also avoids a number of safe iterator instantiations.
* include/debug/unordered_map
(unordered_map<>::begin()): Use C++11 direct
I've just reverted the controversial changes.
2018-10-18 François Dumont
Partial revert.
2018-10-08 François Dumont
* include/debug/list (list<>::cbegin()): Use C++11 direct
initialization.
(list<>::cend()): Likewise.
(list<>::erase(const_iterat
On 10/23/2018 11:52 AM, Jonathan Wakely wrote:
On 22/10/18 22:45 +0200, François Dumont wrote:
I plan to commit the attached patch this week if not told otherwise.
Looks good.
This is to generalize usage of C++11 direct initialization in
unordered containers.
It also avoids a number
Some tests dg-prune-output regex need to be adapted to pass when
versioned namespace is activated.
I preferred to add the version namespace in the regex rather than
removing namespace qualification. Let me know if you would prefer the
other approach.
*
On 10/25/18 1:16 PM, Jonathan Wakely wrote:
On 24/10/18 21:30 +0200, François Dumont wrote:
Some tests dg-prune-output regex need to be adapted to pass when
versioned namespace is activated.
I preferred to add the version namespace in the regex rather than
removing namespace qualification
Hi
Some feedback regarding this patch ?
Thanks,
François
On 8/21/18 10:34 PM, François Dumont wrote:
I missed a test that was failing because of this patch. So I revert a
small part of it and here is the new proposal.
Tested under Linux x86_64, ok to commit ?
François
On 24/07/2018
Following Marc Glisse change to ignore _M_start offset I wanted to go a
little step further and just remove it in _GLIBCXX_INLINE_VERSION mode.
I also fix a regression we already fixed on mainstream std::vector
regarding noexcept qualification of move constructor with allocator.
And I
amp;)): Adapt.
(vector::_M_initialize(size_type)): Adapt.
* testsuite/23_containers/vector/bool/cons/noexcept_move_construct.cc:
Add check.
Tested under Linux x86_64 w/o versioned namespace, w/o C++98 mode.
Ok to commit ?
François
On 10/30/18 10:59 PM, Jonathan Wakely wrote:
On 30/10/
Running tests in C++98 mode show that I had forgotten a 'return *this;'
in _Bvector_impl_data::operator=.
So here is the patch again.
On 10/30/18 7:28 AM, François Dumont wrote:
Following Marc Glisse change to ignore _M_start offset I wanted to go
a little step further and just remove
Running some tests in C++98 show that the error checked by following
tests are those of the C++11 mode.
This patch add target c++11 so that those tests are ignored in previous
mode.
* testsuite/23_containers/deque/requirements/dr438/assign_neg.cc:
Add target c++11.
*
While working on a hashtable enhancement I noticed that we are not using
the correct method to deallocate node if the constructor throws in
_ReuseOrAllocNode operator(). I had to introduce a new
_M_deallocate_node_ptr for that as node value shall not be destroy again.
I also check other
Oops, it was not the tested patch. Here it is.
On 11/12/18 7:43 AM, François Dumont wrote:
When doing some debugging session I noticed that the
__gnu_cxx::throw_allocator doubles all lookup on both insert and erase.
Using map::insert result and erasing the found iterator avoids this
double
When doing some debugging session I noticed that the
__gnu_cxx::throw_allocator doubles all lookup on both insert and erase.
Using map::insert result and erasing the found iterator avoids this
double lookup.
* include/ext/throw_allocator.h
(annotate_base::insert(void*, size_t)): Use
Here is the patch submitted by John and now fully tested.
PR libstdc++/87872
* include/debug/safe_sequence.tcc
(_Safe_sequence<>::_M_transfer_from_if): Skip transfer to self.
Is it fine to commit it now ?
François
diff --git a/libstdc++-v3/include/debug/safe_sequence.tcc
Here is a patch similar to what has been done to other containers like
std::vector.
It optimizes the swap operation, the allocator extended move constructor
and some other methods where I just bypass intermediate calls.
I reproduced the noexcept qualification on _Deque_impl_data/_Deque_impl
On 10/09/2018 01:31 PM, Jonathan Wakely wrote:
On 09/10/18 07:25 +0200, François Dumont wrote:
As we talked one day I would like to make all iterator operators
global for consistency. So here is the patch to do so for std::list
iterators.
By "global" you mean "non-member
As we talked one day I would like to make all iterator operators global
for consistency. So here is the patch to do so for std::list iterators.
Thanks to this change the operators ==(iterator, const_iterator) and !=
are not necessary anymore, one less ==|!= operator candidate.
*
sure we use consistent comparison between
iterator/const_iterator in erase and emplace methods.
2018-10-08 François Dumont
* include/debug/list (list<>::cbegin()): Use C++11 direct
initialization.
(list<>::cend()): Likewise.
(list<>::emplace<&g
Just some code cleanup extending use of C++11 direct initialization.
* include/debug/map.h
(map<>::emplace<>(_Args&&...)): Use C++11 direct initialization.
(map<>::emplace_hint<>(const_iterator, _Args&&...)): Likewise.
(map<>::insert(value_type&&)): Likewise.
mpared to calling empty().
2018-09-28 François Dumont
* include/debug/functions.h
(__foreign_iterator_aux3(const _Safe_iterator<>&, const _InputeIter&,
const _InputIter&, __true_type)): Use empty() rather than begin() ==
end().
François
diff --git a/li
Same patch as for std::list iterators. I only additionally move doc on
those operators.
I also avoid redefining some typedef that are already defined in
_Fwd_list_base<>.
* include/bits/forward_list.h
(_Fwd_list_iterator<>::operator==): Replace member function with inline
friend.
Here is the cleanup version.
* include/bits/stl_tree.h
(_Rb_tree_iterator<>::operator==): Make inline friend.
(_Rb_tree_iterator<>::operator!=): Likewise.
(_Rb_tree_const_iterator<>::operator==): Likewise.
(_Rb_tree_const_iterator<>::operator!=): Likewise.
On 09/28/2018 02:01 PM, Jonathan Wakely wrote:
On 25/09/18 22:11 +0200, François Dumont wrote:
I guess it must have something to do with the [] but as I escaped
both I don't understand what's wrong.
You might need to escape them twice, or more ... so that TCL doesn't
try to handle them
On 09/19/2018 01:07 PM, Jonathan Wakely wrote:
On 18/09/18 22:39 +0200, François Dumont wrote:
On 09/18/2018 10:41 AM, Jonathan Wakely wrote:
On 13/09/18 07:49 +0200, François Dumont wrote:
All changes limited to hashtable_c++0x.cc file.
_Prime_rehash_policy::_M_next_bkt now really does what
?
François
On 09/19/2018 01:07 PM, Jonathan Wakely wrote:
On 18/09/18 22:39 +0200, François Dumont wrote:
On 09/18/2018 10:41 AM, Jonathan Wakely wrote:
On 13/09/18 07:49 +0200, François Dumont wrote:
All changes limited to hashtable_c++0x.cc file.
_Prime_rehash_policy::_M_next_bkt now really does
On 12/20/18 9:04 AM, Ville Voutilainen wrote:
On Thu, 20 Dec 2018 at 08:29, François Dumont wrote:
Hi
I eventually find out what was the problem with the
std::move_if_noexcept within associative containers.
The std::pair move default constructor might not move both first
Hi
Here is the integration of libbacktrace to provide the backtrace on
_GLIBCXX_DEBUG assertions.
I decided to integrate it without impacting the build scripts.
Users just need to install libbacktrace and once done _GLIBCXX_DEBUG
will look for it and start using it if supported. The
eck for noexcept qualification of Value type move
constructor and it doesn't really make sens to check for
alloc::construct when we eventually call allocValue>::construct.
I'll submit this officially once back in stage 1.
François
On 12/4/18 10:43 PM, François Dumont wrote:
On 12/4/18 3
gt;()(_Arg&&)): Likewise.
* libstdc++-v3/testsuite/util/testsuite_allocator.h
(CustomPointerAlloc<>::allocate(size_t, pointer)): Replace by...
(CustomPointerAlloc<>::allocate(size_t, const_void_pointer)): ...this.
François
On 11/29/18 7:08 AM, François Dumont wrote:
I am unclea
401 - 500 of 1024 matches
Mail list logo
