On 7/17/2014 9:18 PM, Botond Ballo wrote:
std::shared_ptr is mostly unusable in Gecko code because there's no way to
specify whether you need thread-safety or not (usually you don't). There
should be a way to specify whether you want to pay the cost of thread
safety when using it.
I would like to see this as well.
I talked to Jonathan Wakely (a libstdc++ maintainer) about this, and
he said that this has been discussed but rejected, for two reasons.
First, it encourages brittle code, where instances that don't need
thread safety at one point in time come to need it as the codebase
evolves. Second, it adds complexity to the library and diminshes its
teachability to have two different flavours of std::shared_ptr.

I know std::shared_ptr works in conjunction with std::enable_shared_from_this to provide some form of intrusive reference counting. I think it's unlikely that Mozilla will switch to "vanilla" std::enable_shared_from_this in part because our reference counting has better features (the non-atomic reference counting, and, in debug builds, we log reference counting to provide leak detection and logging, as well as also detecting violation of thread safety), and also in part because we have more complicated reference counting scenarios--cycle collection, for instance. I wonder if the committee would be open to having a smart pointer (maybe by overloading shared_ptr, maybe a new smart pointer) that allows for user-defined reference counting. This could also be useful for, e.g., wrapping gobject references in smart pointers.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to