Boost C++ Libraries: Ticket #7378: lookup_one_property fails if property tag not found

attachment set

Fri, 14 Sep 2012 15:42:37 GMT

attachment → example.cpp

demonstration code

status, component changed; resolution set

Jeremiah Willcock — Fri, 14 Sep 2012 15:45:53 GMT

status new → closed
resolution → wontfix
component property_map → graph

That change was made on purpose; it greatly helps error messages for using nonexistent property maps from graphs.

attachment set

Fri, 14 Sep 2012 15:45:56 GMT

attachment → property.hpp.patch

patch

Fri, 14 Sep 2012 15:52:52 GMT

Replying to jewillco:

That change was made on purpose; it greatly helps error messages for using nonexistent property maps from graphs.

Is there another way of checking the existence of some particular property tag then?

Jeremiah Willcock — Fri, 14 Sep 2012 15:57:08 GMT

Look at lookup_one_property<...>::found. That takes a property list and a tag and determines if the property is present in the list. That doesn't give an easy way to test a graph for a given property, though.

anonymous — Fri, 14 Sep 2012 16:01:38 GMT

That's what I thought, but lookup_one_property<...>::found is not false if the tag is not found, instead it just results in a compiler error.

Jeremiah Willcock — Fri, 14 Sep 2012 16:03:40 GMT

What triggers the error in that case?

Fri, 14 Sep 2012 16:06:03 GMT

That's what I reported in this bug report. Or am I missing something?

Fri, 14 Sep 2012 17:55:51 GMT

The problem is that in the enable_if of the lookup(...) member function

template <typename Tag, typename T, typename Base, typename PropName>
  struct lookup_one_property_internal<boost::property<Tag, T, Base>, PropName>: lookup_one_property_internal<Base, PropName> {
    private:
    typedef lookup_one_property_internal<Base, PropName> base_type;
    public:
    template <typename PL>
    static typename enable_if<is_same<PL, boost::property<Tag, T, Base> >, typename base_type::type&>::type
    lookup(PL& prop, const PropName& tag)

typename base_type::type& does not depend on the template parameter of the template member function but only on the template parameters of the class. Therefore base_type::type is required to exist, even if lookup(...) is not used (or the enable_if<...> disables the function).

A solution could be to add a indirection which depeneds on PL, like

 template <class First, class Second>
 struct second_type {
     typedef Second type;
 };
...
    static typename enable_if<is_same<PL, boost::property<Tag, T, Base> >, typename second_type<PL,base_type>::type::type&>::type
    lookup(PL& prop, const PropName& tag)

which will prevent the compiler from resolving base_type::type unless lookup(...) is explicitly instantiated.

This way the general template lookup_one_property_internal does not need to define a type member to use lookup_one_property<...>::found.

But I have to admit that this solution looks a little ugly.

Jeremiah Willcock — Fri, 14 Sep 2012 18:04:04 GMT

(In [80524]) Added void as default value of lookup_one_property_internal::type for "not found"; refs #7378

status changed; resolution deleted

Fri, 14 Sep 2012 21:29:02 GMT

status closed → reopened
resolution wontfix

This was also my first approach, but unfortunately it doesn't solve the problem.

Since the return type of lookup(...) is type& the compiler will complain if type is void, as you can see if you try to compile my example code.

status changed; resolution set

Jeremiah Willcock — Fri, 14 Sep 2012 21:41:09 GMT

status reopened → closed
resolution → fixed

(In [80528]) Using lazy_enable_if to avoid "reference to void" errors for properties that are not found; fixes #7378

Sat, 15 Sep 2012 11:50:06 GMT

Great! That solved the problem. I totally forgot about lazy_enable_if...

Could you also apply the same fix to struct lookup_one_property<const T, Tag> in line 159 of the same file?

Thanks for fixing the problem so quickly! :)

Jeremiah Willcock — Sat, 15 Sep 2012 13:49:06 GMT

(In [80532]) Further fixed #7378 issue; refs #7378