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

Modern C++ Won't Save Us

alexgaynor.net

Post reply on HN
Print view View original

171–180 of 395 posts

Re: Modern C++ Won't Save Us

#171

Post by blub »

badsectoracula wrote: post #33
jclay wrote: post #14

I really don't get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn't without it's warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you'll end up writing your CUDA code in C++ anyways. I gues…

C++ does have its positives, as you mentioned, but those positives do not make its negatives go away, nor having negatives means that there aren't positives. You can dislike some parts of the language while still using it for its positive aspect - that doesn't mean the negative parts do not exist nor mentioning them means that there are no positives.

Once again, this is not merely mentioning negatives, it's just more submarine advertising for Rust.

Re: Modern C++ Won't Save Us

#173

Post by PudgePacket »

alfalfasprout wrote: post #135
tatersolid wrote: post #41

Earlier quoted context omitted.

> think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. That’s the whole point: your caveat shows that’s it’s C/C++ which are unsafe in their very nature and therefore should not be used in code exposed to potentially malicious (e.g. user or network) input. Which is just about everything useful. HPC are generally closed systems and have differ…

"which is just about everything useful". This statement is wildly without merit. Sure, for the typical user facing application HN readers talk about then C++ can certainly contain vulnerabilities that are worrisome. Many performance critical applications can tolerate vulnerabilities in favor of latency. It seems to me that the world of realtime systems including avionics, autonomous control software, trading, machine…

> The extreme low level control that C++ offers and powerful metaprogramming allows for performance that even Rust cannot hope to rival.

Could you expand on this? It's a pretty strong claim.

LLVM produces very fast code and is very commonly used for c++ compilation. Rust also has access to the usual low level control suspects, inline asm, manual memory layout & operations, pointer shenanigans etc.

Benchmarks are never perfect but they show that rust in usually within the ballpark of c++, if not comparable: https://www.reddit.com/r/rust/comments/akluxx/rust_now_on_av....

Re: Modern C++ Won't Save Us

#174

Post by dodobirdlord »

alfalfasprout wrote: post #135
tatersolid wrote: post #41

Earlier quoted context omitted.

> think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. That’s the whole point: your caveat shows that’s it’s C/C++ which are unsafe in their very nature and therefore should not be used in code exposed to potentially malicious (e.g. user or network) input. Which is just about everything useful. HPC are generally closed systems and have differ…

"which is just about everything useful". This statement is wildly without merit. Sure, for the typical user facing application HN readers talk about then C++ can certainly contain vulnerabilities that are worrisome. Many performance critical applications can tolerate vulnerabilities in favor of latency. It seems to me that the world of realtime systems including avionics, autonomous control software, trading, machine…

> The extreme low level control that C++ offers and powerful metaprogramming allows for performance that even Rust cannot hope to rival.

I'm curious if perhaps you're using the word 'performance' here in a way I'm not familiar with, especially given the context of metaprogramming. As far as the usage of 'performance' that I'm familiar with, C++ and Rust come in at about even in benchmarksgame, which matches my experience. The optimization pass of Rust compilation is carried out by LLVM on LLVM IR, so it would be very surprising if it reliably underperformed compiled C++, especially given that the compiler has more freedom to optimize due to more extensive constraints on the language.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Modern C++ Won't Save Us

#175

Post by ajxs »

DoingIsLearning wrote: post #166
ajxs wrote: post #76

Earlier quoted context omitted.

I came here to the comments to post this exact thing, haha. I'm very late to the Ada party, and I'm amazed at how ahead of its time this language was. It's still very usable and modern by today's standards.

> by today's standards You make it sound like Ada stopped in the 80's. They don't release standards in rapid succession but 'Ada 2012' has pretty much all of the features that people were asking for in C++ since 2011. The only issue (on top of the obvious lack of coolness and hype around it) is that professional grade Ada compilers/toolchain are still quite a high cost for single developers or small companies. AdaCor…

My comment was more addressing the general public misconceptions of the language. I showed some of my teammates the work I've been doing in it and they were shocked, expecting the language to look like COBOL. When I reference "today's standards", I was referring to the kinds of modern features people expect from a newer language. I haven't had too many problems using the community version of Gnat made by AdaCore, but I share many people's concerns with the main toolchain being developed by a private enterprise who commercialise it. The version of GCC bundled with Fedora Linux IIRC had an Ada toolchain out of the box too. The lack of runtime support for a wide range of architectures/boards was a bit of a bummer, but that's just a function of it's popularity I guess.

Re: Modern C++ Won't Save Us

#176

Post by pjmlp »

It is true, C++ has several warts some of them caused by the copy-paste compatibility with C.

Which is both a blessing and a curse. A blessing as it allowed us Pascal/Ada/Modula refugees never to deal with what was already outdated, unsafe language by the early 90's.

But also makes it relatively hard to write safe code when we cannot prevent team members, or third party libraries, to use Cisms on their code.

Regarding the alternatives, Swift is definitly not an option outside Apple platforms. And even there, Apple still focus on C++ for IO Kit, Metal and LLVM based tooling.

Rust, yes. Some day it might be, specially now with Google, Microsoft, Amazon, Dropbox,... adopting it across their stacks.

However for many of us it still doesn't cover the use cases we use C++ for, so it is not like I will impose myself, the team and customers, a productivity pain, take the double amount of time that it takes to write a COM component or native bindings in C++ for .NET consumption just to feel good.

When we get Visual Rust, with mixed mode debugging, Blend integration and a COM/UWP language projection for Rust, then yeah.

Re: Modern C++ Won't Save Us

#177

Post by pjmlp »

ajxs wrote: post #164
pjmlp wrote: post #158

Earlier quoted context omitted.

A large majority of Ada partisans found their corner in Java, C# and C++'s type system improvements over C, and made the best we could from the sour grapes of C's copy-paste compatibility.

Calling myself an Ada partisan is a bit of a stretch. I've recently begun using it for embedded development, which is a domain almost completely dominated by C. That's the angle I'm coming in from.

It depends on each one naturally.

For me, coming from Turbo Pascal 3 - 6, it allowed me in 1993 to use a language with a similar level of safety and language features, instead of having to deal with PDP-11 constraints.

I was always the weird kid that asked the professors if I could deliver C projects written in C++ instead, which thankfully some of them did accept.

Specially given that at my degree, C was already out of fashion by the early 90's. First year students got to learn Pascal and C++, and were expected to learn C from their introduction to C++ programming.

Re: Modern C++ Won't Save Us

#178

Post by tpolzer »

dodobirdlord wrote: post #170
paulmooreparks wrote: post #134

Earlier quoted context omitted.

Why is it difficult to believe? I've also written plenty of C++ code without memory bugs. It's not that hard if you play by a few simple rules.

> I've also written plenty of C++ code without memory bugs. The classic response to this is "That you know of." Consider that even quality-conscious projects with careful code review like Chrome have issues like this use-after-free bug from time to time. https://googleprojectzero.blogspot.com/2019/04/virtually-unl... So when people claim that they personally don't write memory bugs I tend to assume that they are mist…

Chrome is in an exceptionally hard place because of its JIT. Your language cannot tell you if it's safe for your JIT to omit a bounds check.

Re: Modern C++ Won't Save Us

#179

Post by masklinn »

pjmlp wrote: post #176

It is true, C++ has several warts some of them caused by the copy-paste compatibility with C. Which is both a blessing and a curse. A blessing as it allowed us Pascal/Ada/Modula refugees never to deal with what was already outdated, unsafe language by the early 90's. But also makes it relatively hard to write safe code when we cannot prevent team members, or third party libraries, to use Cisms on their code. Regardin…

> It is true, C++ has several warts some of them caused by the copy-paste compatibility with C.

I mean that's a bit of a cop-out given C++ has more non-C warts and UBs than it has C warts and UBs at this point. It's not just "copy-paste compatibility with C" which made std::unique_ptr or std::optional deref and UB.

Re: Modern C++ Won't Save Us

#180

Post by 0xDEEPFAC »

DoingIsLearning wrote: post #166
ajxs wrote: post #76

Earlier quoted context omitted.

I came here to the comments to post this exact thing, haha. I'm very late to the Ada party, and I'm amazed at how ahead of its time this language was. It's still very usable and modern by today's standards.

> by today's standards You make it sound like Ada stopped in the 80's. They don't release standards in rapid succession but 'Ada 2012' has pretty much all of the features that people were asking for in C++ since 2011. The only issue (on top of the obvious lack of coolness and hype around it) is that professional grade Ada compilers/toolchain are still quite a high cost for single developers or small companies. AdaCor…

Many of AdaCore's "community" versions are the full compiler and if they dont have builds available for your bareboard arch you can build it yourself or get one from gcc.

The only difference is that use of the special "GNAT.X" packages outside the standard runtime are under a GPL restriction and you would be required to export those dependencies as a separate lib and do open dev on it.

Otherwise you are free to sell or keep any trade secrets you want without giving AdaCore anything.

Post reply on HN