6 ms·

What we need is a compiler flag that says, "give me the good parts of C++11/14, but leave out the bad stuff from C++98, and fix some of the inconsistency quirks

by xscott 7y ago

What we need is a compiler flag that says, "give me the good parts of C++11/14, but leave out the bad stuff from C++98, and fix some of the inconsistency quirks from trying to be compatible with C89".

harikb 7y ago
This works so long as entire build is your own code. Once you get to libraries written by someone else who happens to have a different “wish list”, I would guess this flags idea wouldn’t work well.
- falcor84 7y ago
  Could you please explain more about the process you're using? Are you compiling external dependencies as an integral part of building your own code?
  - derefr 7y ago
    They’re using some header-only libraries, presumably. Which, after all, is one of the only unique benefits of C++ that would lead you to choose it for a green-field project over, say, Rust. Header-only template libs + link-time WPO = inlining of template-instantiated monomorphized methods to their type-strict callers. This is the feature that leads e.g. LLVM to be written in C++.
    - steveklabnik 7y ago
      Rust doesn’t have headers, but can still do this.
  - CreRecombinase 7y ago
    Anything in your headers is (more or less equivalent to being) copy-pasted into your own code. Many dependencies are header-only (which is the only option I'm aware of if the code is templated).
  - petters 7y ago
    This is the only sane way of using C++. All C++ dependencies in the same repo, because there is no standard C++ ABI. I am compiling my C++ codebase with gcc, clang, emscripten to wasm, visual studio. Impossible if all dependencies are not present in a "third-party" folder. Google's Abseil library is intended to be used this way. Otherwise, use the C ABI between dependencies.
    - gpderetta 7y ago
      > standard C++ ABI. All major OS have a standard, very stable C++ ABI. Some of them also guarantee a stable ABI for the library components. Of course you cannot use a library built for, say, Windows on Linux but that's true for all languages.
      - jdsully 7y ago
        For windows that is a very recent change. The ABI used to change with every compiler rev. Further without buyin from the actual standard there’s no gurantee a breaking change won’t be forced by the standard at some point.
        pjmlp 7y ago
        Not for libraries exposed as DLL or COM. Although one might argue that is only a C++ subset.
        jdsully 7y ago
        COM is based off of the C ABI not C++. This was done specifically because C++ does not have a stable ABI.
        pjmlp 7y ago
        There is no such thing as C ABI, rather Windows ABI, which you can even select several calling conventions, including Pascal based one. COM is based on the way Visual C++ lays out the VMT, and only masochists use it from bare bones C.
- 0xffff2 7y ago
  It's just another standard option. Do libraries that are compiled with std=c++14 work with application code compiled with std=c++11? What about the other direction? (I don't actually know because I do build everything from source.) You would basically just be adding a new `std=good` option.
  - asveikau 7y ago
    I have seen with clang++ that if I mix and match .o files built with -std=c++11 and -std=c++17 [something I have occasionally done by accident] and they reference the same classes, sometimes they fail to link, not due to standard library types differing but ones I defined myself that can compile with either standard.
  - CJefferson 7y ago
    The problem with c++ is many libraries are mostly header files, and they are combined with your code basically by cut+paste, so you can't rewlly seperwte libraries from your own code usefully.
0xffff2 7y ago
Even given the inevitability of disagreements about which are the "good parts", I'm pretty sure this would be my "standard version" of choice if it was available.
- zozbot234 7y ago
  The "C++ Core" guidelines get pretty close to standardizing the 'good parts' of C++.
  - 0xffff2 7y ago
    I'm aware of the guidelines and apply them, but that's only a small fraction of the problem. What I need is a compiler flag that enforces the guidelines so that I can write it into my software management docs in place of "-std=c++11".
karlicoss 7y ago
I think core guidelines [0] are aiming that. Some of it is already supported by tools like clang-tidy, but as far as I understand the ultimate goal is to have some sort of flag (e.g. --sane) that would only accept 'reasonable' subset of c++ and reject legacy stuff. However this document is a bit raw, lots of todos, so I'm not sure how close are we to such flag. [0] https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
- mlvljr 7y ago
  There is something even better: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p188... cheers from the shadowland :)
- ATsch 7y ago
  I think the only good way to do this is off of the back of C++ Modules. Having it as a compiler flag means that all files in a project, including libraries, must be compliant. With C++ modules putting an end to the naive #include, translation units could specify the C++ specification they are compliant with, and hence gracefully remove or add new features on a translation-unit level.
  - steveklabnik 7y ago
    This is the idea for the 'epochs' proposal https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs.html https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs...
deleted 7y ago
[deleted]

by xscott 7y ago

harikb 7y ago

This works so long as entire build is your own code. Once you get to libraries written by someone else who happens to have a different “wish list”, I would guess this flags idea wouldn’t work well.

falcor84 7y ago
Could you please explain more about the process you're using? Are you compiling external dependencies as an integral part of building your own code?
- derefr 7y ago
  They’re using some header-only libraries, presumably. Which, after all, is one of the only unique benefits of C++ that would lead you to choose it for a green-field project over, say, Rust. Header-only template libs + link-time WPO = inlining of template-instantiated monomorphized methods to their type-strict callers. This is the feature that leads e.g. LLVM to be written in C++.
  - steveklabnik 7y ago
    Rust doesn’t have headers, but can still do this.
- CreRecombinase 7y ago
  Anything in your headers is (more or less equivalent to being) copy-pasted into your own code. Many dependencies are header-only (which is the only option I'm aware of if the code is templated).
- petters 7y ago
  This is the only sane way of using C++. All C++ dependencies in the same repo, because there is no standard C++ ABI. I am compiling my C++ codebase with gcc, clang, emscripten to wasm, visual studio. Impossible if all dependencies are not present in a "third-party" folder. Google's Abseil library is intended to be used this way. Otherwise, use the C ABI between dependencies.
  - gpderetta 7y ago
    > standard C++ ABI. All major OS have a standard, very stable C++ ABI. Some of them also guarantee a stable ABI for the library components. Of course you cannot use a library built for, say, Windows on Linux but that's true for all languages.
    - jdsully 7y ago
      For windows that is a very recent change. The ABI used to change with every compiler rev. Further without buyin from the actual standard there’s no gurantee a breaking change won’t be forced by the standard at some point.
      - pjmlp 7y ago
        Not for libraries exposed as DLL or COM. Although one might argue that is only a C++ subset.
        jdsully 7y ago
        COM is based off of the C ABI not C++. This was done specifically because C++ does not have a stable ABI.
        pjmlp 7y ago
        There is no such thing as C ABI, rather Windows ABI, which you can even select several calling conventions, including Pascal based one. COM is based on the way Visual C++ lays out the VMT, and only masochists use it from bare bones C.
0xffff2 7y ago
It's just another standard option. Do libraries that are compiled with std=c++14 work with application code compiled with std=c++11? What about the other direction? (I don't actually know because I do build everything from source.) You would basically just be adding a new `std=good` option.
- asveikau 7y ago
  I have seen with clang++ that if I mix and match .o files built with -std=c++11 and -std=c++17 [something I have occasionally done by accident] and they reference the same classes, sometimes they fail to link, not due to standard library types differing but ones I defined myself that can compile with either standard.
- CJefferson 7y ago
  The problem with c++ is many libraries are mostly header files, and they are combined with your code basically by cut+paste, so you can't rewlly seperwte libraries from your own code usefully.

0xffff2 7y ago

Even given the inevitability of disagreements about which are the "good parts", I'm pretty sure this would be my "standard version" of choice if it was available.

zozbot234 7y ago
The "C++ Core" guidelines get pretty close to standardizing the 'good parts' of C++.
- 0xffff2 7y ago
  I'm aware of the guidelines and apply them, but that's only a small fraction of the problem. What I need is a compiler flag that enforces the guidelines so that I can write it into my software management docs in place of "-std=c++11".

karlicoss 7y ago

I think core guidelines [0] are aiming that. Some of it is already supported by tools like clang-tidy, but as far as I understand the ultimate goal is to have some sort of flag (e.g. --sane) that would only accept 'reasonable' subset of c++ and reject legacy stuff. However this document is a bit raw, lots of todos, so I'm not sure how close are we to such flag. [0] https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

mlvljr 7y ago
There is something even better: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p188... cheers from the shadowland :)
ATsch 7y ago
I think the only good way to do this is off of the back of C++ Modules. Having it as a compiler flag means that all files in a project, including libraries, must be compliant. With C++ modules putting an end to the naive #include, translation units could specify the C++ specification they are compliant with, and hence gracefully remove or add new features on a translation-unit level.
- steveklabnik 7y ago
  This is the idea for the 'epochs' proposal https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs.html https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs...

deleted 7y ago

[deleted]