[pjmlp]

Before C++17, boost::filesystem, now std::filesystem.

In Android's case, the ABI would be whatever g++, now clang, shipped with NDK support.

Additionally there are ways to implement compatible ABIs in C++.

In any case, they are wrapping the C++ classes already, either via C or Java, so they could offer them as well.

Instead, one needs to write unsafe C code, JNI boilerplate or wrap them again in C++.

[humanrebar]

The need to standardize things like std::filesystem was my point.

> Additionally there are ways to implement compatible ABIs in C++.

Eh... when even compilation flags affect ABIs, it's hard for a particlar C++ file to have a stable ABI. The same is true in C, of course, but the way C libraries are generally designed, it's simpler to be ABI compatible. In C++, arcane and unexpected things like noexcept specifications (affected by changes in underlying libraries!) can change your ABI.

> Instead, one needs to write unsafe C code, JNI boilerplate or wrap them again in C++.

That's a fair point. There might be reasons they'd do that (SLAs they can afford), but that's a presumption.

[pjmlp]

> The need to standardize things like std::filesystem was my point.

Which circles back to my statement about "The C mentality of some devs dragged into C++ world.".

Many useful C++ libraries were not standardized in the early days beyond STL, because many thought C++ should be like C where libraries are whatever the OS provides and nothing else.

Which is clearly visible in the decision to have ANSI C and POSIX APIs as two separate standards, although most C compilers try to provide some kind of additional POSIX compatibility, specially visible in non-POSIX OSes.

Thankfully, the ANSI C++ committee realized the mistake and now we are getting a useful set of libraries into the standard.

As for compilation flags, even for C it is only true if all compilers on the platform follow the same ABI.

And you still need to provide all variants anyway (debug, single and multithreaded, hard and soft float, pre-defined pre-processor macros, ...).

C ABI only appears to be simple in OSes that happen to be written in C.

Grated that is the case nowadays with most being UNIX clones, besides Windows and mainframes, but it wasn't always like that.

I remember the pain of trying to mix multiple C compilers back in the 90's.

[humanrebar]

All good points.

> C ABI only appears to be simple in OSes that happen to be written in C.

I'd say that C is the only language that (mostly accidentally and non-standard, for the reasons you state) provides a simple a (relatively) stable ABI.

[pjmlp]

As update to my rant, I have to be faire to the Android team.

Apparently something related to C++ APIs on the NDK is planned to start appearing with NDR r17 onwards, as per Github issues.