On 13/06/17 22:36 +0200, François Dumont wrote:
On 01/06/2017 15:34, Jonathan Wakely wrote:
I would expect the constructor to look like this:
_Bvector_impl()
_GLIBCXX_NOEXCEPT_IF( noexcept(_Bit_alloc_type()) )
: _Bit_alloc_type()
{ }
What happens when you do that?
On 01/06/2017 15:34, Jonathan Wakely wrote:
I would expect the constructor to look like this:
_Bvector_impl()
_GLIBCXX_NOEXCEPT_IF( noexcept(_Bit_alloc_type()) )
: _Bit_alloc_type()
{ }
What happens when you do that?
_Bvector_impl(const _Bit_alloc_type& _
On 01/06/17 22:49 +0200, François Dumont wrote:
On 01/06/2017 15:34, Jonathan Wakely wrote:
On 31/05/17 22:28 +0200, François Dumont wrote:
Unless I made a mistake it revealed that restoring explicit call
to _Bit_alloc_type() in default constructor was not enough. G++
doesn't transform it into
On 01/06/2017 15:34, Jonathan Wakely wrote:
On 31/05/17 22:28 +0200, François Dumont wrote:
Unless I made a mistake it revealed that restoring explicit call to
_Bit_alloc_type() in default constructor was not enough. G++ doesn't
transform it into a value-init if needed. I don't know if it is a
On 31/05/17 22:28 +0200, François Dumont wrote:
Unless I made a mistake it revealed that restoring explicit call to
_Bit_alloc_type() in default constructor was not enough. G++ doesn't
transform it into a value-init if needed. I don't know if it is a
compiler bug but I had to do just like prese
On 31/05/2017 12:34, Jonathan Wakely wrote:
Well in general the is_nothrow_default_constructible trait also tells
you if the type is default-constructible at all, but the form above
won't compile if it isn't default-constructible. In this specific case
it doesn't matter, because that constructor
On 28/05/17 22:13 +0200, François Dumont wrote:
Sure but like freedom which stop where start others' freedom so does
those requirements :-). Because the Standard says that an allocator
will be value-init when there is no default-init it makes usage of the
C++11 default constructor more complica
On 29/05/17 22:55 +0200, François Dumont wrote:
Hi
It wasn't such a big deal to restore value-init of the allocator.
So here is the updated patch.
I used:
_Bvector_impl() _GLIBCXX_NOEXCEPT_IF( noexcept(_Bit_alloc_type()) )
rather than using is_nothrow_default_constructible. Any
Hi
It wasn't such a big deal to restore value-init of the allocator.
So here is the updated patch.
I used:
_Bvector_impl() _GLIBCXX_NOEXCEPT_IF( noexcept(_Bit_alloc_type()) )
rather than using is_nothrow_default_constructible. Any advantage
in one approach or the other ?
On 27/05/2017 13:14, Jonathan Wakely wrote:
On 26/05/17 23:13 +0200, François Dumont wrote:
On 25/05/2017 18:28, Jonathan Wakely wrote:
On 15/05/17 19:57 +0200, François Dumont wrote:
Hi
Following what I have started on RbTree here is a patch to
default implementation of default and move c
On 26/05/17 23:13 +0200, François Dumont wrote:
On 25/05/2017 18:28, Jonathan Wakely wrote:
On 15/05/17 19:57 +0200, François Dumont wrote:
Hi
Following what I have started on RbTree here is a patch to
default implementation of default and move constructors on
std::vector.
As in _Rb_tr
On 25/05/2017 18:28, Jonathan Wakely wrote:
On 15/05/17 19:57 +0200, François Dumont wrote:
Hi
Following what I have started on RbTree here is a patch to default
implementation of default and move constructors on std::vector.
As in _Rb_tree_impl the default allocator is not value initi
On 15/05/17 19:57 +0200, François Dumont wrote:
Hi
Following what I have started on RbTree here is a patch to default
implementation of default and move constructors on std::vector.
As in _Rb_tree_impl the default allocator is not value initialized
anymore. We could add a small helper
Gentle reminder, ok to commit ?
François
On 19/05/2017 21:39, François Dumont wrote:
Hi
On 15/05/2017 21:31, Marc Glisse wrote:
The __fill_bvector part of the fill overload for vector could
do with some improvements as well. Looping is unnecessary, one just
needs to produce the right mask an
Hi
On 15/05/2017 21:31, Marc Glisse wrote:
The __fill_bvector part of the fill overload for vector could do
with some improvements as well. Looping is unnecessary, one just needs
to produce the right mask and and or or with it, that shouldn't take
more than 4 instructions or so.
I have impl
On Tue, 16 May 2017, François Dumont wrote:
What is match.pd ?
It is a file in gcc where we describe simple pattern-matching
optimizations. In this case, IIRC, the missing transformations were
* ptr + n == ptr + 1 --> n == 1 (we already do it if 1 is replaced by a
variable or 0)
* ((n/8)+1)
On 15/05/2017 21:31, Marc Glisse wrote:
On Mon, 15 May 2017, François Dumont wrote:
I also added some optimizations. Especially replacement of
std::fill with calls to __builtin_memset. Has anyone ever proposed to
optimize std::fill in such a way ? It would require a test on the
value used
On Mon, 15 May 2017, François Dumont wrote:
I also added some optimizations. Especially replacement of std::fill with
calls to __builtin_memset. Has anyone ever proposed to optimize std::fill in
such a way ? It would require a test on the value used to fill the range but
it might worth this
Hi
Following what I have started on RbTree here is a patch to default
implementation of default and move constructors on std::vector.
As in _Rb_tree_impl the default allocator is not value initialized
anymore. We could add a small helper type arround the allocator to do
this value in
19 matches
Mail list logo
