Autocheck To Check If Your C++ Code Is Safe For Automobiles & Safety Critical Systems

[mdedetrich]

It is. I'm speaking it the way it actually is. Look pal, there is a reason most of the world despises math to the point of it being a meme (you know). It's not math itself, a lot more people like physics for instance, it's the SYNTAX. Get over it.

It's antiquated and obscure as fuck. On top of all it uses greek letters, seriously?

For example compare how clean a for loop is to a "sum" in math notation. Or a "casual" syntax like 1 + 2 + 3 + .... + 10 not the bullshit math formality.

The amount of stupidity that is written here is so immense I am in awe on how to respond to it.

[darkonix]

This is one such case, yeah. What's wrong with "var"? variables should be mutable by default (note that variable means it varies), constants shouldn't of course. "let" is also an issue. I mean you already use the "let" keyword, so it's pointless extra fluff. Javascript has let but that's to preserve backwards compatibility with "var" keyword. "let mut" is just horrid.

tl;dr "var" for mutable variables, "const" or "let" for immutable (I know const is already used though). Not both.

But anyway this is just words, not that high on the syntax issues.

The other issue is the colon for specifying types. Extra pointless fluff. In constrast, in C you legit just put the type and var name, no keyword even needed.

Yeah that's a big one. I mean you could use any other symbols or ways to denote it, no? For example @ and yes this is just an example.

I actually don't know anything about Rust macros but I heard they're super ugly as well.

There's also stuff like trailing return types for functions, which I also despise in C++ (though it's a newer addition), and the redundant "fn" keyword (but well it's needed due to stupid trailing return type you know). Too functional-language syntax for me.

Note that a lot of the syntax is shared by "modern" C++ full of template and container bullshit everywhere, which I also find hard to read. Legit sometimes feels like every other character is a colon. Jesus.

Opinions about syntax are very personal and everyone is entitled to their own. I share a few of those but in general I like Rust. Do you have other issues with the language other than the syntax?

[mdedetrich]

Opinions about syntax are very personal and everyone is entitled to their own. I share a few of those but in general I like Rust. Do you have other issues with the language other than the syntax?

Yes, it has math and apparently math is bad

[ssokolow]

This is one such case, yeah. What's wrong with "var"? variables should be mutable by default (note that variable means it varies), constants shouldn't of course. "let" is also an issue. I mean you already use the "let" keyword, so it's pointless extra fluff. Javascript has let but that's to preserve backwards compatibility with "var" keyword. "let mut" is just horrid.

tl;dr "var" for mutable variables, "const" or "let" for immutable (I know const is already used though). Not both.

But anyway this is just words, not that high on the syntax issues.

They did it that way for consistency... especially given that there are actually two places you can use mut in the argument's signature

fn example(mut my_ref: &mut str) {}

The first mut indicates that my_ref is a mutable binding (i.e. you can go my_ref = ...; without just using shadowing via another let) while the second one indicates that the memory location storing the pointed-to address is mutable (i.e. you can use it as an out parameter.)

This becomes more significant and useful when you might have a mutable binding to a struct that has at least one field that remains immutable. (eg. an Iterator over some shared memory, where the binding is mut so the iterator's internal cursor can change, but the compiler can disallow iterator invalidation at compile time because the iterator still only holds a read-only reference to the backing store.)

The other issue is the colon for specifying types. Extra pointless fluff. In constrast, in C you legit just put the type and var name, no keyword even needed.

That was specifically to avoid the need for the Lexer Hack. (i.e. to gain a massive win on how easy the grammar is to parse for only a very minor change to the syntax that pretty much every non-C-descended grammar already does anyway, including Wirth languages like Pascal and more common-in-modern-day stuff like the optional type annotations in TypeScript and Python).

That aside, given how commonplace type inference is in function bodies, a keyword would very much have been needed in your proposed approach. C++ named it auto.

Yeah that's a big one. I mean you could use any other symbols or ways to denote it, no? For example @ and yes this is just an example.

That's one I don't like either, so I won't try to defend it. All I can do is explain it: They copied the syntax off OCaml, which took inspiration from the notation used in mathematics journals.

I actually don't know anything about Rust macros but I heard they're super ugly as well.

They're basically just a metaprogramming version of Rust's match (switch/case on steroids) construct with $variable templating mixed in.

Here's a simple match you're likely to see for dealing with a tagged union:

match some_result {
    Ok(x) => { println!("Success. We got {}!", x); }
    Err(e) => { println!("Ouch! Failed with {}!", e); }
}​

...and here's a declarative macro:

macro_rules! example {
    ($foo: expr) => {
        // Code written here is a template
        // which can use the $foo placeholder
    }
    ($foo:expr, $bar:lit) => {
        // Code written here is a template
        // which can use the $foo and $bar placeholders  
    }
}​

It's basically like C++'s function overloading, but at the metaprogramming level. You can either call it as example!(any_expression) or example!(any_expression, only_a_literal_will_do) and it will substitute whichever code block matches the signature or give you a compile-time error if there's no matching variant.

There's also stuff like trailing return types for functions, which I also despise in C++ (though it's a newer addition), and the redundant "fn" keyword (but well it's needed due to stupid trailing return type you know). Too functional-language syntax for me.

Again, chosen to make the language simpler to write a parser for.

[Weasel]

The amount of stupidity that is written here is so immense I am in awe on how to respond to it.

Cope harder with math memes and why so many people hate math.

Syntax by actual dinosaurs.

[Weasel]

Opinions about syntax are very personal and everyone is entitled to their own. I share a few of those but in general I like Rust. Do you have other issues with the language other than the syntax?

Yeah, it's just too hard to do some sensible things without using unsafe (even simple binary trees for instance), and I'm personally not a fan of copy pasting libraries everywhere like most "developers" these days. So please don't say something like "just use the standard library's binary tree", that was just an example. I'm not a library plumber I'm an actual software developer. I know, rare sight these days.

Another big issue is automatic bounds checks at runtime by default. Runtime being the keyword.

But granted in terms of functionality Rust isn't anywhere near as bad as garbage-collected languages (not interpreted, but compiled, like D or Go for instance). Interpreted languages having a GC is totally fine though. Different use cases. Another "perk" of Rust is that it doesn't have exceptions, and I absolutely despise them in C++. Not better than C in this department though. But at least nobody forces you to use them in C++ either, except when you see people plaguing their code with them.

[mdedetrich]

Cope harder with math memes and why so many people hate math.

Syntax by actual dinosaurs.

Yeah math scary, big problem for dem little programmer boys

[darkonix]

Yeah, it's just too hard to do some sensible things without using unsafe (even simple binary trees for instance), and I'm personally not a fan of copy pasting libraries everywhere like most "developers" these days. So please don't say something like "just use the standard library's binary tree", that was just an example. I'm not a library plumber I'm an actual software developer. I know, rare sight these days.

Why would a binary tree implementation require to use unsafe? You can find several examples of people doing that without doing anything unsafe just googling for it. This is just an example: https://www.iainmaitland.com/binary_tree

[ssokolow]

So please don't say something like "just use the standard library's binary tree", that was just an example. I'm not a library plumber I'm an actual software developer. I know, rare sight these days.

Bear in mind that Bryan Cantrill's bit in this talk is relevant. Both how Rust makes composing parts more feasible and the more general implications of his statement that "the implementation for B-Trees in Rust is total rocket science".

Basically, sure... you can reinvent your data structures... but you shouldn't have to... especially in this era when software development is growing beyond the middle ages "knowledge was sparse enough that it was possible for one man to know everything" situation where programmers who do do everything will be at a disadvantage compared to people who compose building blocks made by people and projects who specialized in implementing that particular task very very well.

Another big issue is automatic bounds checks at runtime by default. Runtime being the keyword.

It depends on how you implement it. There are plenty of language constructs which will not do runtime checks because it's proven correct at compile time. (For example, Iterators will only check once, same as in C or C++ and, because C's ASSERT is equivalent to Rust's debug_assert!, you can use an assert! to hint to the optimizer that the data structure will always be bigger than the largest index you access so it'll strip the bounds checks from everything following the assert!.)

C++ and Rust are the same on that point. It's just that, in C++, if you write bad code, you get memory corruption and/or undefined behaviour. In Rust, if you write bad code without using unsafe, you either get a panic (ASSERT failure) or bad performance, depending on which construct you used. In either case, the problem is that you're using the tools you've been given incorrectly, not that the language is slow.

TL;DR: If C++ gets to yell "git gud" at complainers, then Rust can too.

Another "perk" of Rust is that it doesn't have exceptions, and I absolutely despise them in C++. Not better than C in this department though. But at least nobody forces you to use them in C++ either, except when you see people plaguing their code with them.

I'd say having proper sum types is a significant difference.

[Weasel]

Bear in mind that Bryan Cantrill's bit in this talk is relevant. Both how Rust makes composing parts more feasible and the more general implications of his statement that "the implementation for B-Trees in Rust is total rocket science".

Basically, sure... you can reinvent your data structures... but you shouldn't have to... especially in this era when software development is growing beyond the middle ages "knowledge was sparse enough that it was possible for one man to know everything" situation where programmers who do do everything will be at a disadvantage compared to people who compose building blocks made by people and projects who specialized in implementing that particular task very very well.

Thanks for the link. But I was talking in general, binary trees (not B-Trees but still) were just an example. What I meant was that adding custom things like that is just unnecessarily difficult.

It depends on how you implement it. There are plenty of language constructs which will not do runtime checks because it's proven correct at compile time. (For example, Iterators will only check once, same as in C or C++ and, because C's ASSERT is equivalent to Rust's debug_assert!, you can use an assert! to hint to the optimizer that the data structure will always be bigger than the largest index you access so it'll strip the bounds checks from everything following the assert!.)

Right, that's basically an optimization. You can add bounds checks yourself and they can be removed by optimization.

The problem is that sometimes they can't be proven, and the code can be correct, so they're there plaguing the binary. For instance if it's an external argument or parameter it can't inspect. Even if it comes from user input, maybe it was already validated up the chain, so there's no point checking for it again (anyway, "validation" needs to have proper error checking and feedback so it still has to be done regardless, an ASSERT is just trash, really should only exist for debugging).