Re: [boost] [multi_index] Problems with chained pointers in multi index from 1.34 RC
Hello Alexei, thank you for testing the RC branch before it's out, this certainly helps ship a more robust library! ----- Mensaje original ----- De: Alexei Alexandrov <alexei.alexandrov@gmail.com> Fecha: Miércoles, Abril 12, 2006 6:15 pm Asunto: [boost] [multi_index] Problems with chained pointers in multi index from 1.34 RC
Hi,
my multi_index use case: * The container contains not objects themselves, but pointers (shared_ptr-s). * The objects are noncopyable - they are created by a factory and only smart pointers are copied between clients. * The container has 2 indexes. Indexes are built on const_mem_fn extractor. One of the indexes uses a function from a base class.
It seems that in 1.34 problem with using member function from a base class is supposed to be solved, but it causes a regression that you cannot have pointers to noncopyable objects in the container. Is this a known issue?
No, it is not. Alas I'm rather computer-disabled until next week, so I can't directly try to reproduce the problem, in the meantime I'd be very greateful if you can provide more info on the following: 1. What is the compiler error you're getting? 2. The difference between 1.33.1 and 1.34 is that one of the overloads inside const_mem_fun is now restricted by means of boost::disable_if: typename disable_if< is_convertible<const ChainedPtr,const Class>,Type>::type operator()(const ChainedPtr& x)const { return operator()(*x); } Now, from what you report, seems the restriction is being too much comprehensive. Could you test what is the value of boost::is_convertible< const name_record::Ptr, const name_record
::value
on your compiler? If this evaluates to true (or fails to compile), then we've got both an explanation for the problem and a serious issue with boost::is_convertible. I've googled for "is_convertible noncopyable" and found some references about problems with using is_convertible on non-copyable types, but the references are too vague and distant in the past to consider worth referring to. Again, thank you for using Boost.MultiIndex and being such an early tester of the RC branch. Looking fwd to getting your feedback wrt to the questions above. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
JOAQUIN LOPEZ MU?Z <joaquin <at> tid.es> writes:
1. What is the compiler error you're getting?
Now, from what you report, seems the restriction is being too much comprehensive. Could you test what is the value of
boost::is_convertible< const name_record::Ptr, const name_record
::value
on your compiler?
No, this thing compiles and expands to false as expected. In fact, the error I'm getting is about boost/boost/type_traits/is_convertible.hpp(254): error: class "name_record" has no suitable copy constructor BOOST_STATIC_CONSTANT(bool, value = ^ detected during: instantiation of class "boost::detail::is_convertible_basic_impl<From, To> [with From=boost::detail::is_convertible_impl<const name_record, const name_record>::ref_type, To=const name_record]" at line 286 instantiation of class "boost::detail::is_convertible_impl<From, To> [with From=const name_record, To=const name_record]" at line 362 instantiation of class "boost::detail::is_convertible_impl_dispatch<From, To> [with From=const name_record, To=const name_record]" at line 409 instantiation of class "boost::is_convertible<From, To> [with From=const name_record, To=const name_record]" at line 59 of "D:\src\3rd- parties\boost/boost/utility/enable_if.hpp" and can be reproduced with bool br = boost::is_convertible< const name_record, const name_record >::value; It fails to compile as well. It seems that is_convertible doesn't handle noncopyable target type well. I believe that this is because they use SFINAE for the check and the try-a-conversion function has the argument by value template <typename From, typename To> struct is_convertible_basic_impl { static ::boost::type_traits::no_type BOOST_TT_DECL _m_check(...); static ::boost::type_traits::yes_type BOOST_TT_DECL _m_check(To); static From _m_from; and compiler fails to pass the argument by value.
participants (2)
-
Alexei Alexandrov -
JOAQUIN LOPEZ MU?Z