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

just opened a file and...ugh

https://android.googlesource.com/platform/art/+/refs/heads/m...

like, just this, basically C:

    if (strncmp(argv[arg_idx], "-XXlib:", strlen("-XXlib:")) == 0) {
       ...

is just so complicated and error-prone over

    if(std::string_view{argv[arg_idx]}.starts_with("-XXlib:"))  
       ...

(which I guess is the intent)

I don't get the point you're trying to make, sorry. "Big companies sometimes write crappy code" is of course going to be true.

Overloading << is part of Stroustrup's iostreams toy and thus enjoyed the advantage that the language's creator was advocating it from the outset (it pre-dates the C++ standard library). I doubt that anything so ugly and dangerous would be standardised even in C++ today.

Because this is actually still a shift operator, it retains all the precedence of the shift operator even when tired humans think of it as as a clever new stream out operator. So if you're in a situation where shift has precedence, the operator fires, and too bad if that wasn't what you'd intended nor what makes sense to a human reading the code.

Oops.

Some languages let you mint new operators (from some limited combinations of symbols) or allow infix function calls, or by some other means provide for you to nicely extend syntax here, but the overload of unrelated operators was IMNSHO an ongoing disaster whose popularity with programmers is unexplained, like C's decision to treat an array as just the pointer to the front of the array.

But I'm a cranky old man, I also don't like the fact that Rust's + concatenates Strings (this isn't inherent in the language since String isn't a built-in type, in Linux kernel Rust nothing like this exists, because Linus would throw a fit, but in the out-of-box runtime environment Strings implement the Add operator as a concatenate operation).

I’m in the same boat, I’m learning game engines and so many libraries are in C++.

It feels impossible to use Rust or Zig, but I have hope I can use Nim. It can compile to C++ and has a simple-ish way of wrapping C++ code. Maybe it would interesting for you too?

All your examples can be replaced by

    std::vector<T> vec(numValues); 

as vector value-initializes.

Personally I prefer an explicit reserve or resize, but still..

Oh how I agree about the uniform initialization! And to make matter worse, I now work on a code base where it is the mandated form in the coding standard. At least your initial example now gives me ammunition against it, but too late for this coding standard.

It makes code look silly, too, as now initialization looks different from assignment.

     int i { a + 2 };
     i = a + 4;
     
     int j = a + 2;
     j = a + 4; // ah! consistency!

Also, although this might be more obvious to people familiar with any C-like language, C++ considers that since 'x' is a character, and its characters are fundamentally just an integer type (maybe a signed 8-bit integer, it depends) the third list is just two constant integers, which are a perfectly reasonable thing to put in a list. Even though that's obviously not what a human sees.

In a language that isn't just pretending to be strongly typed, the compiler would notice that char and whatever-integer-type-42-is aren't the same type, and it would reject your program as nonsense.

But that confusion gets much less chance if the language explicitly distinguishes initialising collections so that "I want N of X" is different from "I want N, and X". Compare Rust's vec! macro:

  let mut v = vec!['x'; 42]; // NOTE semi-colon. Compiles, vector of 42 x characters

  let mut v = vec!['x', 42]; // NOTE comma. Does not compile

  let mut v = vec![b'x', 42]; // NOTE comma. Compiles, vector containing 120 (the ASCII code for 'x') and 42 as bytes

  let mut v = vec![b'x'; 420]; // NOTE semi-colon. Compiles, vector of 420 bytes with value 120

  let mut v = vec![b'x', 420]; // NOTE comma. Does not compile unless you explicitly tell Rust that you mean the low 8-bits of 420 if you do this

I'd actually be enthusiastic about a Clippy warning for the middle one, because it feels like the odds are better than they should be that wasn't what you meant. But on the other hand, the odds of you wanting either possibility are slim, so, not a priority.

The way I would think about it is: C++ isn't any weirder than English. As long as you are happy to accept there are things just there for weird history reasons, it's not too bad.

The "Pit of success" and "Pit of failure" aren't really about what's available in a language, it's about what's easy and natural.

I'd argue that in a language with the `new` keyword, nothing is more easy or natural than invoking it. `auto Foo = std::make_unique<Foo>(args);` is absolutely the right thing to do, but would you really be surprised to find `auto foo = new Foo(args);`?

I absolutely agree unique pointers are the right call. They just aren't necessarily the easy or natural call.

The contrast is rust where all ptrs are, by default, unique ptr and the compiler validates that for you.

in my experience, it's almost inevitable that you end up calling some code you don't control that returns raw pointers. better hope you have access to the source or at least some good docs :)

Can we agree that the new "best default" way of instantiating is... pretty damn weird?

    auto foo = std::make_unique<Foo>(args);

Think about explaining this to a new C++ developer.

This will feel much more natural to most developers:

    var foo = new Foo(args);