Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

gaultier.github.io

Post reply on HN
Print view View original

281–290 of 356 posts

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

#281

Post by basicallybones »

hobofan wrote: post #258
eschneider wrote: post #89

Some good advice here, and some more...controversial advice here. After inheriting quite a few giant C++ projects over the years, there are a few obvious big wins to start with: * Reproducible builds. The sanity you save will be your own. Pro-tip: wrap your build environment with docker (or your favorite packager) so that your tooling and dependencies become both explicit and reproducable. The sanity you save will be…

> wrap your build environment with docker (or your favorite packager) so that your tooling and dependencies become both explicit and reproducable If you want explicitness and reproducibility please don't reach for Docker. Unless you take a lot of care, you will only get the most watered down version of reproducibility with Docker probably luring you into a false sense of security. E.g. pointing to mutable image tags…

A nice middle ground is using a tool like Google's Skaffold, which provides "Bazel-like" capabilities for composing Docker images and tagging them based on a number of strategies, including file manifests. In my case, I also use build args to explicitly set versions of external dependencies. I also pull external images and build base images with upgraded versions once, then re-tag them in my private repository, which is an easy-to-implement mechanism for reproducibility.

While I am in a Typescript environment with this setup at the moment, my personal experience that Skaffold with Docker has a lighter implementation and maintenance overhead than Bazel. (You also get the added benefit of easy deployment and automatic rebuilds.)

I quite liked using Bazel in a small Golang monorepo, but I ran into pain when trying to do things like include third-party pre-compiled binaries in the Docker builds, because of the unusual build rules convention. The advantage of Skaffold is it provides a thin build/tag/deploy/verify layer over Docker and other container types. Might be worth a look!

Kudos to the Google team building it! https://skaffold.dev

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

#282

Post by bluGill »

z_open wrote: post #236
bluGill wrote: post #136

Earlier quoted context omitted.

vector.at() is memory safe. You get a choice. Easy to ban [] if you cannot statically prove it is safe. C++11 isn't the most memory safe language, but C++11 is a lot safer than older versions, and C++23 is better yet. I'm expecting true memory safety in C++26 (time will tell), but it will be opt-in profiles which isn't ideal.

This is not idiomatic C++ in any C++ standard. You can also just replace vector with map so the brackets insert, but that isn't either.

Prefer at to [] is standard where I write C++. map is not standard because vector is almost always much faster random access in the real world (that is n is normally small enough that a linear search is faster than a binary search because of caching)

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

#283

Post by bluGill »

Night_Thastus wrote: post #206
bluGill wrote: post #134

Earlier quoted context omitted.

If it is C++ I wouldn't think about python in most cases. Rust should come to mind. Ada, or D are other options you sometimes hear about.

Is it possible to integrate any of those while allowing seamless debugging? IE, step right from one into another? I've yet to see that happen.

If nothing else my C++ debugger will see the functions of everything in Rust, D, or ada - it might be a mangled name but generally I can figure them out. Once you step into python the debugger is going to see the python runtime functions and you need to dig into them to figure out what of your functions you are running.

I have yet to figure out how to get any language other than C++ into my system so I can't say how well it works in the real world. Then again I work on an embedded system with real time controls so I can rarely use a debugger since as soon as I hit a breakpoints all my must happen at time X functions fail to run and the whole system fails in a few ms.

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

#284

Post by keepamovin »

TrackerFF wrote: post #279
keepamovin wrote: post #3

It's funny. My first step would be 0. You reach out to the previous maintainers, visit them, buy them tea/beer and chat (eventually) about the codebase. Learned Wizards will teach you much. But I didn't see that anywhere. I think the rest of the suggestions (like get it running across platform, get tests passing) are useful stress tests likely to lead you to robustness and understanding however. But I'd def be going…

I was once tasked with deploying a piece of software on a closed network (military), to run on a old custom OS - it wasn't a huge program, around 50k lines of code. I did encounter a bunch of bugs and problems underway, and wanted to reach out to the devs that wrote it - as it was customer made for my employer. Welp, turns out it was written by one guy/contractor, and that he had passed away a couple of years earlier…

Welp, you might have needed to consult a seance for that one.

Interesting point about the "author expiry" window. I was thinking about that today regarding something else:

Let's say in 20 years time, no database code has been updated for the last 20 years. And all the people who worked on it, can't remember anything about it. Yet, it still works.

That means that everyone who uses that database everyday, doesn't know how it works. They believe that it works, this belief is widespread. And the database providing results to queries, is a real thing. And it does work -- but nobody knows how.

This is common. I don't know in any detail how the MacBook I use works. But it does. I don't know how many things I use actually work. But they do work.

It seems the only difference, in the world of things that "work", and which most people who use them do not understand how they work, is that there are two classes of things: those things for which there is a widespread belief that they do work; and those things for which the belief that they work, is not widespread. But in either case, they work.

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

#285

Post by bluGill »

chx wrote: post #233
bluGill wrote: post #131

Earlier quoted context omitted.

I have been involved in a successful rewrite. It cost billions of dollars and many years when the code wasn't working so the old system was still in use. We also ended up bringing over some old code directly just to get something - anything - functional at all. For many years my boss kept the old version running on his desk because when there was a question that old system was the requirements. Today we only have to…

> because some new requirement came along that didn't fit our nice architecture. This is the thing. I was doing the event section of the website and it was the event. I mean, it was preposterous to even think of running multiple events. Fast forward a few years, the company is now many times the size after very rapid growth, has an office in the UK and now runs multiple events. Would you have made an architecture for…

When considering this question, I've designed for things knowing they would come and they never did. I've also designed for situations that did come, but 10 years later we discovered a significant downside that we didn't anticipate and so the seemingly non-elegant hacks would have been better.

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

#286

Post by zer00eyz »

otabdeveloper4 wrote: post #240
zer00eyz wrote: post #35

Earlier quoted context omitted.

>> It's a nice idea, but it's hard to do. One person is using VIM, another is using emacs, another is using QTCreator, another primarily edits in VSCode.. Trying to get everyone on the same page about all this is very, very hard. This is what's wrong with our industry, and it's no longer an acceptable answer. We're supposed to be fucking professional, and if a job needs to build a tool chain from the IDE up we need t…

> every single carpenter in the world should use the exact same make and model of saw, for, uh, professionalism reasons

Picture the crew that shows up to stick frame your house.

First guy: hand saw and impact driver... cut and screw Second guy: Power Saw, and hammer. Cut and nail. Third guy: Safety glasses and a Nail gun. Forth guy shows up: compressor, asks where the power is (none) and if he can use some tools.

It would not work. You dont build a CNC production line for parts with every CNC being unique. We dont let devs pick what their production server OS is, we dont let them choose random languages. Tooling matters.

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

#287

Post by eschneider »

reactordev wrote: post #180
eschneider wrote: post #151

Earlier quoted context omitted.

There was that time when I had to dump the roms off a 'test' MRI machine because that's the only version of the code they had, then decompiled it, and rewrite it from that. I think about that a lot now that I'm older and spend a fair bit of time in MRI machines...

Dang man that’s tough, at least you know they work ;)

Oh, we tested those a lot. Fun fact: you can see under the foil in scratch cards with those. Might, um, have something to do with "every card a winner" scratch cards no longer being a thing.

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

#288

Post by hawk_ »

hobofan wrote: post #258
eschneider wrote: post #89

Some good advice here, and some more...controversial advice here. After inheriting quite a few giant C++ projects over the years, there are a few obvious big wins to start with: * Reproducible builds. The sanity you save will be your own. Pro-tip: wrap your build environment with docker (or your favorite packager) so that your tooling and dependencies become both explicit and reproducable. The sanity you save will be…

> wrap your build environment with docker (or your favorite packager) so that your tooling and dependencies become both explicit and reproducable If you want explicitness and reproducibility please don't reach for Docker. Unless you take a lot of care, you will only get the most watered down version of reproducibility with Docker probably luring you into a false sense of security. E.g. pointing to mutable image tags…

> If you want explicitness and reproducibility please don't reach for Docker

Is it common in C++ builds to rely on the current O/S libraries instead of say making most dependencies explicit, close to full cross-compile? Do dependencies need to be pulled in using apt-get and not something like maven?

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

#289

Post by TrackerFF »

keepamovin wrote: post #284
TrackerFF wrote: post #279

Earlier quoted context omitted.

I was once tasked with deploying a piece of software on a closed network (military), to run on a old custom OS - it wasn't a huge program, around 50k lines of code. I did encounter a bunch of bugs and problems underway, and wanted to reach out to the devs that wrote it - as it was customer made for my employer. Welp, turns out it was written by one guy/contractor, and that he had passed away a couple of years earlier…

Welp, you might have needed to consult a seance for that one. Interesting point about the "author expiry" window. I was thinking about that today regarding something else: Let's say in 20 years time, no database code has been updated for the last 20 years. And all the people who worked on it, can't remember anything about it. Yet, it still works. That means that everyone who uses that database everyday, doesn't know…

Even more common in the world of industrial automation.

Lots of old early-gen PLCs from the 70s/80s still ticking, with no documentation and the techs/engineers/companies long gone.

We worked on one such PLC, around 3 decades old at the point, and it came down to probing I/O, reverse engineering the functionality.

But at some point, if there hasn't been enough legacy support, there comes a time where people just have to bite the bullet and re-build a system from the ground up - and integrate it in parallel with the old system running, until it can be removed completely.

Too bad many of the old and forgotten systems are still running and integral, so they get put inside a glass cage with "DON'T TOUCH!" warning sticker.

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

#290

Post by cesarb »

boolemancer wrote: post #193
groby_b wrote: post #188

Earlier quoted context omitted.

Often yes. Sometimes, no. You haven't enjoyed C++ until you get reports of the app intermittently crashing, and your build at the same version just won't. But yes, if the goal is "slap it all in a container", that's probably good and at least somewhat reproducible. We aren't Python here! ;)

> Often yes. Sometimes, no. You haven't enjoyed C++ until you get reports of the app intermittently crashing, and your build at the same version just won't. That's okay, it's probably just some bank in a random country that requires some software package to be installed, presumably in the interest of security, which injects a dll into every process on the machine and unsurprisingly has a bug which causes your process…

> some software package to be installed, presumably in the interest of security, which injects a dll into every process on the machine

You don't even have to get that far. Shell extensions (for file open or save dialogs) and printer drivers also introduce arbitrary DLLs to your processes. And some of them are compiled in an old version of IIRC Delphi or Turbo Pascal, which on the DLL startup code unconditionally changes the floating point control word to something which causes unexpected behavior in some framework you're using.

(We ended up wrapping all calls to file open or save or print dialogs with code to save and restore the floating point control word, just in case they had loaded one of these annoying DLLs.)

Post reply on HN