Live data from Hacker News

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

twitter.com

691–700 of 929 posts

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

#691

Earlier quoted context omitted.

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 { .. }

>...And others

> auto main() -> int {

Absolutely no reason to masquerade main() in such a fashion!

It's a rule of least surprise, be it for user or fellow developer.

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

#692

Earlier quoted context omitted.

Can you please elaborate?

It's a meme template. The gp post didn't spend time to actually complete it, which is disappointing because it could be very funny.

Neither did you, so now we know a partial joke which could be funny but no one cared to elaborate.

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

#693

Earlier quoted context omitted.

I was saying a commanders accuracy with a rifle isn’t relevant to their ability to decide tactics or strategy. Nothing you’ve said contradicts what I said.

But the commander hasn't tried a machine gun and thinks that a bayonet charge will still work like it did before.

Or, the commander thinks that in an age of drones and cruise missles, bayonet charges don't make sense even if the bayonet is now attached to a machine gun.

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

#694
post #464
post #454

Earlier quoted context omitted.

In other words, not a problem.

Except for the use-after-free?

Because nobody does this. An sv is a temporary you pass down the call chain, where it is uniformly perfectly safe.

This is why I say it takes extra work to get things wrong. Every example purporting to show "unavoidable" memory faults is super contrived. You have to turn off compiler warnings to be able to miss it.

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

#695
post #230

Earlier quoted context omitted.

Box doesn't solve the problem of cyclic references. And telling people they need to eat the overhead of a per-object reference count and/or weak pointer double-dereference just to write a list that can delete items in place is a pretty tall order for a language that claims to be high performance. No, this is genuinely a big hole in the expressive space of the language. Not a lot of apps really need to do a ton of man…

> a pretty tall order for a language that claims to be high performance. Doing this in Rust is still going to be orders of magnitude faster than many other languages. Maybe not C/C++, but then again if you’re chasing pointers in a list maybe squeezing every ounce of performance you can isn’t the #1 priority for the given application. The industry consensus is shifting to the idea that being #1 in security at the expe…

> The industry consensus is shifting to the idea that being #1 in security at the expense of being #2 or #3 in performance is a fine trade off.

Is it? That's where Java was 20 years ago.

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

#696

Earlier quoted context omitted.

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…

That's quite readable and actually makes me wanna try C++20 or whatever it is.

the gist is mostly c++11, all I can say is that c++20 is much better.

with constexpr etc, and std::move, and unique_ptr in use, many memory safety issues can be contained.

adding cppfront on top can make modern c++ even more memory safe.

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

#697

> For the sake of security and reliability. I just read a few C++ vs Rust comparisons online yesterday and didn't see anything about a significant difference in security or reliability. Mind you the articles weren't very technical. How is Rust so much more secure and reliable than *modern* C++?

Using modern C++ is like walking a tightrope. If you stay within the constraints, you'll do mostly fine. But it's a fine balancing act and there's a steep cliff to fall off if you don't pay enough attention.

Look at it from the perspective of someone brand new to C++. How do they know what is "modern" and the right way to do things, versus "legacy" and the wrong way to do things? As a beginner, there are thousands of resources available to you on the internet -- some new, some decades old -- with code of varying quality that may or may not be "modern". All of it is valid C++ and will compile, but some of it may have footguns that are nonobvious to the new programmer. There's no "modern only" compiler that will reject said footguns, because C++ takes the position that leaving the footguns there is a feature.

This isn't the case with Rust. Maybe it will become more like C++ in the future as the language changes, only time can tell. But for now, code that compiles in Rust is guaranteed to be free from various classes of bugs that still are possible to compile in C++, despite "modern" C++ having fixed various issues.

Another way of saying this is that "just use modern C++" is a variation of "you're holding it wrong" or "just don't write buggy code", which has proven not to be scalable advice that leads to safer software.

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

#698

Earlier quoted context omitted.

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

Right. So the general says we should use a different weapon. That’s fine. It’s also fine to question if that strategy makes sense. It is nonsensical to say “the general can’t hit a moving target with the old rifle, so he should say nothing at all about weapons”. Which is what the person I replied to said.

The point the person you replied to was making was that him being CTO didn't add much credibility to his claim as you seem to assume by bringing it up, not that it necessarily removed credibility.

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

#699

Earlier quoted context omitted.

I disagree with both paragraphs. By choosing a license that requires attribution, developers are communicating a preference. MIT0 and 0BSD exist. If someone does not care about attribution, they would use one of those licenses. Dynamically linking to a MIT lib is not the same as distributing an MIT lib, so yeah static linking to the lib is completely different, according to the terms of the license. If you are workin…

They certainly don't care enough to enforce it. >Dynamically linking to a MIT lib is not the same as distributing an MIT lib Would you mind citing the clause that makes that distinction?

I’m not a lawyer and this is not legal advice, but…

> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

When statically linking, you’re including a copy of the software, so you’re required to include the notices.

When dynamically linking, you’re not including the software.

Seems pretty straight forward to me.

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

#700

I'm just a programmer who's been doing this for 20 years. I don't have the credentials of Mark, who is a legend. But I fully agree with him. There will be specific exceptions, but if you have the choice between Rust and C++ you would be making a big mistake to not choose Rust. The language is simpler, cleaner, safer, and more enjoyable to work with. The build tools are far more pleasant. The IDE experience is compara…

As someone that is looking to learn one or the other (and hopefully be able to utilize it to land a job too), is the recommendation to skip learning C++ at this point and learn Rust instead? I was going to learn how to write a game boy emulator, which could be written in either, but I’d also like the language to help me in the professional world as someone getting ready to enter the field.
Post reply on HN