On Wed, 22 Feb 2023 at 06:06, François Dumont via Libstdc++
wrote:
>
> Here is eventually a working proposal.
>
> Compared to the unordered container approach we need to find out what
> type is going to be used to call the comparer. Otherwise we might
> reinstantiate a temporary each time we call
On Thu, 2 Mar 2023 at 05:40, François Dumont via Libstdc++
wrote:
>
> Just forget about this patch, bad idea.
>
> The key_type might have additional data not used for the comparison.
> This data would not be preserved if we were inserting the already stored
> equivalent key instead of the user pro
Just forget about this patch, bad idea.
The key_type might have additional data not used for the comparison.
This data would not be preserved if we were inserting the already stored
equivalent key instead of the user provided.
On 22/02/23 07:08, François Dumont wrote:
This one is a refineme
This one is a refinement for multimap/multiset.
It allows to have share the same key if managed with ref counting like
the cow string.
libstdc++: [_Rb_tree] Limit allocations on equal insertions [PR 96088]
When inserting the same key several times prefer to insert the new
entry using
Here is eventually a working proposal.
Compared to the unordered container approach we need to find out what
type is going to be used to call the comparer. Otherwise we might
reinstantiate a temporary each time we call the comparer. For example in
case of const char* insertion with a less comp
This is PR 96088 but this time for _Rb_tree based containers.
I guess it won't go in for the moment but I wanted to submit it already
because of the changes I had to do in stl_functions.h. It sounds like
missing parts for C++11 move-semantic. I still need to run all tests to
see if they can ha
