[Boost-bugs] [Boost C++ Libraries] #10853: problem with detection of const_cast_from

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