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

A safe, non-owning C++ pointer class

techblog.rosemanlabs.com

Post reply on HN
Print view View original

11–20 of 50 posts

Re: A safe, non-owning C++ pointer class

#11

Post by Kranar »

niekb wrote: post #9
abstractspoon wrote: post #3

> 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.

It's a common misconception that std::shared_ptr is thread safe. The counter is thread safe, but the actual shared_ptr itself can not be shared across multiple threads.

There is now atomic_shared_ptr which is thread safe.

Re: A safe, non-owning C++ pointer class

#12

Post by niekb »

TinkersW wrote: post #6
mwkaufma wrote: post #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 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..)

> isn't everything multi-threaded these days..

There are alternative ways to utilize a machine with multiple cores, e.g. by running one thread per CPU core, and not sharing state between those threads; in each such thread you then have single-thread "semantics".

Re: A safe, non-owning C++ pointer class

#13

Post by mwkaufma »

niekb wrote: post #12
TinkersW wrote: post #6

Earlier quoted context omitted.

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..)

> isn't everything multi-threaded these days.. There are alternative ways to utilize a machine with multiple cores, e.g. by running one thread per CPU core, and not sharing state between those threads; in each such thread you then have single-thread "semantics".

weak_ptr supports this -- it's only mt-safe if you specialize it with std::atomic

Re: A safe, non-owning C++ pointer class

#14

Post by mwkaufma »

niekb wrote: post #8
mwkaufma wrote: post #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 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…

> laid out next to each other in memory

Moving goalpost. But just to follow that thought: Decoupling alloc+init via e.g. placement-new to do this introduces a host of complications not considered in your solution.

If that layout _is_ a requirement, and you don't want a totally nonstandard foundation lib with nonstandard types promiscuously necessitating more nonstandard types, you want a std::vector+index handle.

Re: A safe, non-owning C++ pointer class

#16

Post by izabera »

cherryteastain wrote: post #10
niekb wrote: post #8

Earlier quoted context omitted.

(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?

atomics aren't free even without contention. the slogan of the language is "you don't pay for what you don't use", and it's really not great that there's no non atomic refcount in the standard. the fact that it is default atomic has also lead people to assume guarantees that it doesn't provide, which was trivially predictable when the standard first introduced it.

Re: A safe, non-owning C++ pointer class

#17

Post by jayde2767 »

This just seems intentionally bad to show where Rust would be better. This is yet another example of what I call "corner-case" instruction, which I define as, "I am going to take an obviously terrible corner-case that shows what an awful developer can do that will break a program, then demonstrate my brilliance by introducing my (highly-biased) opinionated point I wanted to make..."

In this particular case, it was subtly, Rust is preferred because it doesn't allow unsafe memory operations such as the one demonstrated. Really, all it demonstrates is that you can create really bad C++.

Re: A safe, non-owning C++ pointer class

#18

Post by spacechild1 »

TinkersW wrote: post #6
mwkaufma wrote: post #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 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..)

Multi-threading does not imply shared ownership, it can also be achieved with message passing.

Re: A safe, non-owning C++ pointer class

#19

Post by eMSF »

izabera wrote: post #16
cherryteastain wrote: post #10

Earlier quoted context omitted.

> 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?

atomics aren't free even without contention. the slogan of the language is "you don't pay for what you don't use", and it's really not great that there's no non atomic refcount in the standard. the fact that it is default atomic has also lead people to assume guarantees that it doesn't provide, which was trivially predictable when the standard first introduced it.

Related to this, GNU's libstdc++ shared_ptr implementation actually opts not to use atomic arithmetic when it infers that the program is not using threads.

Re: A safe, non-owning C++ pointer class

#20

Post by grogers »

izabera wrote: post #16
cherryteastain wrote: post #10

Earlier quoted context omitted.

> 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?

atomics aren't free even without contention. the slogan of the language is "you don't pay for what you don't use", and it's really not great that there's no non atomic refcount in the standard. the fact that it is default atomic has also lead people to assume guarantees that it doesn't provide, which was trivially predictable when the standard first introduced it.

People assume non-existent guarantees such as?
Post reply on HN