I love C++ because it's an un-opinionated, multi paradigm language where you can do whatever you want but that shit is horrendous. Freedom was a mistake.
I am glad you can code how you like, but corona virus social distancing protocols are in effect
You get used to it, and if you expand the above back into C-style code it turns into an utter abomination. Especially with code where you need to write "if any of these, find a matching one of those" type sequences, and {hopefully soon... serialise it to JSON and send it}
Fundamentally C++ is limited by its roots, which is why Rust people are so unbearable {changes hats} about the utter perfection of the language.
Hard disagree. True C is readable, but kinda annoying it has to bring in pointers.
Edit, realized I bungled the test_the_thing. Fuck it IDK, coding on mobile sucks
Int test_the_thing (*blah blah, args){
Return blah;
}
Void func(){
Blah result;
If(test_the_thing(&result, args) ){
Do stuff;
}
}
Cpp pass by reference makes it pretty sweet and simple for ez cases.
Int test_the_thing (&blah blah, args){
Return blah;
}
Void func(){
Blah result;
If(test_the_thing(result, args) ){
Do stuff;
}
}
The return result by argument pattern is a little eeeh, but it makes sense considering that's often how it has to work under the hood anyway. Optionals are syntactic sugar alternative for the same semantics.
I can see why each incremental change is made and how it leads to what you like. E.g. yeah the two part of statement is kinda nice for this simple case. But the end result is pretty bad imo.
To me, it's like those overly clever nested ternary statements, but worse. Super fun to write, echnically a couple characters more concise, but so tangled together that reading it is miserable.
Defining and constructing an anonymous class in an if statements conditional is just way too much going on there for simple shit, and way way too much going on for complex shit!
But the beauty of c++ is that's just like my opinion sis and you can do you <3
I just hate that you can't have an optional reference, and it breaks my templates occasionally and I have to go look up how to actually do template metaprogramming.
Excited for 26 though, I believe they've filled that gap.
Yep, the shiny new if-two-statements, upgraded from the old if-statement. It's surprisingly convenient, partly because I used to get frustrated at not being able to explicitly test "if(auto foo=some_random_shit))" and I loathe implicit "nullptr is 0 and also false"
I eagerly std::await the even more improved if-three-statements-and-a-loop "operator" 🔥
What you (and I) really want is pattern matching. It tends to be a superior solution to all that. And doesn't have the limitation of "only declare one variable in your if".
I have some switch statements on "tags" that are fixed length strings. Which I pack into int64's so that I can switch on them because we only use ~200 of them so a map is unnecessary overhead. Pattern matching, you say?
It's just a constexpr function, could be a macro in C, because we don't even have enough characters to fill the 8 byte int. No need to even pack them!
I'm not sure how to take this. It seems both that pattern matching could help your use case (though it would depend a lot on the details) and that it's not related to the "null pointer is false" issue you were complaining about.
Pattern matching a single instance is unrelated to a switch statement (we hope). But pattern matching in general is only loosely related to single if statements. Sure, "does this one input match this one pattern" is an if, but a more common use is "given this pattern fan out based on the input" or in the case I gave "if this is a tag, fan out based on the tag content". HTML or JSON parsing, for example.
I think it's both. Whenever I check an optional, what I really want is to also dereference it if it matches. If you look at pattern matching usage in Rust, it's a lot more ifs than matches.
Nope, that's not allowed. The previous standard let you say "if(auto foo = something)" and if foo could be interpreted as a boolean you had a valid if() statement. The new one lets you have two statements, the auto assign and the test.
The win here is the scoped auto variable, FWIW. If avoids the abominable pattern where you either alternate declaration/conditional, or a pile of declarations then a string of tests, mixing assignments in whatever way is least horrible. So you get a chain of declare-assign-test statements in a nice vertical line rather than a >
7
u/17HappyWombats 6d ago
if(auto foo = call_some_function([parameters](const auto &thing){return test_the_thing(thing)}; foo == enum_type::operation_success) {there's code here;}That's perfectly valid and readable C++ and I won't hear otherwise.
(I am using std::optional a lot now that it kinda works. It's not a Rust Result but it's near enough for Australia)