AMDG Jeremiah Willcock wrote:
On Thu, 4 Mar 2010, Steven Watanabe wrote:
Jeremiah Willcock wrote:
I looked at changing the key_type in get to something that would SFINAE out and there isn't one: the farthest I could go is property_traits<IndexMap>::value_type (key_type in the code is a bug), and that class will fail to instantiate (non-SFINAE) on bad index map types. That can be specialized, so I can't fall back to the default definition of value_type inside it. I don't see a general-purpose solution to problem right now.
Would this break anything?
template<typename PA> struct property_traits : PA {};
That plus changing two_bit_property_map to use it passes the BGL, PBGL, and property_map test cases. Does it work to fix all of the known variant problems?
I thought at first that it would, but unfortunately not.
Suppose that the argument is a built-in type...
So, here's try #2 at making property_traits usable
for SFINAE (untested).
BOOST_MPL_HAS_XXX_TRAIT_DEF(key_type);
BOOST_MPL_HAS_XXX_TRAIT_DEF(value_type);
BOOST_MPL_HAS_XXX_TRAIT_DEF(reference);
BOOST_MPL_HAS_XXX_TRAIT_DEF(category);
template<class PA>
struct is_propery_map :
boost::mpl::and_<
has_key_type<PA>,
has_value_type<PA>,
has_reference<PA>,
has_category<PA>
>
{};
template <typename PA>
struct default_property_traits {
typedef typename PA::key_type key_type;
typedef typename PA::value_type value_type;
typedef typename PA::reference reference;
typedef typename PA::category category;
};
struct null_property_traits {};
template <typename PA>
struct property_traits :
boost::mpl::if_