You've just inherited a legacy C++ codebase, now what? • Hacker News Board

Re: You've just inherited a legacy C++ codebase, now what?

#351

Post by groby_b » Sun, Mar 03, 2024, 7:17 PM UTC

vlovich123 wrote: post #332

groby_b wrote: post #183

Earlier quoted context omitted.

Step 0 sounds so easy. Until you realize __time__ exists. Then you take that away, and you find out that some compiler heuristics might not be deterministic. Then you discover -frandom-seed - and go ballistic when you read "but it should be a different seed for each sourcefile" Then you figure out your linker likes emitting a timestamp in object files. Then you discover /Brepro (if you're lucky enough to use lld-link…

frandom-seed is not quite so bad. > The string can either be a number (decimal, octal or hex) or an arbitrary string (in which case it’s converted to a number by computing CRC32). > The string should be different for every file you compile. So basically just pass in the project relative path to the file into random-seed and you'll be fine. It's a shame the guidance doesn't explain why the string should be different b…

Oh, yes, all of those are fixable. It's just a permanent reminder of a lot of bad decisions along the way.

And it wouldn't be C++ if a large chunk of the bad decisions wasn't rooted in the preprocessor.

Re: You've just inherited a legacy C++ codebase, now what?

#352

Post by planede » Mon, Mar 04, 2024, 10:32 AM UTC

keepamovin wrote: post #349

planede wrote: post #263

Earlier quoted context omitted.

You mean the guys the company laid off last week?

Ouch, yeah. I appreciate your topicality with this comment given the recent saga of tech layoffs. Much luck to you if you're in that experience right now!! Say you got fired form a S.Eng job at 350K yearly and some young grunt on 165K slid into your DMs and wanted to meet to chat. What would make you agree to that? I think it's unlikely, but perhaps if they reflected to you all the things you already thought were stu…

> What would make you agree to that?

Money. Charging the higher end of typical consulting rates. That's your competition.

It's OK to want to help the young engineers, it doesn't mean that you shouldn't charge the company while you are at it. It would be foolish to do it for free, you effectively wouldn't do it for free even if you still worked there.

Re: You've just inherited a legacy C++ codebase, now what?

#353

Post by __d » Tue, Mar 05, 2024, 2:48 AM UTC

adastra22 wrote: post #238

__d wrote: post #229

Earlier quoted context omitted.

That's a feature! New warnings added to new compiler versions can identify problems that weren't previously detected. You _want_ those to -Werror when they happen, so you can fix them if they need it. Changing a compiler version is a task that has to be resourced appropriately. Part of that is dealing with any fallout like this. Randomly updating your compiler is just asking for trouble.

It is certainly not a feature because it make all infrastructure including just regular old checkout-and-build workflows break for historical versions of the code. It’s so annoying to have to checkout an older version and then have to go disable -Wall -Werror everywhere just to get the damn thing to build. Keep master clean of any warnings, for sure. But don’t put it straight into the build system defaults.

Old code built with a different compiler isn't something that should be just dropped into production.

If you want to do this, you should version the build infrastructure as well as the code.

Otherwise, it's important to look at the new warnings: they might reflect changes in the generated code. Putting -Werror in your default build settings makes sure this happens before something blows up in prod.

Re: You've just inherited a legacy C++ codebase, now what?

#354

Post by account42 » Wed, Mar 06, 2024, 9:16 AM UTC

pizlonator wrote: post #168

jchw wrote: post #116

Earlier quoted context omitted.

I agree that this helps, although I still think that in general, the default build should never do -Werror, since people may use other toolchains and it shouldn't surprise-break downstream (I'm pretty sure this is a problem Linux distros struggle with all the time..) If it does it only in your fully reproducible CI, then it should be totally fine, of course.

I think this depends on a bunch of stuff. - Who are the consumers of the source code, i.e. who will ever check it out and build it? Sometimes, it's just one person. Sometimes, it's a team of engineers. In that case, -W -Werror is fine. - How does a warning being reported make the engineers on the team feel? If the answer is, "Hold my beer for five minutes while I commit a fix", then -W -Werror might be the right call…

I don't really see the point of -Werror for projects where I am the only developer because I can just fix warnings before committing but things like errring on unused variables are counterprodutctive when you are just trying something out in your local checkout. In my opinion the only place -Werror makes sense is in CI - and there you can just as well have the CI fail on warnings so you get all of them in the output and not just miss out later ones that were never produced because the build was aborted due to -Werror. CI also allows more nuanced approaches like not allowing new warnings of some types while you still deal with fixing existing ones.

Re: You've just inherited a legacy C++ codebase, now what?

#355

Post by dieortin » Wed, Mar 06, 2024, 10:54 PM UTC

jpc0 wrote: post #335

dieortin wrote: post #327

Earlier quoted context omitted.

How would you get rid of any memory unsafe C++? Isn’t that just another way of saying “do not make mistakes”?

The same way you do it in rust, use wrappers for all memory allocation. C++ has had RAII forever, since C++11(2024 btw now) have actually good wrappers, Box = std::unique_ptr, whatever the ref counter version is = std::shared_pte. Do the other things he already said to do, ie clang-tidy with the correct rule will warn/error on any raw pointer usage. You don't need to "not make mistakes". If you never use raw pointers…

Using smart pointers solves some problems, sure, but it does not make C++ memory safe.

Re: You've just inherited a legacy C++ codebase, now what?

#356

Post by ralphist » Thu, Mar 07, 2024, 5:04 PM UTC

cratermoon wrote: post #219

eropple wrote: post #130

Earlier quoted context omitted.

> neither does the organization have to deal with the endless yak shaving over brace style and tool choice I hear you, but an organization that fears this, instead of Just Pick Something And Deal With It, is an organization that probably doesn't have the right people in it to succeed at any task more arduous than that.

Conversely, and organization that imposes arbitrary choices and isn't capable of allowing people do use the tools they know best probably doesn't attract the best people. There are many different kinds of hammers, and making everyone who uses hammers use the same kind is, to say the least, counter productive.

I don't imagine the best people crying at being forced to use VSCode instead of CLion.