[graph] Extending bgl_named_params
Hi, I maintain a library that introduces its own graph properties for domain specific algorithms and provides it's own implementation of bgl_named_parameters by essentially mimicking bgl_named_parameters one-to-one. With the refactoring in 1.51 that implementation broke and I had to add another implementation of named parameters which essentially looks like this: enum my_property_t { my_property }; template <typename T, typename Tag, typename Base = boost::no_property> struct foo_bgl_named_params : boost::bgl_named_params<T, Tag, Base> { typedef boost::bgl_named_params<T, Tag, Base> base; typedef foo_bgl_named_params self; foo_bgl_named_params(T v = T()) : base(v) {} foo_bgl_named_params(T v, const Base& b) : base(v, b) {} template <typename PMap> foo_bgl_named_params<PMap, my_property_t, self> my_property_map(const PMap& p) const { typedef foo_bgl_named_params<PMap, my_property_t, self> Params; return Params(p, *this); } }; // the respective free functions... template <typename PMap> foo_bgl_named_params<PMap, my_property_t, self> my_property_map(const Pmap& p) const { typedef foo_bgl_named_params<PMap, my_property_t, self> Params; return Params(p); } // partial specialization for lookup_named_param_def namespace boost { template <typename T, typename Tag, typename Base, typename Def> struct lookup_named_param_def<Tag, foo_bgl_named_params<T, Tag, Base>, Def> { typedef T type; static const type& get(const bgl_named_params<T, Tag, Base>& p, const Def&) { return p.m_value; } }; template <typename Tag1, typename T, typename Tag, typename Base, typename Def> struct lookup_named_param_def<Tag1, foo_bgl_named_params<T, Tag, Base>, Def> { typedef typename lookup_named_param_def<Tag1, Base, Def>::type type; static const type& get(const bgl_named_params<T, Tag, Base>& p, const Def& def) { return lookup_named_param_def<Tag1, Base, Def>::get(p.m_base, def); } }; } // boost This is brittle because it the type returned by the inherited functions is not the same and chaining will not work if one of those functions is called first, e.g. all custom properties have to be chained together first.
From the documentation it is not really obvious to me if other libraries are even supposed to provide their own properties and how/if they actually should be able to extend the named parameters API.
Is that simply not an intended feature of the BGL or can that be done differently? Cheers, Philipp
On Mon, 22 Oct 2012, Philipp Moeller wrote:
Hi,
I maintain a library that introduces its own graph properties for domain specific algorithms and provides it's own implementation of bgl_named_parameters by essentially mimicking bgl_named_parameters one-to-one. With the refactoring in 1.51 that implementation broke and I had to add another implementation of named parameters which essentially looks like this:
(snip)
From the documentation it is not really obvious to me if other libraries are even supposed to provide their own properties and how/if they actually should be able to extend the named parameters API.
Is that simply not an intended feature of the BGL or can that be done differently?
Nothing about the named parameter mechanism is documented, and it should be replaced by Boost.Parameter sometime in the future. You should be able to add your own parameters by just replicating the (multiple) definitions of BOOST_BGL_ONE_PARAM_CREF from <boost/graph/named_function_params.hpp> and applying them to your parameter keys. The last couple of those definitions are only needed if you want to use Boost.Parameter as your parameter handling mechanism with BGL named parameters provided for compatibility (see <boost/graph/depth_first_search.hpp> for an example of that). -- Jeremiah Willcock
participants (2)
-
Jeremiah Willcock
-
Philipp Moeller