Hacker News Reader

Comment by shmerl | Hacker News Reader

Raw pointers is a bad example to compare to Rust. It's more like comparing C to it. If anything one should compare managed pointers like std::shared_ptr and etc, especially since the author mentions C++11.

View on HN

One thing important to keep in mind that unique and shared pointers are actually _much_ less common than borrowed pointers in Rust. I have little C++ experience, but I can borrowed pointers in Rust are used exactly like the unsafe pointers that would be used in the same situation in C. In other words borrowed pointers allow you to write the same code you would in C, but safer. [Other Rust features necessitate or strongly encourage different coding styles.] This leads me to conclude that C++ smart pointers either give you less ergonomics, or less safety, than Rust.

What do you mean less common? Less commonly used or less commonly useful? Idiomatic C++11 discourages usage of raw pointers altogether. C++ introduced RAII ideas quite a long time ago, it's just in practice they weren't always followed and only in C++11 they were backed by standardized features from stdc++. Rust has an advantage of following this approach from the very beginning and not having all kind of legacy baggage.

To be clear: Rust has quite a few smart pointer types, but because Rust makes regular references completely safe, people just use those a lot of the time. For example, very few functions are written to take `Vec<T>`s (the equivalent of C++'s `std::vector`), because they can simply take slices (`&[T]`) which are just a pointer and a length. Storing a slice in a structure isn't unsafe in Rust, so people do it all the time. The same goes for strings (Rust's `&str` is equivalent to C++'s `std::string_view`). It is also very common to pass references directly into slices, strings, or other data structures rather than copying, allocating, or moving, since it's completely safe to do so. You end up only really requiring explicit smart pointers for recursive data structures, or in very rare cases where you need complex ownership behavior.

Thanks for clarifying. That's good, since I assume using smart pointers is more expensive in Rust than using references, same as in C++.

Reference counted smart pointers are more expensive than regular references in rust, but not as expensive as those in C++: Regular Rc pointers live on a single thread, and so don't have to use atomic increment/decrement like they do in C++. In addition, Rust's support for borrowing means that when passing smart pointers around you typically don't need to increment/decrement the pointer at all - because the compiler statically enforces that the borrowed reference lives for a shorter time than the smart pointer it's borrowed from.

Not only legacy, many hardware vendors provide only C bindings leaving the management of resources to the user.

How many hardware vendors provide any kind of Rust bindings at all? Let's compare like with like.

Maybe a more fair example would be std::fstream from C++, which takes a `char const ` (no size integer) or a `std::string` (a.k.a. string buffer) as constructor arguments. In the most idiomatic C++ possible, the standard library would support two character iterators.
In Rust, the equivalent might be:
let ioResult = File::open(&Path::new("foo.txt"));
...no unsafe pointers or mandatory allocation necessary (1). Plus you're forced to check your error condition by unwrapping the returned value.

I don't bring that up to pick a nit, but to point out that this is basically the state-of-the-art (well, the char might be paired with a size_t) for passing strings through C++ APIs.

(1) I'm not sure whether Path::new actually allocates, but there's nothing stopping you from implementing a tight-and-fast InPlacePath that works seamlessly.

Both, because you don't need them as often.

Not sure, I used them quite extensively in various projects and tried avoiding raw pointers. The only concern can be some cost of overhead when using them.

Also failed to use std::thread and its related synchronization primitives.

And nobody who's been writing C or C++ for more than five minutes would actually make that mistake with a switch statement (omitting breaks). On the contrary, its fall-through behavior is often very convenient.

I missed a break in a switch a few weeks ago. I have been programming in C++ for more than a decade.

There have been actual real world examples of simple things like one line if statements and forgetting switches breaking code in production software and leading to VERY dangerous things. Especially in C/C++ code.

I have to agree with you. It's never registered as a problem for me. I think of it like an ordinary kitchen knife. Yeah there's an off chance I might cut myself, but 99% of the time I'm just going to enjoy a steak.

Reply on news.ycombinator.com