A safe, non-owning C++ pointer class
techblog.rosemanlabs.com
A safe, non-owning C++ pointer class
1–10 of 50 posts
Re: A safe, non-owning C++ pointer class
#2> Note that our use case is in a single-threaded context. Hence, the word safe should not be interpreted as ‘thread-safe.’ Single-threadedness greatly simplifies the design; we need not reason about race conditions such as one where an object is simultaneously moved and accessed on different threads. Extending the design to a thread-safe one is left as an exercise to the reader.
Why intentionally design a worse alternative to std::weak_ptr which has been around since C++11??
Re: A safe, non-owning C++ pointer class
#3> Extending the design to a thread-safe one is left as an exercise to the reader.
Doesn't get much glibber than that!
Re: A safe, non-owning C++ pointer class
#4I’ve recently read the third edition of Bjarne’s “A tour of c++” (which is actually a good read). I feel the author of this post could benefit from doing so also.
Re: A safe, non-owning C++ pointer class
#5[deleted]
Re: A safe, non-owning C++ pointer class
#6> Note that our use case is in a single-threaded context. Hence, the word safe should not be interpreted as ‘thread-safe.’ Single-threadedness greatly simplifies the design; we need not reason about race conditions such as one where an object is simultaneously moved and accessed on different threads. Extending the design to a thread-safe one is left as an exercise to the reader. Why intentionally design a worse alter…
They never mention std::weak_ptr which makes me think they aren't aware of it.. yes this looks pretty useless and unsafe(isn't everything multi-threaded these days..)
Re: A safe, non-owning C++ pointer class
#7[deleted]
Re: A safe, non-owning C++ pointer class
#8> Note that our use case is in a single-threaded context. Hence, the word safe should not be interpreted as ‘thread-safe.’ Single-threadedness greatly simplifies the design; we need not reason about race conditions such as one where an object is simultaneously moved and accessed on different threads. Extending the design to a thread-safe one is left as an exercise to the reader. Why intentionally design a worse alter…
(Author here.) That is a good question. For our use case, we in fact do not use std::shared_ptr in our implementation, but instead a single-threaded shared_ptr-like class that has no atomics (to avoid cross-core contention).
However, when I wrote the blog-post, I replaced that not-so-well-known class by std::shared_ptr for the sake of accessibility of the blogpost for a general c++ audience, but by doing so, it indeed becomes a natural question to ask why one wouldn't use std::weak_ptr (which I hadn't realised when writing the post).
One reason why this design can still be beneficial when using the standard std::shared_ptr in its implementation, is when you do not want to manage the pointee object by a std::shared_ptr (which is a requirement if you want to use std::weak_ptr). E.g., if you want to ensure that multiple objects of that type are laid out next to each other in memory, instead of scattered around the heap.
Another goal of the post is to show this idea, namely to use a shared_ptr (instead of shared_ptr), which is kind of non-standard, but can be (as I hope I convinced you) sometimes useful.
Re: A safe, non-owning C++ pointer class
#9> Extending the design to a thread-safe one is left as an exercise to the reader. Doesn't get much glibber than that!
That was mostly meant as irony/a joke, but I admit that's not really clear from the text...
For the sake of clarity, if you need thread-safety, probably best to just use std::shared_ptr / std::weak_ptr.
Re: A safe, non-owning C++ pointer class
#10> Note that our use case is in a single-threaded context. Hence, the word safe should not be interpreted as ‘thread-safe.’ Single-threadedness greatly simplifies the design; we need not reason about race conditions such as one where an object is simultaneously moved and accessed on different threads. Extending the design to a thread-safe one is left as an exercise to the reader. Why intentionally design a worse alter…
(Author here.) That is a good question. For our use case, we in fact do not use std::shared_ptr in our implementation, but instead a single-threaded shared_ptr-like class that has no atomics (to avoid cross-core contention). However, when I wrote the blog-post, I replaced that not-so-well-known class by std::shared_ptr for the sake of accessibility of the blogpost for a general c++ audience, but by doing so, it indee…
> but instead a single-threaded shared_ptr-like class that has no atomics (to avoid cross-core contention
Why would there be contention in a single threaded program?