Re: [Boost-users] [graph][spirit][variant] Boost.Graph and Boost.Spirit incompatible ?

Subject: Re: [Boost-users] [graph][spirit][variant] Boost.Graph and Boost.Spirit incompatible ?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2010-03-05 00:11:09

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_<is_property_map<PA>,
      default_property_traits<PA>,
      null_property_traits>::type
  {};

The other alternative is to make the second argument
of get fully generic.  This will guarantee it against errors, but
the downside is that it will match too much.

In Christ,
Steven Watanabe