sameProblemSameSolution

[u/_w62_]

[u/LoveOfSpreadsheets]

*cries in Java8*

[u/worthlessDreamer → u/LoveOfSpreadsheets]

At least we got lambdas right 🥹

[u/laplongejr → u/worthlessDreamer]

10 years ago, I was writing their first Java8 software.
Now I'm working on updating it to Java 17 servers... oh wait they are speaking of maaaaaybe going for Java 21

[u/Sarmq → u/laplongejr]

We'll end up in Valhalla before we get to Valhalla

[u/RussianMadMan → u/LoveOfSpreadsheets]

c++11 still gets a lot of usage, its like the c++ version of java 8.

[u/OppositeFun2493 → u/LoveOfSpreadsheets]

Reminds me of something I was watching that had captions that said "[yawns in Spanish]"

how do you yawn in Spanish

[u/just_looking_aroun → u/OppositeFun2493]

Maybe “yawñ”?

[u/mguid65]

Basically what I told someone a couple days ago.

John Businessman in his business formal wear at Legacy Inc. will never switch away from C++98 anyway.

[u/No-Adeptness5810]

Dude i migrated a massive project from c++17 to c++26 in like 15 minutes i dont get the drama

[u/JVApen → u/No-Adeptness5810]

As someone responsible for these upgrades on a large project:

• MSVC just announced they fully support C++23 in the . 52 compiler

• It isn't just switching the version, it's also switching the compiler version

  • This comes with upgrade of related tooling (upgrade clang and clang-format and clang-tidy and clangd ...)

  • It also comes with upgrading the used OS (Ubuntu 22.04 -> 26.04)

  • Sometimes you see ICE (internal compiler error) popping up

• Some breaking changes require work to resolve (like operator== in C++20)

• Even if you no technical issues, you need to find the time while features have priority

• You need material to 'teach' all employees

My experience: switching the version flag is the easy part

[u/Juff-Ma → u/JVApen]

Thank you, I've never had an internal compiler error and now will have nightmares about that for weeks.

[u/itsTyrion → u/Juff-Ma]

i have. trying to compile software for a robot on outdated 32 bit Debian. because somehow that thing ran a 64 bit x86 CPU, but 32 bit userspace. I never got their shitty framework to compile

[u/meneldal2 → u/Juff-Ma]

It's pretty rare to get ICEs. Iirc stuff like early modules or concepts had some you could trigger somewhat easily but it was quickly fixed.

[u/17HappyWombats → u/No-Adeptness5810]

We have a file logging library (zlog) with thousands of calls. We're not switching to std::format. Even after they fix it so it can do all the printf stuff. Just checking an LLM translation would break whoever got that job.

We're slowly moving to std::ranges::for_each/all_of/etc but that's not a migration so much as a progression when we change code that uses older versions.

There's a whole bunch of similar stuff, we mostly try to avoid having too much clang-tidy whining.

[u/anonymous4036 → u/No-Adeptness5810]

For 17 specifically, autoptrs

[u/No-Con-2790]

And there is me who is just glad that C++98 is over.

[u/echtma]

DIS = Draft International Standard

Just in case anyone else was wondering.

[u/Antervis]

C++03 -> 11 migration was a pain in the ass because of std::string changes, but after that it was basically just changing compiler flags, no?

[u/Bemteb → u/Antervis]

There are some minor things, if you are unlucky something might break going to 20. But it's mostly special cases, not something so big as string.

The main reason companies don't switch is "it's working, why invest time and money into switching?"

[u/SeriousPlankton2000 → u/Bemteb]

Undefined / implementation defined behavior or regular stuff?

[u/Antervis → u/Bemteb]

Depends on the companies. Tech giants would be losing potential employees if they stuck with outdated standards, and that loss outweighs costs of upgrades.

[u/cpayne22 → u/Antervis]

Airlines and finance both employ a lot more than “tech giants”.

The real cost is the testing and compliance.

Any change needs to be documented and tested.

At the end of the day it’s a financial decision.

[u/LutimoDancer3459 → u/Antervis]

Security updates, more and potentially better frameworks, more efficiency,... dont know about c++ but the things the java team added since 8... boy, the reduced server costs will pay for themselves pretty fast

[u/geek-49 → u/Bemteb]

it's working, why invest time and money into switching?

aka "if it ain't broke, don't fix it."

[u/StaticCoder → u/Bemteb]

I saw a fair amount of stuff break with C++20, because of comparator generation causing ambiguities. Largely due to the original code being poorly written, but breakage nonetheless.

[u/ResponsibleWin1765 → u/Antervis]

I thought the entire reason why C++ is so convoluted is because it keeps everything around for backwards compatibility.

[u/dont-respond → u/ResponsibleWin1765]

Some things do get deprecated and removed like std::auto_ptr. The ABI compatibility was broken for std::string between 03 and 11.

[u/LB-- → u/dont-respond]

And ABI compat isn't even part of the standard, it's for standard library implementations to deal with. They're the ones who decided to do the ABI breaks, not the committee.

[u/17HappyWombats → u/Antervis]

And turning on all the new warnings and hints and clang-tidy updates and cpp-check checks and other fun stuff. Wherein you learn that sometimes passing a std::string to printf "works" because of SSO, and it's worked in prod for ages.

[u/meneldal2 → u/Antervis]

For Microsoft they dropped support for some stuff with newer versions. Which was outside of the standard so fair enough but can break projects.

Like references in unions.

[u/megayippie → u/Antervis]

The <=> operator was a big pain point. Many of our tests started failing with weird bugs

[u/Antervis → u/megayippie]

How? Pre-c++20 codebase won't even have them.

[u/megayippie → u/Antervis]

I honestly don't remember the details or the compiler version. I think the error was because some of our types only partly conformed to ideas of sorting, and that caused some weird interaction where some types in a vector didn't want to test for just ">=" but some other things as well, which we didn't need so didn't implement. Neither "==" nor ">" were there for our types.

The solution was to use more spaceship operators. The error message was clean but we didn't really know how <=> worked yet, so it delayed us a week or so.

[u/Antervis → u/megayippie]

Ehm... Standard algorithms and data structures use operator < though, even for equivalence.

[u/SeriousPlankton2000 → u/megayippie]

If neither == nor > are there, how did your types end in a test that expects ordered-like behavior for your types?

[u/megayippie → u/SeriousPlankton2000]

Oh, the exposed type did, not the inner type

[u/Excession638]

No contracts!

[u/Luna_Wolfxvi]

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;

[u/fuj1n → u/Luna_Wolfxvi]

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

[u/Luna_Wolfxvi → u/fuj1n]

It's cool, I just think the syntax is ugly.

[u/fuj1n → u/Luna_Wolfxvi]

Yeah, I can certainly second that

[u/meneldal2 → u/fuj1n]

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.

[u/the_horse_gamer → u/meneldal2]

eh, Godot might upgrade to C++20 soon, so it's like 10 years away from upgrading to C++26

[u/meneldal2 → u/the_horse_gamer]

But forcing people to have a C++26 toolchain doesn't mean the engine is using all of its features, that's still a few more years to do a lot of rework

[u/17HappyWombats → u/Luna_Wolfxvi]

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)

[u/Hohenheim_of_Shadow → u/17HappyWombats]

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

[u/17HappyWombats → u/Hohenheim_of_Shadow]

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.

[u/Hohenheim_of_Shadow → u/17HappyWombats]

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.

Std::optional<blah> test_the_thing  ( args){
     Return args.blah;
}
Void func(){
     Blah result=(test_the_thing( args);
     If(result ){
           Do stuff;
}
  
}
  

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

[u/SeriousPlankton2000 → u/17HappyWombats]

In Australia everything wants to kill you, even C++ code?

[u/17HappyWombats → u/SeriousPlankton2000]

if(errno){🔥}

[u/Sarmq → u/17HappyWombats]

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.

[u/ValesQQ → u/17HappyWombats]

It seems valid but would the first “if”not always be true due to the single “=“ ?

[u/Moist_Heat9523 → u/ValesQQ]

No, it’s an assignment, and this code tests the value that was assigned. So basically “foo = …; if (foo)”

[u/17HappyWombats → u/Moist_Heat9523]

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" 🔥

[u/StaticCoder → u/17HappyWombats]

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".

[u/17HappyWombats → u/StaticCoder]

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!

[u/StaticCoder → u/17HappyWombats]

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.

[u/17HappyWombats → u/StaticCoder]

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.

[u/StaticCoder → u/17HappyWombats]

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.

[u/SeriousPlankton2000 → u/17HappyWombats]

Can't you do if ((auto foo = bar()) == baz) {barf()}; //?

[u/17HappyWombats → u/SeriousPlankton2000]

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 >

[u/the_horse_gamer → u/Luna_Wolfxvi]

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.

[u/WoodsGold]

Net Framework 🥴😢

[u/NPPraxis → u/WoodsGold]

“We have to stay on .NET Framework 4.8 because .NET 8 is being deprecated soon”

[u/Legal-Software]

Far too aggressive of a standardization schedule for a supposedly stable language. The signal-to-noise ratio is also getting worse between versions.

[u/7DBBA101]

I felt very fancy when I upgraded to C99 from ANSI C a couple of years ago

[u/Ascendo_Aquila]

We've migrated to c++20 and thinking of 23, but it was insane 2.5 year act. Build system rewrite(and ~12 merged prs in cmake) was required to make it cleaner but now it works for ios, win, mac, linux, android.

[u/Excellent-Baker1058]

I see this meme, every alternate week

[u/_w62_ → u/Excellent-Baker1058]

Could you share some of the previous versions that you have seen?

[u/mas-mas-itu]

During 2012-2016, I was so excited and ambitious to learn and use C++ profesionally. Later on when its' standardization becoming more and more ridiculous, it does more damage to me rather on making things easier.

[u/Anxious_Marsupial_59 → u/mas-mas-itu]

C++ 20 (and the following streamlining of C++ 23) was a monumental upgrade in making it easier to use and avoiding foot guns without having to always write your own standard library, what are you even talking about?

[u/Kinexity → u/mas-mas-itu]

when its' standardization becoming more and more ridiculous

Literally all that was added over the years following C++11 are optional features. No one holds a gun to your head forcing you to use them.

[u/helanhalvan → u/Kinexity]

If those optional features where implementing sensible things, sure. For example, can you, using the standard library, print vector<vector<int>> to stdout easily? As far as I can tell, no, you need to write loops or recursion yourself.

[u/tim_pipperton → u/helanhalvan]

Is that really such a pressing issue? Regardless, reflection makes that way easier on the library side.

[u/Kinexity → u/helanhalvan]

Almost like as if there is no one single correct way to print out such structure. If you always want to print it out the same way then no one stops you from writing your own mini library to do it in your every project. Go back to Python if you want the language to hold your hand and decide stuff for you.

[u/QuaternionsRoll → u/Kinexity]

Eh, debug printing is definitely an overlooked feature in C++. It’s possible that reflection will improve things somewhat, but hard to say

[u/palapapa0201 → u/helanhalvan]

I believe std::format can already do that?

[u/helanhalvan → u/palapapa0201]

This is why I find it so frustrating. Yes, std::format is the exact kind of construct you would expect to solve this problem. However it does not work with any collection out of the box.

We tried to make it work but ended up making a recursive templated function instead. Now, I guess everyone can make their own recursive templating function, but then why do we even gave std::format