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

C++ Should Be C++

open-std.org

Post reply on HN
Print view View original

131–140 of 191 posts

Re: C++ Should Be C++

#131

Post by ativzzz »

josephg wrote: post #101
professoretc wrote: post #74

Earlier quoted context omitted.

> I'm always saying that good way to learn language patterns and idioms is to look into standard libraries implementations. Why would that be true? When you write a library, you are writing code to cover all possible uses; everything within the scope of your library should at least be considered, even if you personally have no need of that particular bit of functionality. But when you write a program it only has to d…

I hear you. But I’ve also learned a lot about how to write idiomatic rust from scrolling through rust’s standard library. You’re right - because it’s written to support lots of programs, it sure is packed with a lot of functions I’ll probably never use. But it’s still quite beautiful and readable. Much more so than C++. Here’s std::vec: https://doc.rust-lang.org/src/alloc/vec/mod.rs.html I tried to read C++’s vec cla…

I'm not very familiar with rust, but isn't the point to mostly avoid `unsafe` and write safe code? Strange that basic std vec functions like insert and remove call `unsafe` - isn't this an example where you don't want to be like the std lib?

Re: C++ Should Be C++

#132

Post by leopoldj »

throwaway81523 wrote: post #100
gafferongames wrote: post #95

Earlier quoted context omitted.

> C++ is at least still pretty committed to the you only pay for what you use principle. As far as I know RTTI is the only real exception (corrections welcome), but even RTTI can be disabled in many compilers. Compile time would also be an exception.

I had a program that had to parse a lot of integers like "12345". The std way to do it was an order of magnitude slower than writing my own simple parsing code. I have no idea what the std version was doing, but it was crazy to see my program's execution time (measured in hours) dominated by int parsing. The handwritten version eliminated that.

You didn't say which std function you were using that was slow. But std::from_chars performs a lot faster than std::stoi et al due to many reasons.

Re: C++ Should Be C++

#133

Post by nickm12 »

fancyfredbot wrote: post #97

What is the proposed legislation referred to in this article?

I have not heard anything about legislation, but the NSA and CISA have been arguing for the industry to embrace memory safe languages:

https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre...

Even without legislation, I could imagine that the US government could try to enact software procurement rules that favor or require memory-safe implementations.

Re: C++ Should Be C++

#134

Post by josephg »

ativzzz wrote: post #131
josephg wrote: post #101

Earlier quoted context omitted.

I hear you. But I’ve also learned a lot about how to write idiomatic rust from scrolling through rust’s standard library. You’re right - because it’s written to support lots of programs, it sure is packed with a lot of functions I’ll probably never use. But it’s still quite beautiful and readable. Much more so than C++. Here’s std::vec: https://doc.rust-lang.org/src/alloc/vec/mod.rs.html I tried to read C++’s vec cla…

I'm not very familiar with rust, but isn't the point to mostly avoid `unsafe` and write safe code? Strange that basic std vec functions like insert and remove call `unsafe` - isn't this an example where you don't want to be like the std lib?

At the end of the day, rust is still a systems language. Lots of useful things require unsafe, including most data structure implementations and FFI - including syscalls.

I see rust's safety guarantees like having a good static type system. Static type systems don't claim to prevent all bugs, but they do catch an awful lot of bugs at compile time in practice. Rust's default safety with opt-out unsafe blocks work the same way. Despite what some zealots would have you believe, the point isn't to make every single line of code "safe". Good rust code still uses unsafe code - for example your binary includes unsafe code whenever you use Vec or Box from std. But all unsafe code blocks are explicitly called out as such, tested thoroughly (eg with miri) and usually constrained to a small part of your program. You can think about it as, C or C++ programs are 100% unsafe. Rust programs are usually only ~2% unsafe or so. That makes a huge difference in practice.

Unsafe code can also usually be encapsulated in safe wrappers. (Eg std::io::File wraps the unsafe call to open(), and std::Vec wraps some raw pointer operations). Unsafe also doesn't turn off the borrow checker. The only difference is unsafe blocks allow you to dereference pointers, call unsafe functions, and a few other things like that.

Re: C++ Should Be C++

#135

Post by steveklabnik »

ativzzz wrote: post #131
josephg wrote: post #101

Earlier quoted context omitted.

I hear you. But I’ve also learned a lot about how to write idiomatic rust from scrolling through rust’s standard library. You’re right - because it’s written to support lots of programs, it sure is packed with a lot of functions I’ll probably never use. But it’s still quite beautiful and readable. Much more so than C++. Here’s std::vec: https://doc.rust-lang.org/src/alloc/vec/mod.rs.html I tried to read C++’s vec cla…

I'm not very familiar with rust, but isn't the point to mostly avoid `unsafe` and write safe code? Strange that basic std vec functions like insert and remove call `unsafe` - isn't this an example where you don't want to be like the std lib?

> Strange that basic std vec functions like insert and remove call `unsafe`

The standard library has more unsafe than most programs, because "data structures that need a lot of unsafe" has historically been an argument for being put in the standard library, because that way they'll be reviewed very carefully by experts.

Re: C++ Should Be C++

#136

Post by bsder »

josephg wrote: post #99
mxmlnkn wrote: post #51

Earlier quoted context omitted.

And the additional trade-off that some bugs are only noticed at runtime when that particular line is executed while it could have been noticed by the compiler of a strongly typed language. Pytype helps but at this point you have a static analyzer that potentially runs as slow as a compiler without the additional performance benefit.

There’s no good reason for type checking to be super slow. I’m no fan of Go, but the language compiles insanely fast while being fully statically typed. As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once. This isn’t a problem with static typing. It’s a problem with C++, and to a lesser extent C.

> As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once.

Sort of. The primary issues are:

1) The C/C++ grammar is garbage.

Note that every single modern language has grammatical constructs so that you can figure out what is "type" and what is "name" without parsing the universe. "typedef" makes that damn near impossible in C without parsing the universe, and C++ takes that to a whole new level of special.

2) C++ monomorphization

You basically compile up your tempate for the universe of every type that works, and then you optimize down to the one you actually use. This means that you can wind up with M*N*O*P versions of a function of which you use only 1. That's a lot of extra work that simply gets thrown away.

The monomorphization seems to be the biggest compile time problem. It's why Rust struggles with compile times while something like Zig blazes through things--both of those have modern grammars that don't suck.

Re: C++ Should Be C++

#137

Post by josephg »

aw1621107 wrote: post #122
josephg wrote: post #112

Earlier quoted context omitted.

> due to the fact that the linker needs to do extra work to eliminate redundant instantiations. Yeah, I see this as another consequence of C++'s poor compilation model: - Compilation is slow because a template class in your header file gets compiled N times (maybe with precompiled headers). The compiler produces N object files filled with redundant code. - Then the linker is slow because it needs to parse all those o…

I'm not sure I'd call the design "bad". At the very least it's a product of the design constraints, and I'm not sure there's an obviously better implementation without sacrificing something else. I think separate compilation and monomorphization are the biggest contributors, but I wouldn't be surprised if there was something I was forgetting. Somewhat related, there was some work in Rust about sharing monomorphized g…

> I'm not sure I'd call the design "bad". At the very least it's a product of the design constraints, and I'm not sure there's an obviously better implementation without sacrificing something else.

It was a product of the design constraints in the 70s when memory was expensive, and compilers couldn't store a whole program in memory during compilation.

The problem C++ has now is that the preprocessor operates on the raw text of a header file (which is a relic from C). This means the same header file can generate totally different source code each time its included in your program. C++ can't change that behaviour without breaking backwards compatibility. So headers get parsed over and over again "just in case" - wasting time producing excess code that just gets stripped back out again by the linker.

The way C++ works doesn't make any sense now that memory is so much cheaper. Go, C#, java, rust, zig - basically every compiled language younger than C++ compiles faster than C++ because these languages don't contain C++'s design mistake.

Rust doesn't share monomorphized generics across crates, but at least each crate is compiled as a single compilation unit.

Re: C++ Should Be C++

#138

Post by MathMonkeyMan »

In every job I've had so far, I've been writing C++ because the guy before me wrote C++. That's really all there is to it.

What "C++" means depends on the project. Maybe that's why it's so hard for the standard -- they have to consider more than one project.

Re: C++ Should Be C++

#139

Post by throwaway81523 »

leopoldj wrote: post #132
throwaway81523 wrote: post #100

Earlier quoted context omitted.

I had a program that had to parse a lot of integers like "12345". The std way to do it was an order of magnitude slower than writing my own simple parsing code. I have no idea what the std version was doing, but it was crazy to see my program's execution time (measured in hours) dominated by int parsing. The handwritten version eliminated that.

You didn't say which std function you were using that was slow. But std::from_chars performs a lot faster than std::stoi et al due to many reasons.

Yeah I don't remember what I originally used. It might have been stoi but it might have been iostream.

Re: C++ Should Be C++

#140

Post by throwat2341 »

C++ has major flaws that cannot be rectified without serious breaking changes. With that said, Herb has been experimenting with a new cpp frontend with sane defaults [1].

In my opinion, the world is on standby until Anders Hejlsberg feels like tackling a modern, next generation systems language.

[1] https://github.com/hsutter/cppfront

Post reply on HN