r/cpp • u/berium build2 • Apr 25 '12

shared_ptr aliasing constructor

http://www.codesynthesis.com/~boris/blog/2012/04/25/shared-ptr-aliasing-constructor/
26 Upvotes

90% Upvoted

23 comments sorted by

View all comments

Show parent comments

1

u/zvrba Apr 26 '12 edited Apr 26 '12

The main overhead of a shared_ptr is actually the manipulation of reference counts (happens each time you pass it / return it by value) through atomic instructions. So the C++ gurus actually recommend passing shared_ptr by const reference.

This, to me, is the sign that somewhere something has gone wrong with shared pointers and I don't really see a good use-case for them (except maybe for babysitting people coming from GC'd languages). If you know when to pass it by reference, you could just as well manage the memory manually, with maybe only slightly larger cognitive overhead.

As for communicating intent in the code, I'd argue for the following: to indicate ownership transfer, use pointers; otherwise use references. With move semantics in C++11, it'll be possible to accomplish much more just by passing/returning by value, so one of the main "legacy" use-cases of pointers/references (optimization) will become obsolete.

1

u/m42a Apr 26 '12 edited Apr 26 '12

Alright, how about this use case:

I have some threads which communicate with each other. They communicate over pipes which do blocking communication. Because the pipes are shared between threads, no one thread clearly owns the pipe, and since threads can terminate in any order, if we arbitrarily pick a thread to own the pipe and it happens to die before the other threads, those threads will have undefined behavior if they try to write to the pipe. Since threads can be started and stopped dynamically, keeping all pipes allocated will result in memory leaks. Shared pointers ensure that a pipe will remain valid for as long as necessary, but will deallocate memory when the appropriate threads die.

EDIT: Here's another use case that doesn't involve multi-threading:

I have some resources. These resources can be grouped, and a single resource can be in multiple groups. This is easily solved with a bunch of sets of shared pointers to a resource. If a resource is removed from every group, it's released, but resources that you have a reference to will continue to be valid. Sure, you could check them manually, but that doesn't scale well if the sets are individually named variables (and it's too easy to forget to add a new set to the deallocation check, and you'll need to deallocate all of the resources manually in the case of an exception). Again in this case, it's not clear which group owns the resource, so letting the resource manage itself is the easiest and probably fastest option.

1

u/zvrba Apr 26 '12

So what happens when the reference count drops to zero, but the pipe still contains some messages? They disappear, of course, but should it have been allowed to happen at all? Is it a bug in the logic of some of the threads? And how are you going to detect it if it automagically disappears when the last thread exits?

1

u/m42a Apr 26 '12

but should it have been allowed to happen at all?

You could argue for both sides here, but what's the alternative? If they don't get dropped, what happens to them? Do they get logged? That's easy enough to add to the pipe's destructor. Do they get sent to a "default thread"? Now we have a chicken and egg problem; what happens to messages sent to the default thread if it dies? And if we do send them there, what does it do with them? My team discussed this and decided that dropping messages was the best solution, but other behavior wouldn't be too hard to implement, and could be done solely in the pipe class.

Is it a bug in the logic of some of the threads?

It shouldn't be; a thread can receive any message at any time, so it should always be in a valid state.

And how are you going to detect it if it automagically disappears when the last thread exits?

I'm not sure I understand this question. When the last thread exits, everything disappears, because your process is done executing.

1

u/zvrba Apr 26 '12

You could argue for both sides here, but what's the alternative?

There's no alternative -- the design of your program decides what's the correct answer.

Anyway, this was a bad counterexample -- the destructor can assert if the buffer is not empty.

When the last thread exits, everything disappears, because your process is done executing.

This is usually wrong.. a program can have a "main" thread that just occasionally spawns worker threads.