It seems like the volatile
comparison functions in shared_ptr
implementation do not exist.
Does it even make sense to exist?
Essentially no, the standard doesn't cater for comparisons or boolean conversion on a volatile shared_ptr
.
The following fails to compile...
auto main() -> int {
volatile shared_ptr<int> a;
if (a == nullptr) // fails
; // empty
if (a) // fails
; // empty
}
You could cast the volatile
off (via. a const_cast
), but I'm not sure that will have the desired outcome. From the cppreference:
Modifying a
const
object through a non-const
access path and referring to avolatile
object through a non-volatile
glvalue result in undefined behavior.
In more general terms, in not marking member methods as volatile
, the class or library implementors are effectively saying "this is not intended to be use as a volatile
object" - if it were, then the appropriate methods or overloads would provide for volatile
objects. Similarly, this applies to const
, in marking members as const
, they are saying "this class can be used as a const
object.
Why is the volatile
needed, what external sources could be modifying the shared_ptr
"without the knowledge of the compiler" (this is one of the uses of volatile
)? If there are threading issues, then you would be better served with one the thread library utilities, or if the requirement is simply turning off optimisations, various compilers have mechanisms for this already (pragmas etc.).