Using C++17

[jakirkham]

It looks like we are currently requiring C++14 on macOS; whereas, we use C++17 on Linux. Would it be possible to start using C++17 on macOS as well?

[chrisburr]

I thought we were doing this already 😄

@conda-forge/clang-compiler-activation Are there any objections to changing macOS to use C++17 by default or should I prepare the PR?

[jakirkham]

I'd take silence here as no objections Chris. Do you want to submit a PR? 🙂

[isuruf]

This needs to be co-ordinated with a boost update as changing the C++ standard changes boost ABI.

[jakirkham]

So we would piggy back on a Boost update and subsequent pinning migrator? That makes sense. Shouldn't be too difficult then. Are there any other issues you foresee?

[jakirkham]

Looking at past Boost version history, it seems like a new release is probably due around April.

[isuruf]

I don't think we should update the C++ version and remove the -std=c++14 flag altogether from CXXFLAGS env variable.

[jakirkham]

Went ahead and put this on the agenda for tomorrow so we can figure out how we want to handle this

[xhochy]

@jakirkham @isuruf What was the outcome of the core meeting on this?

[chrisburr]

We suspect the boost ABI doesn't change between C++ versions (except pre/post C++11) but someone needs to build boost with both versions and diff the available symbols in the shared libraries to check.

[jakirkham]

If that's true, we are planning to drop -std=c++14 from CXXFLAGS as Isuru noted above

[xhochy]

It actually does change!

I've built boost-cpp once with -std=c++14 and once with -std=c++17 and it revealed the following ABI differences:

Script:

from pathlib import Path
from subprocess import check_output

for lib_14 in list(Path("cxx14/lib").glob("*.dylib")):
    lib_17 = Path("cxx17") / "lib" / lib_14.name
    exports_14 = {line.split(b" ")[2] for line in check_output(f"nm {lib_14}", shell=True).split(b"\n") if b" " in line}
    exports_17 = {line.split(b" ")[2] for line in check_output(f"nm {lib_17}", shell=True).split(b"\n") if b" " in line}
    if exports_14 != exports_17:
        print(lib_14.name)
        print("-" * len(lib_14.name))
        print(exports_14 - exports_17)
        print(exports_17 - exports_14)
        print()

Output:

libboost_locale.dylib
---------------------
{b'__ZN5boost6locale4util23create_simple_converterERKNSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEE', b'__ZN5boost6locale4util21create_utf8_converterEv', b'__ZN5boost6locale28localization_backend_manager11add_backendERKNSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEENS2_8auto_ptrINS0_20localization_backendEEE', b'__ZN5boost6locale4util14create_codecvtERKNSt3__16localeENS2_8auto_ptrINS1_14base_converterEEEj', b'__ZNK5boost6locale28localization_backend_manager3getEv'}
set()

libboost_context.dylib
----------------------
{b'__ZNSt3__117__call_once_proxyINS_5tupleIJRFvP6rlimitEOS3_EEEEEvPv', b'__ZNSt3__117__call_once_proxyINS_5tupleIJRFvPmEOS2_EEEEEvPv'}
{b'__ZNSt3__117__call_once_proxyINS_5tupleIJRDoFvP6rlimitEOS3_EEEEEvPv', b'__ZNSt3__117__call_once_proxyINS_5tupleIJRDoFvPmEOS2_EEEEEvPv'}

[jakirkham]

That's unfortunate. Probably no way to know this, but are those symbols actually used externally or are they just used by Boost?

[xhochy]

This stalled for quite some while but we increasingly see packages that require e.g. a C++17 enabled build of abseil-cpp. If someone can list todos, then I would look a bit into doing this; I'm currently out of ideas and would default to just remove std=c++14 from the flags and then see what breaks.