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

In Defense of C++

dayvster.com

Post reply on HN
Print view View original

221–230 of 470 posts

Re: In Defense of C++

#221

Post by imor80 »

alkonaut wrote: post #198

> Yes, C++ can be unsafe if you don’t know what you’re doing. But here’s the thing: all programming languages are unsafe if you don’t know what you’re doing. I think this is one of the worst (and most often repeated arguments) about C++. C and C++ are inherently unsafe in ways that trip up _all_ developers even the most seasoned ones, even when using ALL the modern C++ features designed to help make C++ somewhat safe…

There are two levels on which this argument feels weak:

* The author is confusing memory safety with other kinds of safety. This is evident from the fact that they say you can write unsafe code in GC languages like python and javascript. unsafe != memory unsafe. Rust only gives you memory safety, it won't magically fix all your bugs.

* The slippery slope trick. I've seen this so often, people say because Rust has unsafe keyword it's the same as c/c++. The reason it's not is because in c/c++ you don't have any idea where to look for undefined behaviour. In Rust at least the code points you to look at the unsafe blocks. The difference is of degree which for practial purposes makes a huge difference.

Re: In Defense of C++

#222

Post by nxobject »

jcelerier wrote: post #208
ryao wrote: post #110

Earlier quoted context omitted.

I feel like C++ is a bunch of long chains of solutions creating problems that require new solutions, that start from claiming that it can do things better than C. Problem 1: You might fail to initialize an object in memory correctly. Solution 1: Constructors. Problem 2: Now you cannot preallocate memory as in SLAB allocation since the constructor does an allocator call. Solution 2: Placement new Problem 3: Now the ty…

But the c++ solution is transparent to the user. You can write entire useful programs that will use std:: containers willy-nilly and all propagate their allocators automatically and recursively without you having to lift a finger because all the steps you've mentioned have been turned in a reusable library, once.

I'd file that in the category of "what I can't recreate, I can't understand".

Re: In Defense of C++

#224

Post by pjmlp »

vlovich123 wrote: post #132
worik wrote: post #116

Earlier quoted context omitted.

None of that is a problem There are a lot of problems, but having to carefully construct the build environment is a minor one time hassle. Then repeated foot guns going off, no toes left, company bankrupt and banking system crashed, again

> There are a lot of problems, but having to carefully construct the build environment is a minor one time hassle. I've observed the existence in larger projects of "build engineers" whose sole job is to keep the project building on a regular cadence. These jobs predominantly seem to exist in C++ land.

I have been "build engineer" across many projects, regardless of the set of programming languages being used, this is not specific to C++.

Re: In Defense of C++

#225

Post by silon42 »

ergonaught wrote: post #167

It's a fine post except for this: > Countless companies have cited how they improved their security or the amount of reported bugs or memory leaks by simply rewriting their C++ codebases in Rust. Now is that because of Rust? I’d argue in some small part, yes. Just delete this. Even an hour's familiarity with Rust will give you a visceral understanding that "Rewrites of C++ codebases to Rust always yield more memory-s…

Yeah... if you don't have 100% feature test coverage (and more) you will almost certainly lose features (aka cause bugs)

Re: In Defense of C++

#226

Post by dayvster »

digitalPhonix wrote: post #219
dayvster wrote: post #214

Earlier quoted context omitted.

This is true and I will concede this point. Appreciate your feedback! However if I may raise my counter point I like to have a rule that C++ should be written mostly as if you were writing C as much as possible until you need some of it's additional features and complexities. Problem is when somebody on the team does not share this view though, that much is true :)

> However if I may raise my counter point I like to have a rule that C++ should be written mostly as if you were writing C as much as possible until you need some of it's additional features and complexities. How do you define “need” for extra features? C and C++ can fundamentally both do the same thing so if you’re going to write C style C++, why not just write C and avoid all of C++’s foot guns?

Excellent question, I guess it depends on the team mostly how they define which features they need and which are better avoided.

As for why not just go for C. You can write C++ fully as if it were C, you can not ever turn C into C++

Re: In Defense of C++

#227

Post by jbstack »

dayvster wrote: post #214
jamesdhutton wrote: post #206

> You can write simple, readable, and maintainable code in C++ without ever needing to use templates, operator overloading, or any of the other more advanced features of the language. Maybe you can do that. But you are probably working in a team. And inevitably someone else in your team thinks that operator overloading and template metaprogramming are beautiful things, and you have to work with their code. I speak fr…

This is true and I will concede this point. Appreciate your feedback! However if I may raise my counter point I like to have a rule that C++ should be written mostly as if you were writing C as much as possible until you need some of it's additional features and complexities. Problem is when somebody on the team does not share this view though, that much is true :)

Counter-counter point: if you're going to actively avoid using the majority of a language's features and for the most part write code in it as if it were a different language, doesn't that suggest the language is deeply flawed?

(Note: I'm not saying it is deeply flawed, just that this particular way of using it suggests so).

Re: In Defense of C++

#228

Post by nly »

alkonaut wrote: post #201
blindseer wrote: post #190

I would really like to see more people who have never written C++ before port a Rust program to C++. In my opinion, one can argue it may be easy to port initially but it is an order of magnitude more complex to maintain. Whereas the other around, porting a C++ program to Rust without knowing Rust is challenging initially (to understand the borrow checker) but orders of magnitude easier to maintain. Couple that with e…

I'm a developer since 30 years. I program C#, Rust, Java, some TS etc. I can probably go to most repositories on github and at least clone and build them. I have failed - repeatedly - to build even small C++ libraries despite reasonable effort. And that's not even _writing any C++_. Just installing the tooling around CMake etc is completely Kafkaesque. The funniest thing happened when I needed to compile a C file as…

Most of the C++ world has standardized on CMake.

I work on large C++ projects with 1-2 dozen third party C and C++ library dependencies, and they're all built from source (git submodules) as part of one CMake build.

It's not easy but it is fairly simple.

Re: In Defense of C++

#229

Post by jandrewrogers »

oytis wrote: post #209
jandrewrogers wrote: post #146

Earlier quoted context omitted.

I think this is a case of two distinct populations being inappropriately averaged. There are many high-level C++ applications that would probably be best implemented in a modern GC language. We could skip the systems language discussion entirely because it is weird that we are using one. There are also low-level applications like high-performance database kernels where the memory management models are so different th…

Rust is a systems programming language, it was absolutely designed with the second use case in mind.

This is true. But it has some weird gaps that make it difficult to express fundamental things in the low-level systems world without using a lot of “unsafe”. Or you can do it safely and sacrifice a lot of performance. I am a fan of formal verification and use it quite a lot but Rust is far more restrictive than formal verification requires.

Rust is a systems language but it is uncomfortable with core systems-y things like DMA because it breaks lifetime and ownership models, among many other well-known quirks as a systems language. Other verifiable safety models exist that don’t have these issues. C++, for better or worse, can deal with this stuff in a straightforward way.

Re: In Defense of C++

#230

Post by imtringued »

jlarocco wrote: post #136
duped wrote: post #57

Earlier quoted context omitted.

Consider that to do this you must: - Use a build system like make, you can't just `c++ build` - Understand that C++ compilers by default have no idea where most things are, you have to tell them exactly where to search - Use an external tool that's not your build system or compiler to actually inform the compiler what those search paths are - Oh also understand the compiler doesn't actually output what you want, you…

It's really not that big of a deal once you know how it works, and there are tools like CMake and IDEs that will take care of it. On Windows and OSX it's even easier - if you're okay writing only for those platforms. It's more difficult to learn, and it seems convoluted for people coming from Python and Javascript, but there are a lot of advantages to not having package management and build tooling tightly integrated…

I used to write a lot of C++ in 2017. Now in 2025 I have no memory of how to do that anymore. It's bespoke Makefile nonsense with zero hope of standardization. It's definitively something that doesn't grow with experience. Meanwhile my gradle setups have been almost unchanged since that time if it wasn't for the stupid backwards incompatible gradle releases.
Post reply on HN