[blelbach]

> apparently only a small bit of the library is actually implemented.

Yep. It's an incremental project. But stay tuned.

> I'm somewhat suspicious of the presumption of us using NVIDIA's version of the standard library for our host-side work.

Today, when using libcu++ with NVCC, it's opt-in and doesn't interfere with your host standard library.

I get your concern, but a lot of the restrictions of today's GPU toolchains comes from the desire to continue using your host toolchain of choice.

Our other compiler, NVC++, is a unified stack; there is no host compiler. Yes, that takes away some user control, but it lets us build things we couldn't build otherwise. The same logic applies for the standard library.

https://developer.nvidia.com/blog/accelerating-standard-c-wi...

> Finally, I'm not sure that, for device-side work, libc++ is a better base to start off of than, say, EASTL (which I used for my tuple class: https://github.com/eyalroz/cuda-kat/blob/master/src/kat/tupl... ).

We wanted an implementation that intended to conform to the standard and had deployment experience with a major C++ implementation. EASTL doesn't have that, so it never entered our consideration; perhaps we should have looked at it, though.

At the time we started this project, Microsoft's Standard Library wasn't open source. Our choices were libstdc++ or libc++. We immediately ruled libstdc++ out; GPL licensing wouldn't work for us, especially as we knew this project had to exchange code with some of our other existing libraries that are under Apache- or MIT-style licenses (Thrust, CUB, RAPIDS).

So, our options were pretty clear; build it from scratch, or use libc++. I have a strict policy of strategic laziness, so we went with libc++.

[justicezyx]

How this library works?

There appears a llvm libcxx bundled in as part of the repo. What's the purpose of that libcxx?

[blelbach]

That involves a few diagrams, but essentially, we have two layers:

- the libcu++ layer, which has some of our extensions and implementations specific to our platform. - the libc++ layer, which is a modified upstream libc++.

A header in the libcu++ layer defines the libc++ internal macros in a certain way, and then includes the applicable libc++ header.

This is the current architecture, but we're moving away towards a more integrated approach where almost everything is in the libc++ layer.