Rust in the Linux kernel (Google security blog)

This could be spelled "auto obj = std::make_shared<TestObject>(42);", if that makes you any happier.

> > > What is with the reverse problem, the object goes out of scope while the pointer is still there. How is this handled?
> > This shouldn't happen. Your smart pointer should encapsulate the ownership.
> How does this work if the object is on the stack? Or is this not allowed to use pointers to objects on the stack?

I don't think many people would dispute that C++ is a language which provides you with as many foot cannons as you could possibly want, so indeed it's "allowed" in the sense that it will compile, and in principle it could be done safely in certain circumstances - although I'd argue that in those cases it's actually worse than using a raw pointer thanks to the illusion of safety that it offers.

I wouldn't expect it to pass even the most cursory code review though, because creating a shared_ptr/unique_ptr by passing in a raw pointer to some existing object stands out much like an "unsafe" block in Rust. Actually more so, because I'm not sure there are any circumstances where it's unavoidable, unlike "unsafe". The same is true of using "new" or "delete" by the way, let alone "malloc" or "free": for a pure C++ project I consider them a very strong code smell.

Granted there will be some cases where it's avoidable but you want to do it anyway, eg because you have a strong performance reason to prefer a stack object over a heap allocation. Or maybe where you're implementing a glue layer to some legacy code, although then I'd probably expect it to be used with the return value of some legacy function, so at least you know it's not a stack object (or that function is already completely broken). Much like "unsafe", these should hopefully be cases that are infrequent enough that they can be given special attention.

> Or if I have a composite object, how can I create a smart pointer to a sub-object, e.g. to pass it in a function call? Probably this can be done with reference counted pointers, but reference counting has a runtime overhead. In rust one can simply create a pointer to a sub-object and use it. Of course this is only allowed if it is clear by scope that the object always outlives the pointer to the sub-object. And this works without any runtime overhead. The compiler will verify at runtime that the lifetimes work out (or throw an error).

Certainly it's not as easy to get it right as it is in Rust - this is IMO where we start getting into the areas where the benefits of Rust begin to outweigh the cost of learning a new language. For me personally this is one of the things that's help persuade me that it's worth switching. (Rust's enums are another major one.)

To me Rust feels a lot like a successor to C++ specifically, in that it seems to take a lot of ideas from C++ and do them right from the start[0]. The development of C++ is a history of following numerous blind alleys over a few decades, where all of those dead-end paths need to be left open for compatibility. It now provides you with the route to do it right, typically with a lot less pain than ten or twenty years ago, let alone thirty - but also with the route to do it wrong, and the best you can hope for is a compiler warning that tells you "this path takes you to your doom - are you sure that's what you want?". Rust says "actually we're going to brick up most of those paths, and the rest are going to be behind a big iron gate with a padlock labelled 'unsafe'". This is very attractive because it means you can spend more time thinking about what you're doing and less time obsessively checking the map.

[0] In particular, it's the only language I've tried in which the approach to RAII seems to me to be obviously correct.