> it's really quite expressive, powerful, and orthogonal

Expressive and powerful are definitely true, but I'm not so sure about 'orthogonal'.

Most C++ features seem to depend heavily on each other, and library decisions can impose restrictions/boilerplate on application code in many areas.

Especially as the language has evolved, features like exceptions, destructors, copy and move constructors, and operator overloading have become more and more indispensable. Template functions are still required for any kind of variance (e.g. you still can't have a non-template function that works on a const std::shared_ptr<const *base_type> or any derived type).

None of these is unbearable, but I do believe that even the modern subset of C++ is still the least orthogonal mainstream language in use (and definitely the most complicated by far). To be fair, it's also likely the most expressive mainstream language too, and still the most performant.

    #include <memory>
    #include <iostream>
    
    
    struct foo {
     virtual ~foo() = default;
     virtual void bark() const { std::cout << "fork\n"; }
    };
    
    
    struct bar : foo {
     void bark() const override { std::cout << "bark\n"; }
    };
    
    
    void poke_so_it_barks(std::shared_ptr<foo const> const thing) {
     thing->bark();
    }
    
    
    int main() {
     poke_so_it_barks(std::make_shared<foo>());
     poke_so_it_barks(std::make_shared<bar>());
    }

The thing that has really kept me from getting behind updates to the C++ universe is the lack of progress on improving the state of build tooling. It is miserably underengineered for modern, dependency-heavy environments. C++20 does introduce modules, which is a good push towards correcting the problem, but I'm still going to be "wait and see" on whether the actual implementation pans out.

What does orthogonal mean as an adjective for a programming language? I've never heard that word outside of math and I always get excited by a word that might expand my ability to think about code.

last time I used C++ was in the mid-2000s. With all the new features since then, I assume the "proper" way/style to right C++ has changed since then?

  > I had the luxury of starting from an empty buffer

Let's assume that I'm willing to flush the cache. Are there and C++17 learning resources that you might recommend? My day-to-day languages are Python and scripting languages.

I have seen comments that suggest you can write cross-platform applications (or at least shared business logic) in c++.

Is that the case? If so, how would you recommend someone go about learning c++?

I don't encounter these barriers in commercial settings. The biggest barrier is compiler support if you target environments with different compiler toolchains. Each new version of C++ brings features and bug fixes that make code simpler. It actually reduces complexity from the perspective of the developer. The forcing function for upgrading C++ versions in my teams is always that it would greatly simplify some immediate problem or allow us to remove a gross (but necessary) hack due to the limitations of prior versions. At least with the LLVM toolchain, upgrades have been nearly issue-free so there is little to recommend not doing it. C++17 is a big upgrade over C++11 functionally. Developers that do not see compelling improvements probably weren't using most of the functionality of C++11 anyway.

While the number of features and quirks in standard C++ grows with each version, the subset that a developer needs to remember to write correct idiomatic code is shrinking with each new version as capabilities become more general and the expression of those capabilities simpler. There is a new, simpler, and vastly more capable language evolving out of the old one and you can increasingly live almost entirely within this new language as a developer. I hated classic C++ but I actually really like this new C++, and it allows me to write far less code for the same or better result.

There are still many things that C++ can express simply and efficiently that Rust, Julia, etc cannot. If you work on software that can take advantage of that expressiveness (e.g. databases in my case), the cost of changing languages is quite large.

On the other hand, there aren't really any changes in 14 and 17 that break compatibility with code written in 11, at least that I'm aware of.

In the examples I've seen it seems to mostly come down to compiler, toolchain and 3rd party binary availability for the new versions, like with any major language version.

If for example you are using stock gcc from Ubuntu 16.04 for your builds, you can't use C++17.

ABI stability of the STL is the biggest issue I've seen. Upgrading from C++11 to C++17 becomes a bust if any of your 3rd party libraries want to pass even a basic std::string.

I don't know what the hold up is on modules. Even a basic "this header uses a C++11 namespace" functionality would fix most of the problems.

But even better would be something like "extern 'Cwrapper'" that would let you expose C++ objects as a C API with a void* object pointer without having to do the pointless wrapper dance every time.

Like make the compiler convert "class Thing { doThing(int a); }" to "typedef void* Thing; Thing_doThing(Thing* this, int a);" automatically so that other languages can call me.

Re (5), I rather feel that the quality of the documentation and communication around modern C++ puts everything else to shame. If you knew java or python in 2009, how are you supposed to quickly catch up with 2019? (Rust also seems to have piled on a lot of additions since 1.0, but I don't use it so I shouldn't speak.) There are books and blogs for everything popular, but it's really a little shocking to me that no other big language has anything that can compare to cppreference.com.

This doesn't change what people other than me might be thinking, of course.

(1) It's actually rather sensible, because C++ is famous for its backwards compatibility. So you can use C++14 or C++17 features in some new code while leaving the rest as-is - and gradually refactoring some of it with new features.

(2) This used to be the case with C++03 (or C++98), and it changed...

(3) I partially disagree and partially claim you're begging the question. You don't have poll results to suggest what people think of C++14. But - C++14 had a lot less changes compared to C++11 or C++17; this was natural considering how the cycle of debate of potential features progressed.

The thing is, the fact that C++14 wasn't that revolutionary in terms of features also means it is easier to adopt. If you want more novelty - try C++17; or - try a C++14-dependent library like Eric Niebler's ranges-v3.

(4) C++17 allows for writing less complex code in many cases. Specifically, you can significantly reduce the need for template metaprogramming - a particularly hairy part of the language - by using more constexpr functions and if-constexpr in regular functions. And there are other examples. Like Bjarne says: The C++ committee endeavors to "make simple things simple (to write)". So it's a trade-off.

(5) Some people switch languages because of workplace decisions or personal preferences, that's true; but people also adopt C++ because of what becomes possible, or easily-expressible, with newer versions of the language. For example, using the ranges library and with C++14 or later, functional programming with C++ has become quite reasonable, borderline pleasant even.

---

Bottom line: In my opinion, at this point C++11 has more inertia than momentum. And that's ok. People will progress over time.

> There's no widespread perception that C++14 or later bring compelling language improvements.

I would argue the opposite: C++11 is a fairly different paradigm to C++03, and upgrading an existing code base is a sizable project.

But once you get hooked into the concepts it introduces (auto, lambdas, templates, constexpr), each subsequent revision of the language standard introduces some improvement to these concepts that deals with unpleasant edge cases the earlier revision had, so each of them promises to make your existing use cases simpler, at a moderate rewrite expense.

C++11 vs C++14/C++17/C++20 is not python2 vs python3. Because of the emphasis on backwards compatibility, you can often just recompile your C++11 project with the new version of the standard and everything should just work. Backwards compatability also means that the newer versions are only as "complex" as the features you choose to use.

> (3) There's no widespread perception that C++14 or later bring compelling language improvements.

Constexpr if (introduced in C++17). If you're building a library that uses templated types (and therefore static dispatch instead of virtual functions and dynamic dispatch), then using constexpr if dramatically simplifies the implementation of your code.

> here's no widespread perception that C++14 or later bring compelling language improvements.

C++14 didn't add a whole lot of new things; it mostly improved on existing features.

C++17 adds a number of new things.

I would use it just for std::optional and std::variant though.

Do you think that will change with introduction of modules? Would that be a feature compeling enough to make people move to newer versions of the standard?

They will switch to 20 for modules. No. 1 headache is build times. It will literally save money.

C++14’s compelling improvement is initialization in capture lists, so you don’t have to copy into them. I haven’t seen anything compelling beyond that.

I have hope for modules because they can improve build times. Not exactly sure they would improve build time but if it's true, it would be a massive improvement.

OTOH ranges usually get compiled to faster and more efficient code. Smaller too.

Designated Initializers done awkwardly a.k.a. "the C++ way"

  // Point2D point2d {.y = 2, .x = 1};         // (1) error

Oh my. The C++ committee keeps their flight altitude rivaling moles and worms. This is another brittle feature, just like the initializer lists that have to mirror the declaration order. In what world is this a better option than allowing any order? Can't compiler implementors be bothered or what is the rationale?? C does this better.

> built-in library support for logging, http, zip, gzip, json, yaml, template rendering, RFC3339 datetime reading/writing

That's completely out of scope for a programming language pretending to be taken seriously as a general purpose one (including e.g. systems programming).

Also, your list looks like a pretty arbitrary choice of protocols and formats, why don't we also add support for SSH, SMPT, IMAP, PNG?. In the end, everyone would want their niche protocol/format to be included in the standard.

> the dream: compliant compilers must be able to compile down to static binaries, cross compiling built-in.

Cross-compiling to what architectures specifically? The most used ones are proprietary and I think that disqualifies them from being included in a serious international standard, since you'd need to read the spec and implement it in order to be compliant (I'm not versed in ISO inclusion requirements, so this may be already happening, but it would still be wrong. (grepping "x86" in the offical C standard returns no results though.)).

> built-in library support for logging, http, zip, gzip, json, yaml, template rendering, RFC3339 datetime reading/writing

There is a Boost library for each of those things.

> An opinionated, modern packaging and dependency story (like go modules, Rust crates)

> the dream: compliant compilers must be able to compile down to static binaries, cross compiling built-in.

You can use Conan or vcpkg. LLVM basically solves the cross-compiling issue since you can take the IR to any platform that has a LLVM target.

Neither of these are feasible to include in the International Standard because C++ runs on more than amd64 and would make a lot of obscure platforms no longer compliant with the standard. Rust crates are nice, but people building medical devices with C++ shouldn't need to worry about supporting an npm-like monstrosity in their builds.

C++ has many audiences with disparate needs; ranging from firmware, to scientific computing, to application development.

Most of the industries using the language optimize their code for a target platform. And general non-optimized portable binaries are simply not cost effective, so standardizing installation has not been simple.

If you do care about portability, you functionally need to. - ensure you're not linking to anything but LIBC and the VDSO

- compile with no assembly language

- disable most optimizations, and select a sufficiently generic hardware target. For the most part, they succeed in features.

- directly compile all 3rd party source in your binary.

Then, your binary should last a long time.

That all said, I believe your needs are in the minority in the C++ community, and other languages likely better suit your needs.

i never understood the need for package managers. just check your dependencies in and build with the rest of your source code. this doesn't introduce extra moving parts into the system (why should i need an internet connection to build my stuff?), easy to patch and debug dependencies, gives you full control and doesn't restrict your toolchain (e.g. conan doesn't as of now support vs2019+llvm). what i _would_ like to see though is a standardized build system for c++ projects, although that will likely never happen.

Does Eigen not work for your use cases?

mdspan didn't make it in 20

likely and unlikely exist in different forms as compiler extensions for a while. There is code where they indeed help compilers to produce slightly better code for the hot path. Good use typically involves lots of measurement as developers are often wrong about the impact and about what the real flow is.

What kind of things can the compiler improve? For instance it can arrange the code in a way that the instructions of the hot path are directly behind each other, whereas the unlikely case jumps further away. Or it can arrange code a bit to help the branch predictor.

gcc and clang (at least, I don't know about msvc) have had these for a while. Basically, the instructions for whichever branch is declared most likely to be taken will be placed immediately after the comparison instruction(s), which is generally more cache-friendly.

It seems conceivable that it might also affect the compiler's inlining choices in each branch (i.e. don't bother to inline as aggressively in the less likely branch, to reduce code size), though I don't know for sure.

A common way to extend a language is to standardize what people are doing in practice. It seems niche, but you have to remember what C++'s niche is. Linux kernel etc use hints like this extensively

In some niches it is important.

Say you are writing a high speed trading program. At some point you get to the "if(wouldMakeMoneyOnTrade())...". However for every time this passes and you trade there are 1000 where it fails and you don't. However time is critical because your competitors are using similar algorithms and so you need to beat them - thus you put in a likely and ensure that the CPU jumps to the trade code the fastest possible. Your competitors that use Java pay a CPU branch prediction penalty here because the hotspot optimizer has noticed that the if almost always fails and optimized for the false case. Thus you can make money by beating your competitor to the trade. (Note, this doesn't mean you can't use Java for your code, but if you do you need to manage that risk somehow)

Similar to ABSL_PREDICT_FALSE: https://github.com/abseil/abseil-cpp/blob/master/absl/base/o...

Without actually looking at the docs, I would guess these map directly to cpu intrisics that can be used to guide the cpu branch prediction algorithms.

Depends on your needs. If you don't have a lot of or any legacy code yes, go straight to c++17 (or even 20 though you won't be able to use many of the features right out of a the gate, or without third-party libraries). If you can do this you'll be glad you did.

I was able to start a project in c++17 in 2016, though at the time I had to use boost::variant with the Xcode compiler and boost::filesystem for all three compilers (only a limited use so I could even have skipped it). Also for some complex third party libraries I had to make a little trampoline file that compiled in C++14, or with special flags, and then call those entry points.

Since I was starting from a blank slate I also compiled everything with pretty much maximal warnings an -Werror which really improved the code a lot, something you can never get away with with legacy code (not to insult working legacy codebases!)

C++11 was the major version bump. It changed how you're supposed to write C++. C++14 & 17 are just minor fixes & improvements. So there's really no reason to not start with at least C++17.