[MultiIndex] Visual C++ 10 issue
Are there known problems with MultiIndex on the current VC++ 10 beta? I'm looking in particular at <URL:http://tinyurl.com/39bmudo>. The area around the line VC++ 10 has a problem with (line 276 of distributed_property_map.hpp, the error is on the &std::pair line) is: typedef multi_index::multi_index_container< std::pair<key_type, value_type>, multi_index::indexed_by< multi_index::sequenced<>, multi_index::hashed_unique< multi_index::member<std::pair<key_type, value_type>, key_type, &std::pair<key_type, value_type>::first> > > > ghost_cells_type; and the main error is (full instantiation stack in the link above): D:\boost-test\boost\boost/property_map/parallel/distributed_property_map.hpp(276) : error C2440: 'specialization' : cannot convert from 'boost::detail::parallel::global_descriptor<LocalDescriptor> std::_Pair_base<_Ty1,_Ty2>::* ' to 'boost::detail::parallel::global_descriptor<LocalDescriptor> std::pair<_Ty1,_Ty2>::* ' with [ LocalDescriptor=unsigned int, _Ty1=boost::detail::parallel::global_descriptor<unsigned int>, _Ty2=boost::detail::parallel::global_descriptor<unsigned int> ] Standard conversion from pointer-to-member of base to pointer-to-member of derived is not applied for template arguments What I don't see is where the pointer-to-member of _Pair_base comes from; is that the correct type for the address of a member that's actually from a base class? Or is this a compiler problem? -- Jeremiah Willcock
Sounds like the same problem as https://svn.boost.org/trac/boost/ticket/3594
On Mon, 10 May 2010, Richard Webb wrote:
Sounds like the same problem as https://svn.boost.org/trac/boost/ticket/3594
It seems like it is. Is the workaround that complicated, though? Is there a way to get some of that factored out to reuse in other Boost libraries? Would putting an explicit cast to ... std::pair::* in the template argument work instead? -- Jeremiah Willcock
Sounds like the same problem as https://svn.boost.org/trac/boost/ticket/3594
It seems like it is. Is the workaround that complicated, though? Is there a way to get some of that factored out to reuse in other Boost libraries? Would putting an explicit cast to ... std::pair::* in the template argument work instead?
BTW, did anyone try this with VC10 Release (not beta)?
On Mon, 10 May 2010, Igor R wrote:
Sounds like the same problem as https://svn.boost.org/trac/boost/ticket/3594
It seems like it is. Is the workaround that complicated, though? Is there a way to get some of that factored out to reuse in other Boost libraries? Would putting an explicit cast to ... std::pair::* in the template argument work instead?
BTW, did anyone try this with VC10 Release (not beta)?
The error I posted is from KTC-XP_VC10RTM, which looks like it is the RTM version. Or is the release version updated from the RTM version? -- Jeremiah Willcock
Jeremiah Willcock <jewillco <at> osl.iu.edu> writes:
BTW, did anyone try this with VC10 Release (not beta)?
The error I posted is from KTC-XP_VC10RTM, which looks like it is the RTM version. Or is the release version updated from the RTM version?
The release version has the same problem as the beta - the workarounds in both property tree and wave have been updated on Trunk to account for it.
On 10/05/2010 18:49, Jeremiah Willcock wrote:
The error I posted is from KTC-XP_VC10RTM, which looks like it is the RTM version. Or is the release version updated from the RTM version?
It is the release version of VS 2010 Pro. KTC -- Only two things are infinite, the Universe and Stupidity. And I'm not quite sure about the former. - Albert Einstein
Jeremiah Willcock escribió:
On Mon, 10 May 2010, Richard Webb wrote:
Sounds like the same problem as https://svn.boost.org/trac/boost/ticket/3594
It seems like it is. Is the workaround that complicated, though? Is there a way to get some of that factored out to reuse in other Boost libraries? Would putting an explicit cast to ... std::pair::* in the template argument work instead?
Hi Jeremiah, The problem is not a bug with VC++ 10, but a collateral effect of the way std::pair is implemented in the stdlib provided for this compiler --namely, by deriving from an implementation-specific _Pair_base class where the members are actually defined. This reduced test case can help explain the problem: struct base{int x;}; struct derived:base{}; template< class Class, typename Type, Type Class::*PtrToMember
struct member{}; typedef member<derived,int,&derived::x> member_t; The last typedef fails with "argument of type 'int base::*' is incompatible with template parameter of type 'int derived::*'" or something to that effect because x is defined in base rather than derived, so the type of &derived::x is actually int base::*, for which the standard conversion to int derived::* does not apply in the context of template argument matching, see 14.3.2 [temp.arg.nontype] paragraph 5: "[...] for a nontype template-parameter of type pointer to object, qualification conversions (4.4) and the array-to-pointer conversion (4.2) are applied. [Note: In particular, neither the null pointer conversion (4.10) nor the derived-to-base conversion (4.10) are applied. [...] ]" I don't really know the rationale behind the paragraph above, but this is the way things are. The workaround applied at https://svn.boost.org/trac/boost/ticket/3594 works, but it's probably overkill (and uses the objectionable member_offset, which is really meant to be used as a last resort for legacy compilers). A nicer workaround consists in providing a user-defined key extractor: template<typename First,typename Second> class pair_first_extractor { typedef std::pair<First,Second> value_type; public: typedef First result_type; const result_type& operator()(const value_type& x)const { return x.first; } result_type& operator()(value_type& x)const { return x.first; } }; typedef multi_index::multi_index_container< std::pair<key_type, value_type>, multi_index::indexed_by< multi_index::sequenced<>, multi_index::hashed_unique< pair_first_extractor<key_type, value_type> >
ghost_cells_type;
HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
On Tue, 11 May 2010, joaquin@tid.es wrote:
Jeremiah Willcock escribió:
On Mon, 10 May 2010, Richard Webb wrote:
Sounds like the same problem as https://svn.boost.org/trac/boost/ticket/3594
It seems like it is. Is the workaround that complicated, though? Is there a way to get some of that factored out to reuse in other Boost libraries? Would putting an explicit cast to ... std::pair::* in the template argument work instead?
Hi Jeremiah,
The problem is not a bug with VC++ 10, but a collateral effect of the way std::pair is implemented in the stdlib provided for this compiler --namely, by deriving from an implementation-specific _Pair_base class where the members are actually defined. This reduced test case can help explain the problem:
Could this be viewed as a library issue, then, or is the type of &std::pair<a, b>::first not considered to be part of the library's interface? It does seem bad that any use of pointers-to-members is fragile to the use of mixins or hidden base classes as part of a class's implementation. (snip)
The workaround applied at https://svn.boost.org/trac/boost/ticket/3594 works, but it's probably overkill (and uses the objectionable member_offset, which is really meant to be used as a last resort for legacy compilers). A nicer workaround consists in providing a user-defined key extractor:
template<typename First,typename Second> class pair_first_extractor { typedef std::pair<First,Second> value_type;
public: typedef First result_type;
const result_type& operator()(const value_type& x)const { return x.first; }
result_type& operator()(value_type& x)const { return x.first; } };
typedef multi_index::multi_index_container< std::pair<key_type, value_type>, multi_index::indexed_by< multi_index::sequenced<>, multi_index::hashed_unique< pair_first_extractor<key_type, value_type>
ghost_cells_type;
OK. Should that code (for std::pairs) be part of multi_index anywhere? It would seem like other users would use parts of pairs as keys. Otherwise, can I copy your code into BGL (under the Boost license)? Also, would just a simple cast on the pointer-to-member type work, or are those not allowed in non-type template arguments? -- Jeremiah Willcock
Jeremiah Willcock <jewillco <at> osl.iu.edu> writes:
On Tue, 11 May 2010, joaquin <at> tid.es wrote:
Jeremiah Willcock escribió:
On Mon, 10 May 2010, Richard Webb wrote:
Sounds like the same problem as https://svn.boost.org/trac/boost/ticket/3594
[...]
Hi Jeremiah,
The problem is not a bug with VC++ 10, but a collateral effect of the way std::pair is implemented in the stdlib provided for this compiler --namely, by deriving from an implementation-specific _Pair_base class where the members are actually defined. This reduced test case can help explain the problem:
Could this be viewed as a library issue, then, or is the type of &std::pair<a, b>::first not considered to be part of the library's interface? It does seem bad that any use of pointers-to-members is fragile to the use of mixins or hidden base classes as part of a class's implementation.
I'm sure there must be valid reasons for the restrictons posed by 14.3.2/5 but I can't see them. I posted about the issue in comp.std.c++ some years ago alas the response was nearly null: http://tinyurl.com/32cdmk8 I might try posting again.
The workaround applied at https://svn.boost.org/trac/boost/ticket/3594 works, but it's probably overkill (and uses the objectionable member_offset, which is really meant to be used as a last resort for legacy compilers). A nicer workaround consists in providing a user-defined key extractor:
[...]
OK. Should that code (for std::pairs) be part of multi_index anywhere? It would seem like other users would use parts of pairs as keys.
I don't feel comfortable with providing such custom key extractors (where should we finish once we start down this path?) On the other hand, specializing boost::multi_index::member when Class is a std::pair might be a good idea. I'll add it to my "to consider" list.
Otherwise, can I copy your code into BGL (under the Boost license)?
Sure, use it freely. You might want to use the specialization variant in anticipation to Boost.MultiIndex providing this specialization itself in the future.
Also, would just a simple cast on the pointer-to-member type work, or are those not allowed in non-type template arguments?
That wouldn't work, you can't cast that way in that context. But if you don't mind coupling with VC++ 10 stdlib implementation details you can just use boost::multi_index::member< std::_Pair_base<key_type,value_type>, key_type, std::_Pair_base<key_type,value_type>::first
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (6)
-
Igor R -
Jeremiah Willcock -
Joaquin M Lopez Munoz -
joaquin＠tid.es
-
KTC -
Richard Webb