9 ms·

Just skimming section 4, this really just looks like even more syntax being added to the language without enough benefit to justify the additional complexity. A

Just skimming section 4, this really just looks like even more syntax being added to the language without enough benefit to justify the additional complexity. At this point, I think I've made the decision to just stick with C++11 indefinitely and backport the rare useful feature. I don't want to have to memorize all of this extra stuff.

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]
Sharlin 7y ago
Interesting. To me there’s very little totally new syntax, and the benefits are considerable. It’s basically just being able to match on the existing structured binding patterns, as well as on type tags when the expression is polymorphic.
- stinos 7y ago
  the benefits are considerable Exactly. Admittedly with enough modern C++ experience and having used pattern matching I find the syntax pretty readable and clear. But even if it weren't I'd probably still be +1 pattern matching.
voldacar 7y ago
If they added proper metaprogramming, people could make their own pattern matching and other compile time goodies and they wouldnt have to keep shoving cruft down our throats every 3 years.
SamReidHughes 7y ago
The consequences of using an inspect statement are local to the statement. So the syntax is a thing to learn, but probably not a harbinger of language complexity. It's a leaf node.
userbinator 7y ago
From my observations of working as a developer for a long time, it seems the majority of developers can be classified in two groups. One group will really advocate for adding lots of features to a language. They are also the ones who don't mind or even seek out constant change for the sake of change. They like the new and shiny, and don't care that much about anything else. They want to rewrite code even if it is perfectly working and the problem it solves does not change, just to make it more "modern". They don't think anything of burdening everyone else with the additional complexity added by their demands, as long as it makes their specific use-case easier. Their attitude can be summed up as "it's not my problem". On the other hand, the other group values stability and not feature proliferation. They don't want to have a constantly changing foundation, but something stable they can build on. They want a small language which they can more easily master and then use to solve problems with. They think code should not ever need to change again as long as the problem it solves is the same. Their attitude can be summed up as "do what you can with what you have." The C++ and a lot of newer programming languages (especially web stuff) seem to mainly be composed of people from the former group, which is much larger than the latter, but I think we really need more of the latter group in a lot of the tech industry. My go-to language is still C89 and I don't need anything more, because it gets the job done and it's simple enough to be very portable.
- Supermancho 7y ago
  > They don't want to have a constantly changing foundation, but something stable they can build on For how many generations?
- master-litty 7y ago
  I like to consider programming as an art form with many schools of thought. As with art in other mediums, developers enjoy creating and interacting with their art in different ways. Conflict builds when developers exist in the same ecosystem with different opinions on what this art means to them. It feels like everyone is accomplishing different goals because we really are. Some people want to continually iterate their code until it matches a perfect vision in their head; It's less (if even at all) about the functionality and more about how we got there. That obviously frustrates people who care about the functionality far more.

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]

Sharlin 7y ago

Interesting. To me there’s very little totally new syntax, and the benefits are considerable. It’s basically just being able to match on the existing structured binding patterns, as well as on type tags when the expression is polymorphic.

stinos 7y ago
the benefits are considerable Exactly. Admittedly with enough modern C++ experience and having used pattern matching I find the syntax pretty readable and clear. But even if it weren't I'd probably still be +1 pattern matching.

voldacar 7y ago

If they added proper metaprogramming, people could make their own pattern matching and other compile time goodies and they wouldnt have to keep shoving cruft down our throats every 3 years.

SamReidHughes 7y ago

The consequences of using an inspect statement are local to the statement. So the syntax is a thing to learn, but probably not a harbinger of language complexity. It's a leaf node.

userbinator 7y ago

From my observations of working as a developer for a long time, it seems the majority of developers can be classified in two groups. One group will really advocate for adding lots of features to a language. They are also the ones who don't mind or even seek out constant change for the sake of change. They like the new and shiny, and don't care that much about anything else. They want to rewrite code even if it is perfectly working and the problem it solves does not change, just to make it more "modern". They don't think anything of burdening everyone else with the additional complexity added by their demands, as long as it makes their specific use-case easier. Their attitude can be summed up as "it's not my problem". On the other hand, the other group values stability and not feature proliferation. They don't want to have a constantly changing foundation, but something stable they can build on. They want a small language which they can more easily master and then use to solve problems with. They think code should not ever need to change again as long as the problem it solves is the same. Their attitude can be summed up as "do what you can with what you have." The C++ and a lot of newer programming languages (especially web stuff) seem to mainly be composed of people from the former group, which is much larger than the latter, but I think we really need more of the latter group in a lot of the tech industry. My go-to language is still C89 and I don't need anything more, because it gets the job done and it's simple enough to be very portable.

Supermancho 7y ago
> They don't want to have a constantly changing foundation, but something stable they can build on For how many generations?
master-litty 7y ago
I like to consider programming as an art form with many schools of thought. As with art in other mediums, developers enjoy creating and interacting with their art in different ways. Conflict builds when developers exist in the same ecosystem with different opinions on what this art means to them. It feels like everyone is accomplishing different goals because we really are. Some people want to continually iterate their code until it matches a perfect vision in their head; It's less (if even at all) about the functionality and more about how we got there. That obviously frustrates people who care about the functionality far more.