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
struct foo_bgl_named_params : boost::bgl_named_params
{
typedef boost::bgl_named_params 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
my_property_map(const PMap& p) const
{
typedef foo_bgl_named_params Params;
return Params(p, *this);
}
};
// the respective free functions...
template <typename PMap>
foo_bgl_named_params
my_property_map(const Pmap& p) const
{
typedef foo_bgl_named_params Params;
return Params(p);
}
// partial specialization for lookup_named_param_def
namespace boost {
template
struct lookup_named_param_def, Def> {
typedef T type;
static const type& get(const bgl_named_params& p, const Def&) {
return p.m_value;
}
};
template
struct lookup_named_param_def, Def> {
typedef typename lookup_named_param_def::type type;
static const type& get(const bgl_named_params& p, const Def& def) {
return lookup_named_param_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
