Live data from Hacker News

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

gaultier.github.io

151–160 of 356 posts

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

#151

Earlier quoted context omitted.

Step 0: reproducible builds (like you said) Step 1: run all tests, mark all the flaky ones. Step 2: run all tests under sanitizers, mark all the ones that fail. Step 3: fix all the sanitizer failures. Step 4: (the other stuff you wrote)

If we're going to visit the circles of hell, let's do it properly: Step -1: Get it under source control and backed up. Step -2: Find out if the source code corresponds to the executable. Which of the 7 variants of the source code (if any). Step -3: Do dark rituals over a weekend with cdparanioa to scrape the source code from the bunch of scratched cd's found in someone's bottom drawer. Bonus point if said person died…

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

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

#152
And I have at some point inherited 5000+ files long legacy PHP code. I had to write Python program to parse that insanity to look for particular patterns and report those for manual fixing or do it automatically if possible. The example would be database access. That single software used 5 different methods to access it.

So no. I would not call C++ any special in this regards.

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

#153

My first thing is usually: #0: Replace the custom/proprietary Hashmap implementation with the STL version. Once upon a time, C++ academics brow beat the lot of us into accepting Red-Black-Tree as the only Map implementation, arguing (in good faith yet from ignorance) that the "Big O" (an orgasm joke, besides others) worst case scenario (Oops, pregnancy) categorized Hash Map as O(n) on insert, etc. due to naieve imple…

It’s unfortunate that the hashmap picked by the standards comittee (std::unordered_map) is both awkwardly named and not very performant. Still probably better than whatever was hacked up in 1998, but nowadays you can do much better for any case where performance actually mattered. Note, still don’t roll your own, but there’s plenty of options from e.g. Abseil or Facebook’s Folly.

I worked on a project a few years ago where all data was stored in hashmaps. Just swapping out std::unordered map for an optimized implementation of a robin hood hash map increased performance by something like 2x and cut memory usage in half on many larger test cases.

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

#154

> Rewrite in a memory safe language? like c++11 and later?

Oops, shared_ptr circular reference.

Oops, null smart pointer.

Oops, UB made my reference null.

Oops, invalidated iterator.

Oops, aliased pointers.

Oops, race condition.

Oops, recursion.

Oops, moved-from object is partially formed.

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

#156

>worry not, by adding std::cmake to the standard library and you’ll see how it’s absolutely a game changer I'm pretty sure my stomach did somersaults on that. But as for the advice: >Get out the chainsaw and rip out everything that’s not absolutely required to provide the features your company/open source project is advertising and selling I hear you, but this is incredibly dangerous. Might as well take that chainsaw…

> It's a nice idea, but it's hard to do. One person is using VIM... The things the author listed there are commonly not IDE integrated. I've never seen a C++ development environment where cpplint/clang-tidy and fuzzers are IDE integrated, they're too slow to run automatically on keystrokes. Auto-formatting is the only one that is sometimes integrated. All of this stuff you can do from the command line without caring…

Clangd will happily run clang-tidy as part of completion/compile-as-you-type/refactor/auto independent.

On the editor/IDE of your choose.

I wouldn't call it fast, but it is quite usable.

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

#157
post #81

Earlier quoted context omitted.

That's why I asked what the bar was? If Google is writing shitty C++ even with the world's eyes on their code base, who is doing it right? No one writing anything sufficiently complicated that's for sure.

However you feel about this issue: It's pretty widely known that google is bad at c++. Most codebases will be of significantly higher quality.

>It's pretty widely known that google is bad at c++

No, it's not. This is literally the first time I hear about this. Do you have any sources to support your claim, especially in light of the fact that Google has written and contributed to some of the largest and most important C++ codebases in existence?

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

#158

Earlier quoted context omitted.

If we're going to visit the circles of hell, let's do it properly: Step -1: Get it under source control and backed up. Step -2: Find out if the source code corresponds to the executable. Which of the 7 variants of the source code (if any). Step -3: Do dark rituals over a weekend with cdparanioa to scrape the source code from the bunch of scratched cd's found in someone's bottom drawer. Bonus point if said person died…

I was assuming it already had unit and system tests with decent coverage. I forgot how bad stuff gets. Maybe VM clones of various users too, and recordings of their work flows?

I'm always careful to dump the bash history as soon as I get access to a machine involved in a legacy project.

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

#160

Good points, but this is not something you can solve with a recipe. Investigate, talk to people and make sure you are solving actual problems and prioritizing the right tasks. This is an extremely crucial step that you must do first: familiarize yourself with the system, its uses and the reasons it works like it does. Most things will be there for a reason, even if not written to the highest standard. Other parts mig…

I did not find Chesterton's fence, and was sad. The very first thing to do with a new codebase is don't touch anything until you understand it, and then don't touch anything until you realize how mistaken your understanding was.

[deleted]
Post reply on HN