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

201–210 of 395 posts

Re: Modern C++ Won't Save Us

#201

Post by adrianN »

gmueckl wrote: post #185
dodobirdlord wrote: post #170

Earlier quoted context omitted.

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

That is why use tools like valgrind to verify that you got it right.

Together with a test-suite that covers the exponential number of paths through your code...

Re: Modern C++ Won't Save Us

#202

Post by pjmlp »

masklinn wrote: post #179
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.

Sure it is, because they need to be compatible with C pointer semantics.

The large majority of C++ UB comes from compatibility with ISO C UB 200+ documented cases.

And ISO C++ working group is trying to reduce the amount of UB in ISO C++, which is exactly the opposite of ISO C 2X ongoing proposals.

Re: Modern C++ Won't Save Us

#203

Post by fooker »

Someone wrote: post #195
Razengan wrote: post #157

Earlier quoted context omitted.

What are the hidden language hacks in Swift?

I wouldn’t call them hacks, but there are things in the runtime that you can’t implement yourself in Swift. Examples (corrections welcome): - you can’t allocate memory and then turn it into an Swift object. - you can’t write Decodable in pure Swift (reflection isn’t powerful enough to do “set the field named “foo” in this structure to “bar”) - reference counts are hidden from Swift code (yes, there’s swift_retainCoun…

There are a lot more of these, I can't find a comprehensive list unfortunately.

Re: Modern C++ Won't Save Us

#204

Post by dragonwriter »

ajross wrote: post #64
arcticbull wrote: post #63

Earlier quoted context omitted.

It’s definitely easier to reason about than C++ because it errs on the side of safety and explicitness. You can use things you don’t understand without fear which straddles the boundary in a good way IMO. To your point that doesn’t make it simple. As a work-a-day hacker it’s completely become my go to language when I’m writing tools, libraries or just want to knock out a simple algorithm to prove myself right or wron…

> It’s definitely easier to reason about than C++ See... I don't think that's true, and argue the huge body of C++ code and talent in the ecosystem is an existence proof to the contrary. I mean, sure, C++ has its crazy edge cases and its odd notions. But you don't need to understand the vagaries of undefined behavior, or the RVO, or move semantics to write and deploy perfectly sensible code. Literally hundreds of tho…

> I'll be frank: probably 40% of professional C++ programmers aren't going to be able to pick up Rust and be productive in it, at all.

Well, a certain number of professional programmers are past the point of being willing to learn new technologies, so maybe that's true. But close to 100% of the people who might become professional C++ programmers could instead become professional Rust programmers.

Re: Modern C++ Won't Save Us

#205

Post by pjmlp »

arcticbull wrote: post #70
the_trapper wrote: post #46

Earlier quoted context omitted.

Rust's learning curve isn't exactly a shallow one either. For the record I think Rust has a lot going for it, but it is not the C++ killer that many are touting it to be.

C++ has a huge learning curve too though, the difference is it lets you write whatever you want. The learning curve is to write correct C++. It’s deceptive, it’s like skiing vs snowboarding. Skiing you pick up fast but to get good is damn hard and few bother. Snowboarding is damn hard to pick up but then it’s pretty easy to become really good.

I guess that is why I enjoy Snowboard and never bothered with skiing. :)

Re: Modern C++ Won't Save Us

#206

Post by felixguendling »

pfultz2 wrote: post #51
jasonhansel wrote: post #36

Can someone at least make a linter that ensures you only use a "safe" subset of C++?

Clang's lifetime profile will catch the first example: :8:16: warning: passing a dangling pointer as argument [-Wlifetime] std::cout :7:38: note: temporary was destroyed at the end of the full expression std::string_view sv = s + "World\n"; ^ And cppcheck will catch the second example: :7:12: warning: Returning lambda that captures local variable 'x' that will be invalid when returning. [returnDanglingLifetime] retur…

For everyone interested in experimenting with this: https://gcc.godbolt.org/z/vmcnXh

Godbolt's compiler explorer is a great tool to try new features (language, compiler, standard library, etc.).

Re: Modern C++ Won't Save Us

#207

Post by dragonwriter »

ncmncm wrote: post #128
Inityx wrote: post #74

Earlier quoted context omitted.

> the huge body of C++ code and talent in the ecosystem is an existence proof to the contrary Looks to me more like proof that C++ has been around a long time

Lots of languages have been around a long time without attracting billions of lines of code. To get that, the language must be unusually useful.

That's a powerful endorsement of COBOL, but a lot of language success is “when did it become common”, “who was sponsoring it or what libraries did it come bundled with”, and path dependence that makes momentarily (due to transient conditions) sensible choices into standards that are mandatory for decades.

Re: Modern C++ Won't Save Us

#208

Post by pjmlp »

jclay wrote: post #132
_bxg1 wrote: post #75

Earlier quoted context omitted.

But most of the things you just listed are just aspects of the existing ecosystem (libraries, tooling, etc.). There's no doubt C++ has an incredibly large ecosystem and will therefore be around for quite a while to come, but that doesn't make it a good language , it just makes it one that happens to have been very popular for a very long time. Our industry is one that values progress over tradition in the long run. I…

The point is that I've noticed a broad "religious" trend where those promoting Rust don't lend any credit to the places where C/C++ has valid strengths, even if due to it's legacy. It doesn't do a great service to either community to constantly pit the two against each other, and to misrepresent the other in a way that's not honest. C++ doesn't exist and continue to evolve just because it's been around forever, there…

Case in point, most modern OS GUIs are written in managed languages nowadays, even Qt has JavaScript bindings now.

Yet, C++ is still there as the binding layer between UI and GPGPU.

Re: Modern C++ Won't Save Us

#209

Post by fetbaffe »

Without any data to back this up, my guess is that there is no good reason to pick C++ for a new project except when the developer is already fluent in C++.

Assume we have this abstract developer that has a good knowledge in programming theory but has no experience in programming languages.

The developer starts a new project, but in what language?

web: Don't see any reason for this. Exist lots of great alternatives. This is not really one of C++ strengths so is not that strange.

desktop-GUI: Probably one of the biggest strengths of C++ is the Qt framework, it is solid choice. I can see this a possible choice. However with electron dominating & PWA:s becoming a more viable option it is probably much higher chance that a HTML/JS environment is picked instead, especially how it already dominates the web. And by using TypeScript you can do it an solid language.

mobile apps: Most apps are written in some web technology or directly with Swift or Java. Qt has some support for this, but not sure how widely used. My experience with NDK was not pleasant. I can't really see this as a viable option.

embedded: I don't do embedded, but my understanding is that plain C is much more common here & if faster development is needed you integrate something like Lua. Maybe?

memory safe: use rust I guess.

compiled binary: Use golang, no complicated buildstep.

Parallellism: Better to use a language designed for this like erlang.

Game development: For the majority of games today a scripting language like JavaScript or Lua is good enough. HTML/JS has some really good frameworks for game development today.

3D game development: Probably a good fit to use C++, but I think that C# with Unity is a much better choice. Great framework, good community, however C++ is not bad choice for this. Possible.

Commandline tool: If the developer is building the next grep, C++ could fit that, but most commandline tools does not have that performance requirement, Probably do some HTTP, JSON decoding, DB access. Bash is good enough or any other dynamic language.

Scientific: my understanding is that today this is mostly python or matlab. Maybe?

System development (drivers etc): I know too little about this to make a good assessment, to be fair I put this as a possible choice.

And if the developer do decides to use C++ for a new project, the initial cost is quite high to just understand the basics, even if he/she uses the latest C++ version. Copy constructors, lvalue & rvalue (xvalue, glvalue, prvalue...), move semantics, const refs, rvo, smart pointers, auto etc

Any good arguments to pick C++ for a new project?

Re: Modern C++ Won't Save Us

#210

Post by Maken »

adrianN wrote: post #199
geezerjay wrote: post #146

Earlier quoted context omitted.

> The standard library certainly is lacking things which are commonly used (say, JSON parsing or database connection), I strongly disagree. It's quite obvious that the C++ standard library does not need to add support for "common things", because they already exist as third-party modules. In fact, this obsession to add all sorts of cruft to the C++ standard is the reason we're having this discussion. If there is no w…

I believe that C++ needs a fat standard library because using third party libraries is a bit cumbersome in C++. Alternatively there could be a blessed build system that makes third party library integration as easy as Cargo or Go Modules.

I would say that CMake pretty much covers that. What it lacks is somehow a central registry, but I think C++ never intended to have one.
Post reply on HN