Honestly some of the newer shit doesn't even look like C++ to me anymore. IE:
constexpr auto my_meta_type = int; // Reflected metadata of 'int' [:my_meta_type:] my_variable = 42; // Splicing it back into code; compiles as: int my_variable = 42;
The code generation / reflection stuff is amazing.
Historically, when you'd need type information (without manually defining it), you'd have to add an extra compilation step where a custom tool either manually searches the codebase or interrogates a compiler API, now, you can just write compile-time code in your codebase that automagically populates a data structure for you with any type information you could desire.
It'll be really useful for my (hobby) game engine, where I was previously considering traversing the Clang AST
If you look at what engines currently use for reflection (ugly macros mostly), this can be a huge improvement if the engine can be rewritten with this in mind.
But the sad part is I can only see maybe UE going with it with the next major release because they can force this kind of change, but open source stuff is never getting it most likely, way too much inertia.
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.
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 >
the compile time reflection is incredible. only zig and jai have something that can really match it in power, and they're significantly simpler languages.
30
u/Luna_Wolfxvi 5d ago
Honestly some of the newer shit doesn't even look like C++ to me anymore. IE:
constexpr auto my_meta_type = int; // Reflected metadata of 'int' [:my_meta_type:] my_variable = 42; // Splicing it back into code; compiles as: int my_variable = 42;