321–330 of 356 posts
[flagged]
That just ports all the problems to C... You're better off incrementally rewriting it in modern C++. Replace those raw pointers with references or smart pointers!
This is all wrong.
>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…
The project size is probably a lot smaller than what most people are working on though, and I have a fast CPU and NVME disk, but it's definitely possible to do!
I'm not sure about the fuzzer part though.
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! ;)
That's probably reading uninitialized memory. You can get away with that for a VERY long time, until you can't. See the earlier valgrind recommendation. But that sort of report isn't a deep mystery, it's just a specific class of bug. Given the description, you've got a pretty good idea of what you're looking for.
For a long-ago example: I worked on a project that had an optimizer that used time-bounded simulated annealing to optimize. No two builds ever the same. It was "great".
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…
Software is arts and crafts :)
For those that dont know, Arts and Crafts movement in the states is known for some pretty interesting pottery that was produced at scale.
https://excellentjourney.net/2015/03/04/art-fear-the-ceramic...
Earlier quoted context omitted.
That's probably reading uninitialized memory. You can get away with that for a VERY long time, until you can't. See the earlier valgrind recommendation. But that sort of report isn't a deep mystery, it's just a specific class of bug. Given the description, you've got a pretty good idea of what you're looking for.
... until the cause is really and truly a non-deterministic build. Trust me, been there. For a long-ago example: I worked on a project that had an optimizer that used time-bounded simulated annealing to optimize. No two builds ever the same. It was "great".
Earlier quoted context omitted.
So you saw a post about C++, it didn’t mention “Rust” once, mentioned “memory safe” languages which there are dozens of, and yet found a way to shoehorn in a dismissive comment about a meme. Nice. We’ve reached the rewrite-in-rust meme stage of questioning whether the author is a nefarious crypto-Rust programmer in lieu of not being able to complain about it (since it wasn’t brought up!).
(author actually shows up to advocate for rust)
> 3. Make the project enter the 21st century by adding CI, linters, fuzzing, auto-formatting, etc I would break this down: a) CI - Ensure not just you can build this, but it can be built elsewhere too. This should prevent compile-based regressions. b) Compiler warnings and static analysers - They are likely both smarter than you. When it says "warning, you're doing weird things with a pointer and it scares me", it's…
> The last step of an inherited C++ codebase is to rewrite it in a memory safe language Simply getting rid of any actually memory unsafe C++ and enforcing guidelines will do this for you in the C++ codebase. "Rewrite it in X" only adds complexity because it's the flavour of the month as you said in your comment. Author is already doing the work of rewriting large chunks of the codebase in C++, they may as well follow…
If you have a codebase with lots and lots of tests, you are not in a bad place. Remember legacy means a codebase that works and solved and still solves problems over decades. In a sense,a successfull software project implies it will be marked as legacy. Always prefer legacy over Hype.
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…
I've had issues with Dockerfiles not building anymore due to changes in the package registry, but it was like 1-2 times out of 1000 of times I used docker.
> Get the build working on your machine Nope. Make a portable/virtualized env, and make it build there. That way it'll build on you machine, in the CI pipeline, on your co-worker's machine, etc etc. > linters, fuzzing, auto-formatting No, for at least two reasons: 1) Too risky, you change some "cosmetic" things and something will quietly shift in the depths, only to surface at the worst possible time 2) Stylistic ref…