We used C++20 to eliminate a class of runtime bugs

https://devblogs.microsoft.com/cppblog/how-we-used-cpp20-to-eliminate-an-entire-class-of-runtime-bugs/

by maccard • 5 years ago

146 101 5 years ago

devblogs.microsoft.com

maccard8• 5 years ago

I saw this this morning (and also rusts support for fmt strings). Whenever c++ is discussed I often find myself defending modern c++ against people who want to write c++03 because it's simpler. I like this article because it shows how useful modern features really are in practice.

pjmlp17• 5 years ago

C++ is one of my favourite languages, however there is a big difference bettwen being able to write modern C++ in side projects, and what most companies consider C++.

Enjoy a sample of AOSP source code, https://android.googlesource.com/platform/art/+/refs/heads/m...

throwawaybbqed• 5 years ago

Wow ... I want to pull my eyes out now. Is this really some uber critical path in the code or did the author(s) have too much time on their hands/optimizing some other metric (e.g. promotion, proving how smart they are, attempting to get job security). I am also astounded by two things related to documentation .. it is nearly non-existent, and where it exists, seems to provide almost no context to someone other than the original authors.

You posted this for a reason .. would be good to get your thoughts.

edit: adding one more point. I went to a fairly high-ranked university(top-20). We would get graded based on how clear our code was, comments (both for functions and inline comments). This code would get a zero on those metrics.

maccard8• 5 years ago

Just because some companies write ancient C++ code doesn't mean all companies do. I write mostly C++17 these days for a company, and my previous job wasn't exactly afraid of modern C++ but they could have embraced more of it. The post I shared is from Microsoft about writing modern C++ .

gruez• 5 years ago

Enjoy a sample of AOSP source code, https://android.googlesource.com/platform/art/+/refs/heads/m...

What am I looking for? Is it just the use of smart pointers?

jjice• 5 years ago

I don't write C++ for work and I've written very little ever, but it seems like C++ and PHP (which I do write daily) have a similar trend. They get shit for being old and bad, but people haven't seen the myriad of new features, safety, and solid ecosystem.

pjmlp17• 5 years ago

That is true, I have plenty of stuff to complain about C++ and PHP, but also have similar list about Python, Java, C#, F#, C and many other languages of similar age.

still_grokking4• 5 years ago

It's impossible to retrofit sanity ex post facto into something that's broken by design. The nonsense on the base layers will always creep into the higher levels through unavoidable abstraction leaks (which are usually unavoidable exactly because said nonsense on the base layers exists in the first place).

That's why repairing design mistakes is only achievable by rewrites, inevitably breaking compatibility with the old system in this process.

rixed3• 5 years ago

Complexity can solve issues but can also bring new ones.

For instance, I've been bitten recently by the new "universal" syntax to write variable definitions with only curly braces.

  #include <iostream> 
  #include <string>
  #include <vector>

  using namespace std;

  int main() {
    // Forty-two things:
    vector<string> v1 { 42, "foo" };
    vector<int>    v2 { 42, 1 };
    vector<char>   v3 { 42, 'x' };

    cout << v1.size() << " " << v2.size() << " " << v3.size() << endl;
    return 0;
  }

This prints, of course:

42 2 2

edflsafoiewq• 5 years ago

The committee loves overloading. IMO they overuse it. I think once you start thinking "this overload only participates in resolution if..." you should start considering different functions.

blindseer• 5 years ago

Ugh.

I'm firmly of the opinion that if anyone uses a sane programming language first, they'll absolutely do anything they can to avoid C++.

Corollary being, 1) if C++ is your first language, you'll end up learning all these rules and exceptions to the rules and assume that is just how it is (this is the way I think about Python), and 2) if you use C++ you are aiming for performance that alternative languages cannot provide. I'm glad the gap between alternatives and C++ is narrowing. If I could, I would never write another line of C++ again. Rust and Zig are FAAAARRRR better alternatives to me personally, purely because there's fewer gotchas I have to keep in my head when attempting to do anything with those languages.

jcelerier5• 5 years ago

I'm curious about your use case for calling the vector(size_t, value_type) constructor (vector<string> v1 { 42, "foo" }).

I'm on a codebase of a few hundred kloc and the need for a vector initialized to anything but the default value pretty much never came up. It uses boost, Qt, llvm and two dozen other libraries, yet there is a grand total of eight instantiations of that constructor in it.

When putting a breakpoint, it turns out that all the calls to it I could trigger actually just initialize with the default value statically (e.g. vector<T*> v{x, nullptr};).

LAC-Tech2• 5 years ago

Can someone explains why it prints that?

CJefferson4• 5 years ago

This was, in my opinion the single worst thing added to C++ -- it's what made me quit the C++ standard's committee, as it was clear (to me) how much of a mess things were.

Different people wanted "{ } for unified construction" and "{ } for initalizer lists", and we ended up with this mess which made 0 people happy, and ruined unified construction.

beached_whale• 5 years ago

Generally in C++ one should use Type name = Type( args... ) style to be the least surprising. Prior to C++20 that would be aggregates. It's really too bad that initializer_list gets special treatment, and it's universally wart in C++. The alternative would have been vector{ { 1,2,3} } and that would have been fine.

maccard8• 5 years ago

universal initialization is the worst feature added to modern c++; these changes are unexcusable IMO.

uvdn72• 5 years ago

C++‘s initialization is utterly broken. Eg to understand the difference between just ‘struct Foo f;’ and ‘struct Foo f{};’, you have to come across about 10 different kinds of c++ initialization terms.

Is there a way out of this (serious question)?

makecheck• 5 years ago

Worse, even without the vectors, the initialization of single variables of these types would be different with the same syntax, e.g.

    string s; // initialized (empty)
    int i; // NOT initialized (garbage value)
    static int i; // initialized (to zero)
    char c; // NOT initialized (garbage value)

...I mean, it’s always been a complete mess.

kazinator2• 5 years ago

When I was programming C++ regularly, which was C++03, I wrote a robust format string system which could catch all mismatches against the format string at run-time. Which is good enough in practice if you actually test the code paths.

What's valuable is being able to compile format strings into faster code, like the formatter macro in Common Lisp.

superkuh2• 5 years ago

C++?? every 3 years isn't nearly as bad as say, the Rust situation, but it does mean that a linux desktop distro compiler can only compile stuff from "hip" devs writing in C++ for about 3 years after the distro release. It means if you chose to use these language features the vast majority of people will not actually be able to compile it.

So balance that. If you're not just distributing binaries, if you have geek end users compiling, maybe don't always use the latest bleeding edge C++?? features.

jcelerier5• 5 years ago

Nah, this is also why the Linux desktop is behind. On Windows I build on win10 VMs with the very latest C++20 features and can ship back to Win7 because Windows does not idiotically tie a compiler version to an operating system.

jokoon• 5 years ago

I remember using variadic template to implement a print() function, to print any type of variable, with a variable amount of arguments.

I got help to implement it, it was a bit difficult, but quite nice to have.

DiabloD3• 5 years ago

Imagine what happens when Microsoft moves to Rust, it will be a red letter day.

pjmlp17• 5 years ago

There is some ongoing Rust adoption on Azure and IoT, but I doubt WinDev C++/COM bastion will ever allow anything else, given how they manage to keep it going over the years.

scoutt• 5 years ago

Well... a "Microsoft Visual Rust" (integrated with Visual Studio) could be all the motivation I'm looking for to finally learn, mmmm, not learn but to finally put Rust at serious use.

With everything integrated like, you know (and this may sound super crazy) graphically-mouse-operated "create new project", "right click -> add new file to project", resource editor with "create a window with a button, double-click the button and generate a function to handle the event"-sort of thing. F7 to build, F5 to debug. More or less the things we are used to since the past 30 years or so!!!

formerly_proven• 5 years ago

Maybe they can even recreate that amazing Visual Studio project settings dialog for Rust!

muricula• 5 years ago

MSRC is pushing rust internally: https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-win...

flumpcakes4• 5 years ago

Microsoft have done a lot of working attempting to make every windows C/C++ API available for use in Rust. This task is/was too big to do by hand (and sensitive to changes) so they have automated it. See: https://github.com/microsoft/windows-rs

ducharmdev2• 5 years ago

As someone coming from a web background with almost no systems programming experience, Rust is appealing to me in terms of it's language features and support for a functional style of programming, as well as the documentation and tooling (among other things).

But from the little I've learned about modern C++ and RAII, I wonder how systems engineers will respond to Rust in the long-term. Memory safety seems to be the primary argument in favor of using Rust, but what would be easier - rewriting everything in Rust, or refactoring existing code to take advantage of RAII?

zwieback• 5 years ago

I used to be a 100% C++ programmer in the olden days but over the years C# and Python have pushed my C++ percentage down to maybe 10% super time critical code and some embedded.

RAII is the one thing I really really miss from my C++ days. From what little I know about Rust it seems to promise a more "baked-in" version of RAII so I'm all for it. Haven't found the time to experiment but looking forward to eventually dipping my feet in.

cogman103• 5 years ago

I'd argue that RAII is pretty well baked into C++.

For Rust, it's the "Drop" trait that you add onto things which ultimately causes RAII behavior.

You don't need to do it as much with rust as a lot of the reasons for wanting RAII (memory management) are simply handled by the language.

For Rust, it's sort of the "Pit of success" the easy thing to do is the right thing to do. Whereas in C++, it's pretty dang easy to new something up and fail to correctly delete it.

pjmlp17• 5 years ago

If you are using a relatively recent version of C#, you can get quite close to it, specially now that using can make use of structural typing.

And with help of Roslyn, any type with a "destructor" (aka Dispose) that gets used without a using declaration can be turned into a compiler error.

cogman103• 5 years ago

rewriting everything in Rust, or refactoring existing code to take advantage of RAII?

Oh, refactoring existing C++ code is easier, hands down.

You can, for the most part, keep your C++ algorithms exactly as is with little rewriting. Rewriting in rust may force you to totally rethink your approach (or use a lot of unsafe, or write really inefficient code).

leetcrew2• 5 years ago

I'm not sure I fully understand the question. RAII is powerful, but it is just a tool to organize what is still manual resource management. it can help with memory/thread safety, but it doesn't guarantee those things by itself. ex: it's nice that std::vector's memory buffer will be freed when the object goes out of scope, but I can still do something stupid like hold onto to its .data() pointer and try to dereference later.

to answer the more general question, I think most engineers would prefer to refactor a c++ project over rewriting the whole thing in rust, and rightly so. you usually don't want to fuck around with delicate things that currently work in these sorts of projects. perhaps over time you end up with an FFI layer over a thoroughly tested c++ core. then new features can be written in rust or whatever friendly language is popular at the time.

ducharmdev2• 5 years ago

I appreciate the clarification, my understanding of this stuff is pretty superficial.

Putting it that way, I can see why someone would appreciate that Rust guarantees safety by default, instead requiring you to opt-out explicitly when needed (with `unsafe`), versus the opt-in nature of RAII - for greenfield projects, anyway.

rileymat2• 5 years ago

One quibble one of the best uses for RAII is not memory management but any external resource like db connections or file handles or mutexes.

The built in smart pointers take care of much of memory management. (Although they use RAII internally)

pjmlp17• 5 years ago

RAII was already a thing in C++ compilers for MS-DOS.

CJefferson4• 5 years ago

I've been using RAII in C++ since 2002 or so -- so it's not a new thing to do.

Personally, I maintain quite a lot of open source C++ code -- I'm not rewriting that in Rust, but I'm writing new projects in Rust.

joatmon-snoo• 5 years ago

I recently bumped my company's fmtlib version to the one that has compile-time format strings, and it's been such a load off our minds to not have to worry about this anymore. We're reasonably early stage (12 people right now) and even with all of us being reasonably senior, I still found a few callsites where the compile-time format string caught bugs.

(FYI: for anyone holding off on this because of issues with spdlog, enough has been fixed in the latest versions of both that you can upgrade them together now.)

Also worth noting: the UX of fmtlib's compile-time format strings is actually quite interesting. There are error callbacks in the consteval calls that take advantage of the context that compilers show in compilation failures that detail the mistake being made.

(Aside: I'd also like to note that `absl::StrFormat` has supported compile-time format strings for quite a long time. https://abseil.io/docs/cpp/guides/format)

LAC-Tech2• 5 years ago

I haven't used C++ in years. I can remember writing C++11 and transitioning to C++14. And also lots and lots of Valgrind :)

What's it like these days? Is tooling pretty much the same - downloading packages from linux, some header only libs, and makefiles? Has the Language Server Protocol made in roads with C++ editors and IDEs?

ncmncm6• 5 years ago

C++20 is as big an advance as 11 was, and is taking as long to penetrate.

Editors all know C++ now. Generic lambdas in C++14 made coding fun. Template metaprogramming is hardly ever needed or useful anymore. Builds got faster with module support (essentially standardized precompiled headers), and also ccache and ninja. As Concepts penetrate, error messages get radically better.

Valgrind is increasingly unnecessary, as use of op new vanishes.

flumpcakes4• 5 years ago

One of the most interesting changes to me is how much they are pushing metaprogramming into the language itself _without_ a lot of the traditional annotations that went with TMP before.

For example, annotating a parameter with 'auto' instead of the typename T preamble.

kazinator2• 5 years ago

What this is saying to me is that they have untested code paths. All the places where error encountered bad parameters are not actually covered.

It doesn't seem incredibly valuable to know that some error() calls in untested code are well-formed, since that code could be broken. The error() could be a false positive, or the compiler could crash before reaching the error() call due to some bug. Or some of the errors() could be in de facto unreachable code: no test case can cause them to be executed.

If you have a test suite which hits all the error() calls, and if the formatting system is robust to catch bad arguments at run-time, you don't have a problem.

We used C++20 to eliminate a class of runtime bugs

Related Stories