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

C++ creator rebuts White House warning

infoworld.com

Post reply on HN
Print view View original

131–140 of 141 posts

Re: C++ creator rebuts White House warning

#131

Post by CyberDildonics »

jeffbee wrote: post #130
CyberDildonics wrote: post #126

Earlier quoted context omitted.

Even the heroes eventually capitulate to complexity in C++, compromising performance. It is usually dead simple. Reserve memory in a vector, put data in, loop through it linearly. Modern C++ is very simple most of the time. Where are you getting this idea? It is virtually impossible to write a realistically complex zero-copy RPC server in C++ because the lifetime issues are too daunting. This is not only untrue, it d…

> Reserve memory in a vector, put data in You've already proven that you don't know what I am talking about and now you are doubling down. There is no way to put data into a std::vector without copying it. Vector can't adopt memory that already exists. So your plan doesn't suit the use case I am discussing: zero-copy RPC servers.

Focus up, these are two different things. You said complexity, I said looping through a vector.

You said "zero-copy RPC servers" (for some reason) but never gave any evidence of what you are saying or explained it technically in any way.

I'll ask again, show me what is being done in java that can't be done in C++. Show me technically, prove what you are saying.

I know how these conversations usually go. It's mostly the other person trying anything they can to not give evidence of what they're saying.

Re: C++ creator rebuts White House warning

#132

Post by [deleted] »

cbsmith wrote: post #27
marcus0x62 wrote: post #10

> Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ. I and the C++ standard committee are trying to deal with that If only people were perfect, then things would be perfect. There’s, what, 40 years of evidence to suggest that most people, most of the time, simply cannot write memory-safe C++ code (50 years if you count C.) Ma…

> If only people were perfect, then things would be perfect. That argument doesn't hold up too well, considering that people are involved either way.

[deleted]

Re: C++ creator rebuts White House warning

#133

Post by owlstuffing »

ttfkam wrote: post #90
owlstuffing wrote: post #30

Earlier quoted context omitted.

> At least in Java you can't write bad logic that also suffers from memory issues. Oh you bet you can. There are a number of ways to screw that up. - memory leaks/loitering is quite common, gc won’t help if your code hangs on to stale refs - using Unsafe memory can blow up in glorious C++ fashion, directly or indirectly - using native calls incorrectly can be just as nasty

I'd wager Unsafe in Java is far more rare per million lines of code written than unsafe blocks in Rust. Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects. Now JNI on the other hand, that made up maybe 0.5% back in the day. Not anymore where FFI is the predominant native linkage (but still comparatively quite rare). (Cue the one weird guy coming out of the woodwork who claims tha…

> Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects.

Your project may not use it directly, but there’s a pretty good chance one of your libraries does.

Re: C++ creator rebuts White House warning

#134

Post by kazinator »

> Improving safety has been an aim of C++ from day one and throughout its evolution. Just compare the K&R C language with the earliest C++, and the early C++ with contemporary C++

This rhetoric from Stroustrup comes off as disingenuous; what saves it from being outright dishonest is the wording "an aim". As in one of many. Not "the aim".

Firstly, of course we get a jump in safety from K&RC to C++.

But most of the development of C++ has been driven by a hedge between multiple factors, only one of those being safety, and not always having the top priority. Factors like: ease of implementation, performance, safety and backward compatibility.

We can point to recently introduced library features that are not safe, and easily identify backward compatibility issues that prevent improvements in safety.

In the 1990's, C++ introduced a standard library of containers. If safety had been the top priority, iterators would never have had undefined behavior when the target object changes, and std::vector would have been impervious to out-of-bounds accesses. These things could easily have been achieved in what is just library code. A C++ developer can easily ignore the library, and develop their own containers with safe iterators, vectors that can't be misused and other elements. The standard didn't do that because of those other factors: ease of implementation and performance.

(Can someone point to three situations in the development of C++ in which safety ran up against efficiency or implementation ease, and did not lose?)

Re: C++ creator rebuts White House warning

#135

Post by lostmsu »

nequo wrote: post #113
lostmsu wrote: post #111

Earlier quoted context omitted.

Reasonably sure. As soon as one of your dependencies gets a major version bump with incompatible API, the clock starts ticking.

I have no experience with refactoring a Python project. Wouldn’t type hints make it only somewhat more painful than refactoring Rust?

Only if they are consistently applied.

Re: C++ creator rebuts White House warning

#136

Post by Cloudef »

amluto wrote: post #115
Cloudef wrote: post #74

Earlier quoted context omitted.

The standard library consists many functions that simply should be dropped. All the globals like errno, locale should be removed. Instead of global allocator, allocator struct should be passed around (zig). Headers like stddef and stddint in the standard library should be in the language instead. https://github.com/Cloudef/zig-budoux/blob/master/src/c.zig#...

All true, but that still doesn’t mean that there will ever be a genuinely nice string type or map from string to int or a nice HTTP or any similar thing where some of the data types are dynamically sized.

struct and few functions and you get there. Look at zig's std lib. "String" type is also IMO anti-pattern https://mortoray.com/the-string-type-is-broken/

People often complain about null terminated "strings" in C, but I don't really see them as a problem. It rarely is performance bottleneck, and when it is you can opt for your own "string type". There is also bstring that's compatible with these strings but prepend header to the data which contains the length. That said I wish C had language level slicing.

Re: C++ creator rebuts White House warning

#137

Post by ttfkam »

owlstuffing wrote: post #133
ttfkam wrote: post #90

Earlier quoted context omitted.

I'd wager Unsafe in Java is far more rare per million lines of code written than unsafe blocks in Rust. Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects. Now JNI on the other hand, that made up maybe 0.5% back in the day. Not anymore where FFI is the predominant native linkage (but still comparatively quite rare). (Cue the one weird guy coming out of the woodwork who claims tha…

> Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects. Your project may not use it directly, but there’s a pretty good chance one of your libraries does.

And when I code in C, there's typically at least one library with inline assembly even though my C doesn't use any inline assembly.

There is indeed a difference here between the vast majority taking part in risky behavior and library authors using focused performance improvements. There are a lot more eyes on the library code due to downstream effects than in everyday top-level code.

Re: C++ creator rebuts White House warning

#138

Post by carols10cents »

marcus0x62 wrote: post #110
Calavar wrote: post #48

Earlier quoted context omitted.

I'd say it's actually the other way around. C++ in the abstract is full of half-baked, ill conceived ideas that later had to be deprecated or walked back entirely: std::auto_ptr and memory leaks; std::shared_ptr::unique() not being threadsafe; taking the time to implement bounds checking in std::vector, but the default access operator isn't checked; corner cases with std::initializer_list leading to unexpected behavi…

> Crates.io feels like a graveyard of experimental libraries that reached 40% the functionality of their C++ cousins before the commit activity dropped to zero. Not only that, but you see a huge increase in external dependencies because of the ease of importing crates. I'll admit I have absolutely no evidence to back this up, but the crates system feels to me like the Achille's Heel of Rust's security model in two re…

How are these two problems unique to Rust though?

Re: C++ creator rebuts White House warning

#139

Post by CyberDildonics »

Scubabear68 wrote: post #118
CyberDildonics wrote: post #114

Earlier quoted context omitted.

followed by years of monotonic performance degradation as the flaws in the original are iteratively discovered and remediated. This doesn't make any sense and nothing in this comment is something an experienced optimizer would say. I'm not sure where the fantasy comes from that java is going to beat C++, but anyone experienced in optimization is going to control their memory allocations, then control data access bein…

C++ does indeed give you this level of control. Most C++ code I have seen does not even approach this level of care and customization. When we are talking about speed, most people mean basic out-of-the-box speed of the code without heroic efforts. C++ and Java are a wash at this point performance wise. Most analytics code I have seen on Wall Street was either Java or C++, with the choice driven by what the quants wan…

Most C++ code I have seen does not even approach this level of care and customization.

True, but all of this isn't neccesary to be faster than java.

When we are talking about speed, most people mean basic out-of-the-box speed of the code without heroic efforts.

Fair enough in general. All it takes in C++ is allocating memory out of hot loops and looping through memory linearly. This basically eliminates memory allocation as a bottleneck and pointer chasing as a bottleneck. These two things alone can make a program 100x faster or more.

In C++ makes this is often the simplest possible way to do something, although unfortunately that doesn't mean programs are always done like this.

Re: C++ creator rebuts White House warning

#140

Post by germandiago »

edflsafoiewq wrote: post #108
germandiago wrote: post #103

Earlier quoted context omitted.

On the other side, Rust is a safe language that in real world uses unsafe blocks and unsafe libraries underneath (OpenSSL and other C libraries in practical terms). That is not safe either in practical terms. So there is always this discussion about putting C++ as an unsafe thing and it depens a lot, as you said, on how you use it. I use max warning level, warnings as errors, smart pointers, almost everything return…

Certainly it is a question of degrees. But to say the gap in safety is very small is essentially to say Rust's lifetime system is close to zero-value. Unsafe code still exists, the goal is to localize it to small, auditable blocks. However safety often depends on non-local properties. For example, unchecked iteration over a vector requires we know the vector's lifetime exceeds the iteration lifetime, and that the bac…

It is not that the borrow checker is zero value.

But the borrow checker enters the game also depending on your code style. And when it does it gets quite viral with annotations and the like.

That is why I like more a model like the one found in Hylo language. It sidesteps the rigidity of the borrow checker and it can do very well.

Also, the code style I try to keep in C++ is quite "value-oriented" to avoid the typical lifetime pitfalls.

Nowadays I try to use STL with debug mode but not escape iterators. I am actually considering using a library like Flux because I think that, as fast as the iterator model is, it is basically playing with fire. Flux seems to be very competent performance-wise and safer, besides compatible with ranges.

I am quite happy with C++ at the moment. That does not mean I won't use Rust in the future. Who knows.

I hope more work towards safety will be fone in C++. I would not want a borrow checker, but avoiding as many pitfalls as possible is a good thing. I always use compilers with the maximum warning level and warnings as errors. It is actually a good thing to do.

Post reply on HN