Re: [Boost-users] trying to build custom property_map

Subject: Re: [Boost-users] trying to build custom property_map
From: Jeremiah Willcock (jewillco_at_[hidden])
Date: 2010-04-01 17:24:27

On Thu, 1 Apr 2010, Sandeep Gupta wrote:

> 
> 
> On Thu, Apr 1, 2010 at 12:41 PM, Jeremiah Willcock <jewillco_at_[hidden]> wrote:
>       On Thu, 1 Apr 2010, Sandeep Gupta wrote:
>
>             It seems that the error occurs when I don't define   "typedef int& reference"
>             for the property map
>             class.  The confusing part is that when I compile with boost_1_42 I get the
>             error
>
>             boost_1_42_0/boost/property_map/property_map.hpp:33: error: no type named
>             'reference' in 'struct
>             VecMap'
>
>             Which is expected. However, If I compile against the trunk I get undefined
>             value_type error instead of
>             undefined reference error.
>
>             boost-trunk/boost/pending/disjoint_sets.hpp:65: error: no type named
>             'value_type' in 'struct
>             boost::property_traits<VecMap>'
>
>             Something surely is amiss here. Most likely in the disjoint_sets.hpp, I
>             believe.
>
>             Thanks
>             -Sandeep
> 
> 
> The behavior of property_traits changed in newer versions of Boost.  Now, nothing in
> property_traits is defined for a property map unless it has all four required members (key_type,
> value_type, category, and reference). Previously you would only get an error for those that were
> missing. This change was necessary so including Boost.Graph and Boost.Variant in the same program
> would work.
> 
> 
> I see. Although I would say this change introduces a non-friendly error message. It threw me
> out-of-the-loop to see the compiler complain about value_type when it was already defined. Would it be
> possible to emit error at the property_map level itself.

Unfortunately, the change was to work around a different issue -- there 
were some algorithms that took various types T as input and accessed 
property_traits<T>::value_type or whatever; when T was not actually a 
property map, property_traits wouldn't instantiate and so the code would 
be broken.  This was really bad because it happened whenever anyone 
included Boost.Variant and Boost.Graph together.  The fix was to make 
property_traits<T> empty when T is not a property map so that SFINAE will 
disable the inappropriate BGL algorithms, but that leads to the kinds of 
strange error messages you are getting when you intended something to be a 
property map but it didn't have all of the right members.

-- Jeremiah Willcock