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

211–220 of 470 posts

Re: In Defense of C++

#211

Post by IshKebab »

jandrewrogers wrote: post #146
MBCook wrote: post #104

Earlier quoted context omitted.

> Just using Rust will not magically make your application safe; it will just make it a lot harder to have memory leaks or safety issues. Even if we take this claim at face value, isn’t that great ? Memory safety is a HUGE source of bugs and security issues. So the author is hand-waving away a really really good reason to use Rust (or other memory safe by default language). Overall I agree this seems a lot like “I li…

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…

> It is no accident that these have proven to be memory safe in practice; they would not be usable if they weren’t.

Can't agree there. Why wouldn't they be usable if they weren't memory safe?

Can you give me an example of this mythical "memory safe in practice" database?

Not Postgresql at least: https://www.postgresql.org/support/security/

Re: In Defense of C++

#212

Post by jcelerier »

monkeyelite wrote: post #169
jandrewrogers wrote: post #139

Earlier quoted context omitted.

You need something like std::launder in any systems language for certain situations, it isn’t a C++ artifact. Before C++ added it we relied on undefined behavior that the compilers agreed to interpret in the necessary way if and only if you made the right incantations. I’ve seen bugs in the wild because developers got the incantations wrong. std::launder makes it explicit. For the broader audience because I see a lot…

Do you see all the concepts you had to describe here? > Unless you are a low-level systems developer it is unlikely to affect you. Making new data structure is common. Serializing classes into buffers is common.

> Making new data structure is common. Serializing classes into buffers is common.

You don't want std::launder for any of that. If you must create object instances from random preexisting bytes you want std::bit_cast or https://en.cppreference.com/w/cpp/memory/start_lifetime_as.h...

Re: In Defense of C++

#213

Post by oytis »

IshKebab wrote: post #20

Terrible article. > you can write perfectly fine code without ever needing to worry about the more complex features of the language Not really because of undefined behaviour. You must be aware of and vigilant about the complexities of C++ because the compiler will not tell you when you get it wrong. I would argue that Rust is at least in the same complexity league as C++. But it doesn't matter because you don't need…

Fallacy of grey, now I know how is it is called. I see it used by C++ programmers to dismiss Rust a lot.

Nobody claims that Rust is a perfect language, the argument is that Rust is a better language than C++.

Re: In Defense of C++

#214

Post by dayvster »

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 :)

Re: In Defense of C++

#215

Post by jcelerier »

Night_Thastus wrote: post #115
thelittlenag wrote: post #101

Earlier quoted context omitted.

I'm old enough to recall when boost first came out, and when it matured into a very nice library. What's happened in the last 15 years that boost is no longer something I would want to reach for?

C++11 through 17 negated a lot of its usefulness - the standard library does a lot of what Boost originally offered. Alternative libraries like QT are more coherent and better thought out.

I use boost and Qt but completely disagree. Every new version of boost brings extremely useful libraries that will never be in std: boost.pfr was a complete game changer, boost.mp11 ended the metaprogramming framework wars, there's also the recently added support for MQTT, SQL, etc. Boost.Beast is now the standard http and websocket client/server in c++. Boost.json has a simple API and is much more performant than nlohmann. Etc etc.

Re: In Defense of C++

#216

Post by fithisux »

charlieflowers wrote: post #118
fithisux wrote: post #6

"Rust shines in new projects where safety is the priority, while C++ continues to dominate legacy systems and performance-critical domains." the truth

> "while C++ continues to dominate ... performance-critical domains" Why performance-critical domains? Does C++ have a performance edge over Rust?

That is what the article says.

Re: In Defense of C++

#217

Post by jandrewrogers »

IshKebab wrote: post #211
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…

> It is no accident that these have proven to be memory safe in practice; they would not be usable if they weren’t. Can't agree there. Why wouldn't they be usable if they weren't memory safe? Can you give me an example of this mythical "memory safe in practice" database? Not Postgresql at least: https://www.postgresql.org/support/security/

Database kernels have some of the strictest resource behavior constraints of all software. Every one I have worked on in vaguely recent memory has managed memory. There is no dynamic allocation from the OS. Many invariants important to databases rely on strict control of resource behavior. An enormous amount of optimization is dependent on this, so performance-engineered systems generally don’t have issues with memory safety.

Modern database kernels are memory-bandwidth bound. Micro-managing the memory is a core mechanic as a consequence. It is difficult to micro-manage memory with extreme efficiency if it isn’t implicitly safe. Companies routinely run formal model checkers like TLA+ on these implementations. It isn’t a rando spaffing C++ code.

I’ve used PostgreSQL a lot but no one thinks of it as highly optimized.

Re: In Defense of C++

#218

Post by okanat »

moefh wrote: post #170
okanat wrote: post #99

Earlier quoted context omitted.

Nice thing about Rust is not that you cannot write such code, it is you know exactly where you used peaky memory or re-interpreted something as a unsigned integer or replaced your program stack with something else. All of such cases require unsafe blocks in Rust. It is a screaming indicator "here be dragons". It is the do not press this red button unless you intend to. In C and C++ no such thing exists. It is walking…

> All of such cases require unsafe blocks in Rust. It's true that Rust makes it much harder to leak memory compared to C and even C++, especially when writing idiomatic Rust -- if nothing else, simply because Rust forces the programmer to think more deeply about memory ownership. But it's simply not the case that leaking memory in Rust requires unsafe blocks. There's a section in the Rust book explaining this in deta…

My comment is more of an answer to this

> You're gonna be dealing with issues involving "peaky" memory usage e.g. erroneously persistent references to objects

I use Rust in a company in a team who made the C++ -> Rust switch for many system services we provide on our embedded devices. I use Rust daily. I am aware that leaking is actually safe.

Re: In Defense of C++

#219

Post by digitalPhonix »

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 :)

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

Re: In Defense of C++

#220

Post by jillesvangurp »

C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. Over time, and in larger groups of people that always fails. People just aren't that disciplined and they get overconfident of their own skills (or level of discipline). Decades of endless memory leaks, buffer overflows, etc. and the related security issues, crash bugs, data corruption, etc. shows that no code base is really immune to this.

The best attitude in programmers (regardless of the language) is the awareness that "my code probably contains embarrassing bugs, I just haven't found them yet". Act accordingly.

There are of course lots of valid reasons to continue to use C/C++ on projects where it is used and there are a lot such projects. Rewrites are disruptive, time consuming, expensive, and risky.

It is true that there are ways in C++ to mitigate some of these issues. Mostly this boils down to using tools, libraries, and avoiding some of the more dark corners of the language and standard library. And if you have a large legacy code base, adopting some of these practices is prudent.

However, a lot of this stuff boils down to discipline and skill. You need to know what to use and do, and why. And then you need to be disciplined enough to stick with that. And hope that everybody around you is equally skilled and disciplined.

However, for new projects, there usually are valid alternatives. Even performance and memory are not the arguments they used to be. Rust seems to be building a decent reputation for combining compile time safety with performance and robustness; often beating C/C++ implementations of things where Rust is used to provide a drop in replacement. Given that, I can see why major companies are reluctant to take on new C/C++ projects. I don't think there are many (or any) upsides to the well documented downsides.

Post reply on HN