Question about the weak_ptr constructor with lock() call
Hi all, I have question about this line: https://github.com/boostorg/smart_ptr/blob/develop/include/boost/smart_ptr/w... I still can't understand the sentence: // r.px may already have been invalidated. The px(r.px) // conversion may require access to *r.px (virtual inheritance). The px is just a scalar. Why assigning the scalar will require the de-reference operator? The comment says it's in virtual inheritance, but I still have not idea about it. Thanks, Jerry
He-Jie Shih wrote:
Hi all,
I have question about this line: https://github.com/boostorg/smart_ptr/blob/develop/include/boost/smart_ptr/w...
I still can't understand the sentence: // r.px may already have been invalidated. The px(r.px) // conversion may require access to *r.px (virtual inheritance).
The px is just a scalar. Why assigning the scalar will require the de-reference operator? The comment says it's in virtual inheritance, but I still have not idea about it.
When a class Y derives virtually from X, Y contains a hidden pointer of type X* to its X base (because the offset of the X subobject is not constant). When you assign Y* to X*, the compiler reads the hidden pointer of the Y object. If the Y object is invalid, this usually crashes.
On 2016-04-20 21:00, Peter Dimov wrote:
He-Jie Shih wrote:
Hi all,
I have question about this line: https://github.com/boostorg/smart_ptr/blob/develop/include/boost/smart_ptr/w...
I still can't understand the sentence: // r.px may already have been invalidated. The px(r.px) // conversion may require access to *r.px (virtual inheritance).
The px is just a scalar. Why assigning the scalar will require the de-reference operator? The comment says it's in virtual inheritance, but I still have not idea about it.
When a class Y derives virtually from X, Y contains a hidden pointer of type X* to its X base (because the offset of the X subobject is not constant). When you assign Y* to X*, the compiler reads the hidden pointer of the Y object. If the Y object is invalid, this usually crashes.
Maybe the cheaper (and arguably more common) version could be used when it is known that the virtual inheritance is not in play? The case could be detected with is_virtual_base_of from TypeTraits.
participants (3)
-
Andrey Semashev -
He-Jie Shih -
Peter Dimov