Migrating codebase to C++

[onlined]

Hi all,
I am currently working on #854, it is my first (hopefully not last) PR to this repo. While I was working on it, I realized that there is some convention for namespacing and there is a class hierarchy starting with Object struct. To me, it seems like C++ remove most of the boilerplate here. And probably it will remove the need for most of the utility functions in XUtils.c.

So, I have some questions to maintainers:

• Was this subject (migrating some part or all of the codebase to C++) discussed before? If yes, what was the conclusion?
• Would you be OK with going to C++? Of course it wouldn't be completed in one single PR, but small by small it can be handled.
• Are there any blockers for C++, other than maintainers' personal preferences (I don't imply they don't prefer C++)?

[BenBE]

• Was this subject (migrating some part or all of the codebase to C++) discussed before? If yes, what was the conclusion?

It hasn't been discussed before, but given most of the OOP features we currently use, there's not much advantage of such a migration just for the sake of using C++. And while there are some advantages in C++, that would make several code places much more convenient (RAII for memory buffers, ref counting), there's IMHO not much reason to do such a migration.

There has been quite a lot of cleanup going on since September 2020 when the current group of people maintaining the code found together, but there was not a lot of incentive to change the OOP part as it's implementation is mostly idiomatic and close to what you'd expect in a plain C codebase. Also the namespacing you see is common for larger C projects; compared to other projects even quite thorough and consistent.

• Would you be OK with going to C++? Of course it wouldn't be completed in one single PR, but small by small it can be handled.

While I know C++ quite well and could handle it just fine, I doubt the benefits for the amount of work for such a migration isn't compelling enough. In particular: C++ has the disadvantage that even simple projects tend to compile forever compared to similar code written in plain C alone.

• Are there any blockers for C++, other than maintainers' personal preferences (I don't imply they don't prefer C++)?

The intention with htop has been to be runnable on any system for which you find a suitable C99-capable compiler. The equivalent on C++ would imply using at least C++11 if you're not sadist or otherwise eager to experience pain. This would break compatibility with some older platforms that we currently run on even if not actively maintained as such.

[onlined]

If it was OK except the effort involved, I would've offered to do it on my own.

The intention with htop has been to be runnable on any system for which you find a suitable C99-capable compiler. This would break compatibility with some older platforms that we currently run on even if not actively maintained as such.

I could have discussed if the only argument were that it's not worth it, but this seems like a strict deal-breaker. No further questions, your honor 😄

[fasterit]

As per discussion with BenBE we would like to migrate htop to Rust.

[Explorer09]

Excuse me, where is the discussion of migrating htop to Rust anyway? Although I'm not familiar to Rust, the memory safety feature of Rust looks convincing for htop to migrate to. (I actually tried to write my C code defensively, inspired by Rust's code style.) I don't think C++ is ideal for htop considering the little OOP benefits vs. the much more complexity of the language. Just my personal opinion.

[BenBE]

I love those many volunteers who want to rewrite everything …

It's not as if you just sprinkle some magic dust onto your code and have it be valid $anyLanguage, but rather you'll have to put in some effort. And this effort should be less about translating one syntax into another, but to transform the general structure of the code. And this is where language apologists fail to see that each language has its own set of problems, despite the set of benefits readily advertised.

So while memory safety is a desirable feature to have, I don't think that's the only thing we should look out for. Like having a well-defined FFI for libraries you need to use and such. And in that respect, you don't gain anything from e.g. Rust: actually you loose any guarantee altogether about your code. While Rust guarantees correctness within all safe parts of your code, it can't make any such guarantee for anything originating from a FFI. So while you may think your memory is always well-behaved, it actually isn't. Even worse: Checks that normally would make sense to include, are removed due to the assumption they could never hit. It thus takes just one issue in some non-Rust library to mostly invalidate most of your "safe" code's assumptions about the world. The same issue can appear with C and C++ in a similar fashion, but would there be an active oversight, instead of something "optimized away because could never be" …

Also I kinda hate to break it, but @fasterit was making a joke about Rust (based on some side-channel comment from me): Just because everyone is riding the hype train and rewriting everything in $thatFancyNewLanguage doesn't mean it's practical for everyone and everything. Furthermore, the backwards compatibility argument against C++ applies just the same for Rust and many other of the hyped languages …

[fasterit]

Thanks to everybody taking part in this! Closing until the next iteration of "favourite-language-of-the-week" comes up.
/DLange