Mention C++17 (and maybe C++20)?

[PallHaraldsson]

I saw in the README: "C++11 lambda and conversion for arrays" and "a functor (generic C++14 lambda here)", implicitly suggesting [full?] support for at least up to C++14

that made me think. All C++ standards up to C++17 and beyond should be supported, right? I believe it just depends on the C++ compiler supporting, not this package.

If I'm not mistaken, maybe it's best to add text explicitly saying that in the README. If course you can't guarantee compatibility with any future version (who knows what will be added, some different name mangling etc.).

Do you know of anything, in say C++17 (or coming in C++20) or in prior versions NOT supported?

--

I see Cxx.jl also added Julia 1.0 support "5 days ago". That's also awesome. There no specific C++ version is mentioned in any way, so implicit that all are supported. Feel free to mention if you know otherwise, or any differences in C++ support between these packages.

[barche]

Wrappers built with CxxWrap need to be compiled at least with -std=c++14, higher should be fine too.

[PallHaraldsson]

I guess you're right, while I don't see what ties you to at least c++14. I only see "compiler_abi=CompilerABI(:gcc7,:cxx11))" in the code, and realize the ABI is a different restriction (while I think it only requires C++11).

Then I'm not sure you support e.g. full C++20 (or even C++17), as it seems to require GCC 8.

Is it maybe time to change to -fabi-version=13 (GCC 8.2), or even just 12, or keep 11 but still use GCC 8?

https://gcc.gnu.org/gcc-8/changes.html

C++

• GCC 8 (-fabi-version=12) has a couple of corrections to the calling convention, which changes the ABI for some uncommon code:
  ** Passing an empty class as an argument now takes up no space on x86_64, as required by the psABI.
  **Passing or returning a class with only deleted copy and move constructors now uses the same calling convention as a class with a non-trivial copy or move constructor. This only affects C++17 mode, as in earlier standards passing or returning such a class was impossible.
  **WARNING: In GCC 8.1 the second change mistakenly also affects classes with a deleted copy constructor and defaulted trivial move constructor (bug c++/86094). This issue is fixed in GCC 8.2 (-fabi-version=13).
  You can test whether these changes affect your code with -Wabi=11 (or -Wabi=12 in GCC 8.2 for the third issue); if these changes are problematic for your project, the GCC 7 ABI can be selected with -fabi-version=11.

E.g. a line I found in the code that would need to change then:

Windows(:i686, compiler_abi=CompilerABI(:gcc7,:cxx11)) => ("$bin_prefix/libcxxwrap-julia-1.0.v0.5.0.i686-w64-mingw32-gcc7.tar.gz", "5f4fe214985ef1614c97a3135c9ba8319e46678c5f2895e6ae6be81acf047112"),

Is it ok if I ask you some other questions in this thread on C++ support (e.g. with the optional GC)? Should I then open separate issues, even if will not be implemented soon.

Below is off-topic:

I do see (for GCC 9 it seems): "The D programming language front end has been added to GCC. This front end was contributed by Iain Buclaw."

That language (or Go, Objective-C or Ada) would be interesting to support, but I guess outside of the scope of this (or Cxx.jl) project.

Possibly D (and maybe even the other GC-using languages; and maybe C++ with the optional GC) could reuse Julia's GC (or Go's):

Go

• GCC 8 provides a complete implementation of the Go 1.10.1 user packages.
• The garbage collector is now fully concurrent. As before, values stored on the stack are scanned conservatively, but value stored in the heap are scanned precisely.

C++ keeps expanding, with byte type as of C++17 and now this other 8-bit char8_t type as of C++20:
www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0482r6.html

C++11 introduced support for UTF-8, UTF-16, and UTF-32 encoded string literals via N2249 [N2249]. New char16_t and char32_t types were added to hold values of code units for the UTF-16 and UTF-32 variants, but a new type was not added for the UTF-8 variants.