[libcxx-dev] An extension of libcxx

Ben Craig via libcxx-dev libcxx-dev at lists.llvm.org
Wed Dec 12 07:08:09 PST 2018


Trying again with a shorter message, as I think the list filtered out the last one…

“Other things that we SHOULD be able to have, but that would require refactoring in libc++ (and most of them are not part of the current freestanding):”

    <array>
    <string_view>
These are annoying, because they throw exceptions from <stdexcept>, and <stdexcept> exceptions have constructors which take a std::string.  You could omit the throwing methods (as I have done in P0829), or you could patch over it by making those calls terminate instead.

    <pair>
I think you mean <utility>.  You should be able to get all or <utility>.  I’m unsure on how much internal header shuffling is required.

    most if not all of <functional>
I exclude std::function and the string searchers in P0829, as they allocate on the heap.  You may have different priorities here.

    most of <algorithm>
You probably want most of <numeric> as well.  The places I avoided were the execution policy overloads and the algorithms that allocate temporary buffers (stable_sort, stable_partition, inplace_merge).

The “quick” rundown of what is in my paper can be found by searching for “Technical Specifications” in https://wg21.link/P0829, then stopping when you get to “Notable Omissions”.  That is “merely” 3 printed pages, but a lot of it is quick to scroll through.

I suspect that NVIDIA is fine with heap allocations, and probably really wants floating point operations.  My preference is to layer that on to my proposal, but I’m not the one doing the libcxx work right now 😊

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20181212/4604c27f/attachment.html>


More information about the libcxx-dev mailing list