id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
10853,problem with detection of const_cast_from,Matei David <matei@…>,Ion Gaztañaga,"According to the documentation for the `boost::intrusive::pointer_traits` non-standard extensions, `pointer_traits<Ptr>::const_cast_from(const UPtr&)` should try to call `Ptr::const_cast_from(const UPtr&)` if it exists, or else use a default. It seems to me that this process fails with compilation error (not only misdetection) when `const_cast_from()` is a plain static function inside `Ptr`, as opposed to a function template. To trigger this process and the compilation error, use e.g. `front()` on an intrusive list.

For an example demonstrating this, look at `test/bounded_pointer.hpp` in the boost intrusive git repo. There, `const_cast_from` is a template:
{{{
template<class U> static bounded_pointer const_cast_from(const bounded_pointer<U> &)
}}}
For me (`gcc-4.9.2`, `clang-3.4`), the compilation fails if the signature is changed to:
{{{
static bounded_pointer const_cast_from(const bounded_pointer<const_val_t> &)
}}}
For a real program showing this, use the non-dummy version of `test/test_list.cpp`. (I don't understand why it was commented out.) To clarify, the problem has nothing to do with `bounded_pointer`, that's just an existing file demonstrating it.

Digging a bit into this issue, it appears that the problem is with the mechanism used to detect the presence `const_cast_from()` inside `Ptr`. That mechanism is in `boost/intrusive/detail/has_member_function_callable_with.hpp`. In my case, the error comes from line 200 of that file, saying that the call to `const_cast_from` is ambiguous: one candidate is the real function, the other candidate is the dummy declared on line 191. I believe the whole point is for overload resolution to prefer the real function to the dummy, which doesn't happen in this case.",Bugs,closed,To Be Determined,intrusive,Boost 1.57.0,Problem,fixed,,