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

Safe C++ proposal is not being continued

sibellavia.lol

Post reply on HN
Print view View original

211–220 of 226 posts

Re: Safe C++ proposal is not being continued

#211

Post by WalterBright »

hyperman1 wrote: post #172
WalterBright wrote: post #123

Earlier quoted context omitted.

Using D does not require a garbage collector. You can use it, or not, and you can use the GC for some allocations, and use other methods for other allocations. D has a lot of very useful features. Memory safety features are just one aspect of it. > The awkward standard library schism. ??? Don't underestimate the backing of a large and powerful organization.

I've been on the edge to try out D a few times now, and always decided for No in the end. For me, it was missing presence in the IT news that did it. D might be great, but it makes no noise. Rust or go had a lot of articles and blog posts going deep into specific posts, appearing at a regular rate. They tended to appear on e.g this hacker news, or reddit, etc... This caused a drip feed of tutoring, giving me a slow b…

That's the result of having a lot of money behind it, and smart marketing.

Re: Safe C++ proposal is not being continued

#212

Post by motorest »

WalterBright wrote: post #210
motorest wrote: post #207

Earlier quoted context omitted.

> What do you think of C and C++ coming with extensive guides for best practices and what features to not use? I feel that this is a disingenuous point and that you know better than this. For example, the poster child of C++'s "don't use this feature" cliche are exceptions, and it's origins are primarily in Google's C++ stye guide. https://google.github.io/styleguide/cppguide.html#Exceptions If you cross-reference yo…

C++ has a lot of features which are not best practices. For example, you're not supposed to use the builtin arrays anymore, in favor of vector . Google's guide is not the only one. There are the Scott Meyers series "Effective C++" with things like "declare destructors virtual in polymorphic base classes". D's destructors in polymorphic are always virtual. This brings up another issue with C++ - conflation of polymorp…

> C++ has a lot of features which are not best practices. For example, you're not supposed to use the builtin arrays anymore, in favor of vector.

Again, you know better than this. I don't know why you are making these claims, and it's very disappointing to see you make whole sequences of them.

There are no "built-in" arrays in C++. There's C-style arrays, which are there for compatibility with C, and then there's C++'s STL. Since C++'s inception, the recommendation is to use C++'s containers. In STL, there is std::array and std::vector. Which one you pick, it's up to your use case.

This isn't a gotcha. This is C++ 101.

Re: Safe C++ proposal is not being continued

#213

Post by InCom-0 »

Just use sanitizers properly. You are done. Everyone doing anything half-professional with C++ has been doing that for years already. And no you don't have to run sanitizers in production.

That being said: It is inconvenient and it is stacking yet another set of tools and workflow that you have to integrate into your development practice, which is not so nice.

Also, profiles are a better idea anyway. Also, I wish people would stop calling things 'safe'. Ain't nothing 'safe'. There are only various degrees of safety.

Re: Safe C++ proposal is not being continued

#214

Post by dana321 »

tialaramex wrote: post #18

I am actually much more pessimistic about Profiles than Simone. Regardless of the technology the big thing Rust has that C++ does not is safety culture , and that's dominant here. You could also see at the 2024 "Fireside chat" at CppCon that this isn't likely to change any time soon. The profiles technology isn't very good. But that's insignificant next to the culture problem, once you decided to make the fifteen min…

Rust has safety culture? Not in the wild, a lot of coders seem to think its cool to use unsafe to get an extra hairpin of performance at the cost of safety

Re: Safe C++ proposal is not being continued

#215

Post by pjmlp »

DannyBee wrote: post #160
IshKebab wrote: post #33

Earlier quoted context omitted.

Yeah because the committee is now people that a) really love C++, and b) don't care enough about safety to use Rust instead. I think there are plenty of people that must use C++ due to legacy, management or library reasons and they care about safety. But those people aren't going to join language committees.

“But those people aren't going to join language committees.” This is amusingly wrong in the worst way. In the case of c++, they were there but they left years ago when it became clear the committee didn’t see this problem as existential

And in the old days, as I keep telling, many of us (users) prefered C++ over C, exactly due to the safety and stronger typing.

Re: Safe C++ proposal is not being continued

#216

Post by repstosb »

vlovich123 wrote: post #183
Measter wrote: post #153

Earlier quoted context omitted.

It can be preferable to avoid unsafe when reasonable to do so. Programmers are merely human and will make a mistake at some point, and by avoiding unsafe you at least get the guarantee that the buggy behaviour is sound and (aside from race conditions) more predictable.

I think you misunderstand me. I’m not saying that unsafe should be the first thing you reach for. But if you can’t find an easy way to express it safely, and the only path visible is a time costly refactor, it can still be the most cost effective approach and shouldn’t be ignored. Even ignoring the practicality approach, there’s a reason you see it in things like crossbeam or zerocopy - not everything worthwhile expr…

This is exactly how technical debt accumulates. You can write a comment documenting that "unsafe is actually safe here in routine X because Y will always do Z," but if the code lives long enough, someone may eventually change X or Y in a way that falsifies that claim, or try to cut-and-paste X's code into a new context without those guarantees. No, that's not /prudent/, but it happens nevertheless, and the costs of tracking down and fixing the errors are almost always higher than just implementing more conservatively in the first place.

Re: Safe C++ proposal is not being continued

#217

Post by phatskat »

topspin wrote: post #146
tialaramex wrote: post #18

I am actually much more pessimistic about Profiles than Simone. Regardless of the technology the big thing Rust has that C++ does not is safety culture , and that's dominant here. You could also see at the 2024 "Fireside chat" at CppCon that this isn't likely to change any time soon. The profiles technology isn't very good. But that's insignificant next to the culture problem, once you decided to make the fifteen min…

> I am actually much more pessimistic about Profiles than Simone. Likewise. Apparently Stroustrup wrote his first Profiles paper two years before HN existed. That's an incubation period long enough to wonder about its value, for multiple values of "value."

I’m very disconnected from the C/++ world, so when I was reading about profiles in another comment here (the one about the committee essentially saying “Safe C++ is off the table”), profiles sounded like something that was in an early phase of planning and implementation. Then the linked Reddit thread mentioned them being a thing in 2015 and I thought “oof they’ve been on profiles for a minute and it’s this underdeveloped?” and now your comment - yikes!

There was a time when I was learning programming where my options were what the library offered: books on C/++, Java, obscure X extensions, Assembly, and BASIC. I quickly found that C just didn’t “click” for me and the JRE/JDK was a real pain to work with on a slow internet connection and no guidance.

The only thing that’s made me want to go back to trying systems programming is the existence of Rust - I like the concept of the borrow checker and the added safety in general, and the community I’ve seen online seems a lot more inviting and friendly than I ever felt trying to find C++ resources.

All that said, the conversation around core safety in C++ and the community’s reaction to “workarounds” (like offloading functionality to Rust) makes me want to just never step back in to that particular world. There’s no appeal I can see about loading a footgun and putting on a blindfold unless you need to work in that world.

Re: Safe C++ proposal is not being continued

#218

Post by DannyBee »

pjmlp wrote: post #215
DannyBee wrote: post #160

Earlier quoted context omitted.

“But those people aren't going to join language committees.” This is amusingly wrong in the worst way. In the case of c++, they were there but they left years ago when it became clear the committee didn’t see this problem as existential

And in the old days, as I keep telling, many of us (users) prefered C++ over C, exactly due to the safety and stronger typing.

Yep. You either die young or live long enough to become the villain

Re: Safe C++ proposal is not being continued

#219

Post by WalterBright »

motorest wrote: post #212
WalterBright wrote: post #210

Earlier quoted context omitted.

C++ has a lot of features which are not best practices. For example, you're not supposed to use the builtin arrays anymore, in favor of vector . Google's guide is not the only one. There are the Scott Meyers series "Effective C++" with things like "declare destructors virtual in polymorphic base classes". D's destructors in polymorphic are always virtual. This brings up another issue with C++ - conflation of polymorp…

> C++ has a lot of features which are not best practices. For example, you're not supposed to use the builtin arrays anymore, in favor of vector . Again, you know better than this. I don't know why you are making these claims, and it's very disappointing to see you make whole sequences of them. There are no "built-in" arrays in C++. There's C-style arrays, which are there for compatibility with C, and then there's C+…

> There are no "built-in" arrays in C++. There's C-style arrays,

They're built-in arrays. The C++11 n3290 specification calls them arrays in section 8.1. The use of "array" is used regularly elsewhere in the specification. They are built in to the language. There is no warning from clang compiling C++ code that these should not be used.

The trouble with C++ builtin arrays is they have no bounds checking and promptly decay to pointers at every opportunity. Despite the obsolete nature of them, people still use them. There's no switch to turn them off.

Where's the C++ guarantee that code doesn't use those builtin arrays?

Re: Safe C++ proposal is not being continued

#220

Post by hyperman1 »

WalterBright wrote: post #211
hyperman1 wrote: post #172

Earlier quoted context omitted.

I've been on the edge to try out D a few times now, and always decided for No in the end. For me, it was missing presence in the IT news that did it. D might be great, but it makes no noise. Rust or go had a lot of articles and blog posts going deep into specific posts, appearing at a regular rate. They tended to appear on e.g this hacker news, or reddit, etc... This caused a drip feed of tutoring, giving me a slow b…

That's the result of having a lot of money behind it, and smart marketing.

I'd say No on the lot of money, as small scale marketing by a smart person can be enough.

Nginx had the guy translating the manual from russian. Ruby had the person with the weird poetic manuals. Rust had Steve Klabnic and others.

You need someone who is both a technical person and a communicator, being active on fora, doing advent calendars, blog posts, etc... Rust jumped in a hole where D could also fit, and D might be easyer than rust. I think the background interest in D exists, but has nothing to crystallize around.

Post reply on HN