STD extensions incompatible with libc++

Because a lot of code depends on libstdc++ internals.

#ifdef __GLIBCXX__ // libstdc++
#elif _LIBCPP_VERSION // libc++
#else
 static_assert(false, ...);
#endif

mentioned in commit fd4ad050

fd4ad050 (comment 107074) Do we want to use libc++ as a default stdlib with clang builds?

Of course we can. Do we want to? (My original aim was only to enable using it and not to force using it.)

I have heard somewhere that IO is many times slower (I think it was in the lecture on the compile-time regular-expressions). I'd really like to see something like this benchmark but with libc++ 9 or 10.

Once I'm done, we will see very rough numbers based on the integration tests. After that, I would like to at least use stdc++ with clang builds just to be sure we are compatible.

Once I'm done, we will see very rough numbers based on the integration tests.

I'm afraid it wont show much difference in our setup.

After that, I would like to at least use stdc++ with clang builds just to be sure we are compatible.

Yes, the clang job will use sanitizers and libc++, that was the plan. Sorry, forgot to mention it.

regarding the map::merge we talked about today: https://stackoverflow.com/questions/57358807/clang-7-does-not-have-stdmapmerge

So with the libc++-10, some issues were resolved, however, alib2gui fails to link with libjsoncpp (it is built with libstdc++ and they have incompatible ABI). Another issue is with a fixed ordering of regexp nodes (a+\eps) vs (\eps+a) in some regexp tests. Last, integration tests somehow fail with timeouts as well. Have to investigate further.

added D-build P-high T-bug external/upstream labels

mentioned in issue #201 (closed)

xlink to 39a65bd3 discussion