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

It's time to halt starting any new projects in C/C++

twitter.com

Post reply on HN
Print view View original

561–570 of 929 posts

Re: It's time to halt starting any new projects in C/C++

#561

Post by forgotpwd16 »

nindalf wrote: post #559
mkl wrote: post #551

Earlier quoted context omitted.

I find it hard to imagine the CTO of Azure has done enough C++ programming in the last few years to be fluent in C++20. Maybe as a hobby I suppose; it doesn't match my understanding of what a CTO of a big organisation does otherwise.

He doesn’t need to be fluent in every language to set technical direction as a CTO. You don’t question a general’s war strategy simply because they aren’t accurate with a rifle.

>You don’t question a general’s war strategy simply because they aren’t accurate with a rifle.

Thing is in this case their advice regards the rifle.

Re: It's time to halt starting any new projects in C/C++

#562

Post by galangalalgol »

KptMarchewa wrote: post #556
dale_glass wrote: post #520

Earlier quoted context omitted.

The implication is that he's mostly writing C despite the file extension suggesting they contain C++. C++ changed a lot over time, and the way modern code is supposed to be written is very distinct from "C with classes", but you still can do that if you want.

>the way modern code is supposed to be written Many experts disagree with the way modern C++ evolves. To say that modern code is supposed to use all the C++11-forward features or else it's obsolete is a massive bias on your part.

C with classes originally meant non oo c++. It was a common crticism from a time when not being oo was considered a defect rather than a design decision on which paradigm fit your problem space. It would be like a haskell zealot saying someone's clojure was "java with lambdas" to imply it was imperative. Implying imperative code was always inferior.

All that said, some parts of moder c++ like move semantics do really cut down on defects. People who go out of their way to use *all* of the new toys create codebases that make my teeth itch.

Re: It's time to halt starting any new projects in C/C++

#563

Post by mkl »

nindalf wrote: post #559
mkl wrote: post #551

Earlier quoted context omitted.

I find it hard to imagine the CTO of Azure has done enough C++ programming in the last few years to be fluent in C++20. Maybe as a hobby I suppose; it doesn't match my understanding of what a CTO of a big organisation does otherwise.

He doesn’t need to be fluent in every language to set technical direction as a CTO. You don’t question a general’s war strategy simply because they aren’t accurate with a rifle.

Absolutely, but that's not what this subthread is about. It started with zerr saying:

> With all due respect, this is coming from a Win32 API C programmer who happens to save the code in files with .cpp extension. In other words, not familiar with modern C++.

Edit: Ah, you said "know enough about modern C++", so yes, I agree and was arguing in the wrong bit of the thread.

Re: It's time to halt starting any new projects in C/C++

#564

Post by ithkuil »

dale_glass wrote: post #543
palata wrote: post #534

Earlier quoted context omitted.

Wut? Makes no sense to me.

Here's an example of C++ code written intentionally with all the latest C++ features: https://gist.github.com/caiorss/c7db87df674326793431a14006aa... It looks pretty much nothing like a C program doing the same job. A lot of those features were made to make C++ a safer language to use. Eg, with a construction like: for(const auto& it : ast){ You can't accidentally walk past the end of the array by going one item too…

Why some functions are declared like:

    void foo()  { .. }
And others

    auto foo() -> void { .. }

Re: It's time to halt starting any new projects in C/C++

#565

Post by retrocryptid »

There are C programs I wrote in 1982 that still compile and run (and do still do what they were intended to do.) There are rust programs from 5 years ago that don't compile. I have rust programs from 2 years ago that compile but silently fail because semantics of the language have changed.

Before we say C must die, let's think of the modern marvel of reverse compatibility.

But sure, C++ should die. Having to look at several files to figure out how a statement works is annoying.

Re: It's time to halt starting any new projects in C/C++

#566

Post by twic »

jstanley wrote: post #560
HelloNurse wrote: post #502

Earlier quoted context omitted.

This means that you have array accesses that cause index out of bounds fatal errors instead of invalid pointer dereferencing that causes fatal segmentation failure errors. Detecting this kind of bugs reliably is a very good thing, but preventing such errors (and optimizing away bounds checking if possible) would be better.

That's good! That's what you want. Out-of-bounds array accesses causing segfaults is the happy case! The sad case is security vulnerabilities.

If dereferencing an invalid pointer reliably caused a segfault, this would be true. But it's undefined behaviour, so it can segfault, corrupt data, leak data, etc. Given that the possible behaviour is a superset of what can go wrong using an integer index, i would say it's worse.

I would agree that using naive integer indices, and running the risk of accessing the wrong data, is also completely unacceptable, though.

Re: It's time to halt starting any new projects in C/C++

#567

Post by galangalalgol »

nindalf wrote: post #559
mkl wrote: post #551

Earlier quoted context omitted.

I find it hard to imagine the CTO of Azure has done enough C++ programming in the last few years to be fluent in C++20. Maybe as a hobby I suppose; it doesn't match my understanding of what a CTO of a big organisation does otherwise.

He doesn’t need to be fluent in every language to set technical direction as a CTO. You don’t question a general’s war strategy simply because they aren’t accurate with a rifle.

If you're commanding officer orders a bayonet charge in the late 19th century it is safe to say they don't understand the change rifles have brought to the fight. Reference Picket's charge.

Re: It's time to halt starting any new projects in C/C++

#568

Post by unrealhoang »

ninefathom wrote: post #406
humanrebar wrote: post #320

Earlier quoted context omitted.

...as long as you're fine shelling out to cargo, right? What if that's not appropriate or ergonomic? There's a world where Rust is as easy to use as C, C++, Fortran, etc. outside of cargo, but it's not an interesting use case for the Rust community to support right now for whatever reason. That's basically my point. And it's common enough to have linked programs in which python calls C that calls C++ that calls Fortr…

"There's a world where Rust is as easy to use as C, C++, Fortran, etc. outside of cargo, but it's not an interesting use case for the Rust community to support right now for whatever reason. That's basically my point." Yep. The Rust ecosystem is very much a product of the always-connected, move-fast-and-break-things, DevOps-CI/CD-SCRUM-Agile, horizontal scaling world... which is fine right up until the point where it…

Rust-for-Linux doesn't use cargo, yet no satan or demon appears anywhere. Yes, adding dependencies is not single line updated like Cargo-based workflow, but also not that much different than adding a C/C++ dependency.
Post reply on HN