dereferenceable::operator-> uses potentially overloaded T::operator& about utility HOT 6 CLOSED

Thank you! Some Russian guy is going to be grateful for this, even if he is not aware of the behind-the-scenes conversation.

from utility.

Looking at the documentation at http://www.boost.org/doc/libs/1_65_1/libs/utility/operators.htm#deref, it is documented to return &*i, which must be convertible to P. Given that the library is quite old and it has been like that for >=15 years, I wonder if there really is a problem that needs to be fixed. Plus we would add a dependency. What are your thoughts on this? Or do you have a specific problem that needs fixing?

from utility.

Hi Daniel,

It's a real problem reported by a user of Boost.MultiIndex —which library is BTW 13 years old :-)

https://stackoverflow.com/questions/47416304/boostmulti-index-container-crashes-with-com-ptr-t-objects

Basically, Boost.MultiIndex does not work with elements whose operator& is overloaded. The problem is scattered through the code, one of the locations being its dependency on boost/operators.hpp.

I understand changing this on your side requires that you update the documentation from

Requirements: (&*i). Return convertible to P.

to

Requirements: *i. Return convertible to R.

which is not, strictly speaking, a relaxation of the former condition —*i could in principle be anything as long as &*i returns a pointer. So it is up to you; if you decide to not do the change I can fix the issue on my side, although it's more verbose in terms of LOCs touched and the root problem might hit other code using boost/operators.hpp. FWIW commercial implementations of std containers guard themselves against abuses of operator& overloading via constructs similar to boost::addressof.

Thank you

from utility.

If Boost.MultiIndex is only 13 years old, you loose ;-P

Joking aside, I am not trying to ignore the problem, I was just curious where this was coming from. I think it is likely enough that people are not relying on the current implementation to allow them to "abuse" an overloaded operator&, so fixing it by using boost::addressof seems reasonable.

For the documentation part, well, it's not correct that the "return" is directly convertible to R. Maybe this would work:

Requirements: *i. Pointer to the return convertible to R.

or "...returned value..." instead of "...return..."?

from utility.

Requirements: *i. Pointer to the return convertible to R.

I think this not correct either... What about

Requirements: *i. The address of the returned value convertible to P.

"Address of a value" is a well-defined concept that does not depend on operator&, so I think this holds water.

from utility.

OK, agreed. I'll commit a fix soon.

from utility.