On Wed, 31 Mar 2010, Sandeep Gupta wrote:

Hi,  I created a  simple property_map as follows:

struct VecMap {  typedef int value_type;

 typedef int key_type;  typedef  read_write_property_map_tag category;

 typedef int* reference;  std::vector<int> vec_store;

}; void put(VecMap& rmap, int key, int val)

{  rmap.vec_store[key] = val;

} int get(VecMap& rmap, int key)

{  return rmap.vec_store[key];

} /// End code The compiler gcc-4.4.1 against latest boost-trunk gives errorerror: no type named value_type in struct boost::property_traits<VecMap> The code however compiles fine with boost_1_40. Please take a look. The full code is available here http://codepad.org/KtmbXkLa

I tried the code you posted (at codepad) with GCC 3.4, 4.1, and 4.4.0 and did not receive an error.  Note that in the trunk, the property_map header file is .

-

The posted code works with earlier version of boost. However when I change the header to boost/property_map/property_map.hpp and use boost-trunk that it start giving errors. I compiled against gcc 4.4.1, 4.4 and 4.2. It gives the same  error for all the three.

I changed the code to use the new header file and compiled against the trunk and still don't get any errors. What errors are you seeing (i.e., the full gcc output)? -- Jeremiah Willcock

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. -- Jeremiah Willcock

On Thu, 1 Apr 2010, Sandeep Gupta wrote:

On Thu, Apr 1, 2010 at 12:41 PM, Jeremiah Willcock 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