Subject: [Boost-bugs] [Boost C++ Libraries] #10853: problem with detection of const_cast_from
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2014-12-05 01:02:02
#10853: problem with detection of const_cast_from
-----------------------------------+------------------------
Reporter: Matei David <matei@â¦> | Owner: igaztanaga
Type: Bugs | Status: new
Milestone: To Be Determined | Component: intrusive
Version: Boost 1.57.0 | Severity: Problem
Keywords: |
-----------------------------------+------------------------
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.
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/10853> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:17 UTC