Boost C++ Libraries: Ticket #10853: problem with detection of const_cast_from

attachment set

Fri, 05 Dec 2014 20:44:18 GMT

attachment → const-cast-from-failure.cpp

Fri, 05 Dec 2014 21:16:03 GMT

I've isolated the heart of the problem. The attached file demonstrates how overload resolution fails with 2 non-template candidate functions, when both involve non-trivial constructor calls, even though one of them involves ellipses. I imagine the original detection code in boost/intrusive/detail/has_member_function_callable_with.hpp assumed the compiler would prefer the non-ellipses constructor.

The bug is triggered in the boost intrusive library as follows:

In the docs, the signature for list_node_traits::get_next() is:
```
static node_ptr get_next(const_node_ptr)
```

In list::front() const, the following code appears:

detail::uncast(node_traits::get_next(this->get_root_node()))

As a result, detail::uncast() is called with an argument of type node_ptr (not const_node_ptr!).
In turn, this triggers the mechanism looking for:
```
node_ptr::const_cast_from(const node_ptr&)
```
The documentation doesn't specify such a method should exist. One would assume it is ok to only have a similar function where the argument is const_node_ptr (not node_ptr!):
```
node_ptr::const_cast_from(const const_node_ptr&)
```
The existing code tries to detect const_cast_from by passing it an argument of type declval<node_ptr>().
Naturally, a constructor exists with the signature:
```
const_node_ptr(const node_ptr&)
```
However, the overload resolution code now has to choose between calling the constructor above, or the ellipses constructor from has_member_function_callable_with.hpp:191.
As the small example demonstrates, the resolution fails with a compile-time error.

Possible fixes:

Update the docs to make it clear node_ptr::const_cast_from(const node_ptr&) should exist. It can be either a normal function, or a template specialization. But crucially, it may not involve extra constructor calls that might confuse overload resolution.
Fix the intrusive code to not run unnecessary const_cast_from detection, i.e., when the argument is already a pointer to a non-const object. This is hard, because it's unclear where to look.
More robust const_cast_from detection.

Ion Gaztañaga — Sat, 06 Dec 2014 19:09:28 GMT

const_cast_from must be a template because you can't only const_cast from a pointer to a const object but also from a non-const volatile object, const_cast also works for expressions that only remove volatile, etc.

I agree that list::front() does not need to use const_cast_from but this expression:

int *p = 0; const_cast<int*>(p);

is valid, and const_cast_from tried to emulate all this permitted behaviour (specially to support some generic code where pointers passed as argumnets could be non-const-qualified.

Sun, 07 Dec 2014 23:37:45 GMT

The non-template conversion function I was using (in 5 above) could do Ptr<A> to Ptr<A> conversion by using an intermediate Ptr<const A> object. The problem was not with the conversion function not being general enough, but with the pointer_traits code failing while detecting the presence of const_cast_from, because it involved an extra constructor call. This extra constructor call confused the overload resolution.

I don't mind const_cast_from being a template, what I minded was finding it out the hard way. Perhaps this could be better explained here: http://www.boost.org/doc/libs/1_57_0/doc/html/boost/intrusive/pointer_traits.html

Here's a suggestion:

When defining a custom family of pointers or references to be used with BI library, make sure the public static conversion functions accessed through the pointer_traits interface (*_cast_from and pointer_to) can properly convert between const and nonconst referred member types without the use of implicit constructor calls. It is suggested these conversions be implemented as function templates, where the template argument is the type of the object being converted from.

status changed; resolution set

Ion Gaztañaga — Mon, 15 Dec 2014 20:05:28 GMT

status new → closed
resolution → fixed

I added your proposal to the pointer_traits documentation:

SHA-1: 50f9f57f6cc3c6d4f8cfe1c5a2967e297ad487db

Documented pointer_traits according to Trac #10853 proposal

Thanks.