[PATH][_GLIBCXX_DEBUG] Fix unordered container merge

François Dumont frs.dumont@gmail.com
Mon Nov 15 18:16:41 GMT 2021


On 10/11/21 10:38 am, Jonathan Wakely wrote:
>
>
> On Wed, 10 Nov 2021 at 05:47, François Dumont <frs.dumont@gmail.com 
> <mailto:frs.dumont@gmail.com>> wrote:
>
>     On 09/11/21 5:25 pm, Jonathan Wakely wrote:
>>
>>
>>     On Mon, 8 Nov 2021 at 21:36, François Dumont
>>     <frs.dumont@gmail.com <mailto:frs.dumont@gmail.com>> wrote:
>>
>>         Yet another version this time with only 1 guard
>>         implementation. The predicate to invalidate the safe
>>         iterators has been externalized.
>>
>>         Ok to commit ?
>>
>>
>>     I like this version a lot - thanks for persisting with it.
>>
>>     OK to commit, thanks.
>>
>>
>>     As an aside ...
>>
>>     --- a/libstdc++-v3/testsuite/util/testsuite_abi.h
>>     +++ b/libstdc++-v3/testsuite/util/testsuite_abi.h
>>     @@ -24,7 +24,11 @@
>>      #include <locale>
>>      #if __cplusplus >= 201103L
>>      # include <unordered_map>
>>     +# ifdef _GLIBCXX_DEBUG
>>     +namespace unord = std::_GLIBCXX_STD_C;
>>     +# else
>>      namespace unord = std;
>>     +# endif
>>      #else
>>      # include <tr1/unordered_map>
>>      namespace unord = std::tr1;
>>
>>
>>     Several times I've been annoyed by the fact that we don't have a
>>     way to refer to std::_GLIBCXX_STD_C::vector etc. that is always
>>     valid, in normal mode and debug mode.
>>
>>     Maybe we should add:
>>
>>     namespace std { namespace _GLIBCXX_STD_C = ::std; }
>>
>>     That way we can refer to std::_GLIBCXX_STD_C::foo in normal mode,
>>     and it will mean the same thing as in debug mode. So we don't
>>     need to use #if conditions like this.
>>
>>
>     Good idea, I'll prepare it.
>
>
> Alternatively we could do this:
>
> namespace std
> {
> namespace __cxx1998 { }
> #ifdef _GLIBCXX_DEBUG
> namespace __cont = __cxx1998;
> #else
> namespace __cont = ::std::
> #endif
> }
>
> And then define this so it's always the same name:
> #define _GLIBCXX_STD_C __cont
>
> Then we can refer to std::_GLIBCXX_STD_C::vector in any context, and 
> it refers to the right thing. And we could also stop using the 
> SHOUTING macro, and just refer to std::__cont::vector instead.
>
> We could also make this work as std::__cxx1998::vector, but maybe we 
> should move away from the "1998" name, because it doesn't make much 
> sense for forward_list and unordered_map which are not in C++98.
>
Here is what I started.

I use '__normal' because when greping '__cont' in the lib it reported me 
a definition of it in boost_concept_check.h. But now that I took a 
closer look in this file I realize that it is just where you pick the 
idea of the '__cont' !

So, what do you prefer ? __cont or __normal ?

I was not considering to replace usage of _GLIBCXX_STD_C in the lib as 
long as there is no #ifdef _GLIBCXX_DEBUG. Do you prefer I do ?

François

-------------- next part --------------
A non-text attachment was scrubbed...
Name: normal_ns.patch
Type: text/x-patch
Size: 2109 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20211115/21dd237e/attachment-0001.bin>


More information about the Libstdc++ mailing list