Deeply sorry, I indeed didn't sent the patch I wanted to commit. It was
in 3 commits on my side and it looks like I had miss the last one
regarding the changes for _ExtractKey.
But moreover I had change the ebo helper index wrongly, I missed the abi
change here, thanks for fixing it.
On 26/
On 26/08/20 16:58 +0100, Jonathan Wakely wrote:
On 26/08/20 16:55 +0100, Jonathan Wakely wrote:
On 26/08/20 16:30 +0100, Jonathan Wakely wrote:
I'm seeing new FAILures with this:
FAIL: 20_util/function_objects/searchers.cc (test for excess errors)
UNRESOLVED: 20_util/function_objects/searchers
On 26/08/20 16:55 +0100, Jonathan Wakely wrote:
On 26/08/20 16:30 +0100, Jonathan Wakely wrote:
I'm seeing new FAILures with this:
FAIL: 20_util/function_objects/searchers.cc (test for excess errors)
UNRESOLVED: 20_util/function_objects/searchers.cc compilation failed to produce
executable
FAI
On 26/08/20 16:30 +0100, Jonathan Wakely wrote:
On 25/08/20 15:30 +0100, Jonathan Wakely wrote:
On 17/08/20 19:13 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the new proposal.
   As we can't remove template parameters I simply restore those
that I tried to pass differe
On 25/08/20 15:30 +0100, Jonathan Wakely wrote:
On 17/08/20 19:13 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the new proposal.
   As we can't remove template parameters I simply restore those
that I tried to pass differently _H2 and _ExtractKey, so eventually
I only r
On 17/08/20 19:13 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the new proposal.
   As we can't remove template parameters I simply restore those that
I tried to pass differently _H2 and _ExtractKey, so eventually I only
remove usage of _Hash which I renamed in _Unused.
Hi
Here is the new proposal.
As we can't remove template parameters I simply restore those that
I tried to pass differently _H2 and _ExtractKey, so eventually I only
remove usage of _Hash which I renamed in _Unused. Maybe I can keep the
doc about it in hashtable.h and just add a remar
On 06/08/20 08:35 +0200, François Dumont wrote:
On 17/07/20 1:35 pm, Jonathan Wakely wrote:
I really like the general idea of getting rid of some of the
complexity and not supporting infinite customization. But we can do
that without changing mangled names of the _Hashtable specialiations.
I
On 17/07/20 1:35 pm, Jonathan Wakely wrote:
On 19/12/19 20:22 +0100, François Dumont wrote:
Because of this change printers.py has to be updated too.
François
On 11/17/19 10:15 PM, François Dumont wrote:
H1 used to be a reference to the user Hash, now _Hashtable and
unordered types agree
On 19/12/19 20:22 +0100, François Dumont wrote:
Because of this change printers.py has to be updated too.
François
On 11/17/19 10:15 PM, François Dumont wrote:
H1 used to be a reference to the user Hash, now _Hashtable and
unordered types agree on the same Hash type which is more intuitive
On 19/11/19 00:10 +0200, Ville Voutilainen wrote:
On Mon, 18 Nov 2019 at 23:41, François Dumont wrote:
> Also, is
> this ABI-compatible
> for our unordered containers?
>
IMHO, yes it is.
In hashtable_policy.h _H1 was the user hash which I renamed in _Hash,
the same template name that for un
Because of this change printers.py has to be updated too.
François
On 11/17/19 10:15 PM, François Dumont wrote:
H1 used to be a reference to the user Hash, now _Hashtable and
unordered types agree on the same Hash type which is more intuitive.
I also chose to not support anymore a stateful r
On Mon, 18 Nov 2019 at 23:41, François Dumont wrote:
> > Also, is
> > this ABI-compatible
> > for our unordered containers?
> >
> IMHO, yes it is.
>
> In hashtable_policy.h _H1 was the user hash which I renamed in _Hash,
> the same template name that for unordered containers.
>
> _H2 was always
On 11/17/19 11:21 PM, Ville Voutilainen wrote:
On Sun, 17 Nov 2019 at 23:15, François Dumont wrote:
H1 used to be a reference to the user Hash, now _Hashtable and unordered
types agree on the same Hash type which is more intuitive.
I also chose to not support anymore a stateful ranged hash fun
On Sun, 17 Nov 2019 at 23:15, François Dumont wrote:
>
> H1 used to be a reference to the user Hash, now _Hashtable and unordered
> types agree on the same Hash type which is more intuitive.
>
> I also chose to not support anymore a stateful ranged hash functor. We
> only use _Mod_range_hashing an
H1 used to be a reference to the user Hash, now _Hashtable and unordered
types agree on the same Hash type which is more intuitive.
I also chose to not support anymore a stateful ranged hash functor. We
only use _Mod_range_hashing and _Mask_range_hashing.
Thanks to this simplification _M_buck
16 matches
Mail list logo
