Boost logo

Boost :

Subject: Re: [boost] Boost.Convert and ADL [was: GGL review]
From: Barend Gehrels (barend_at_[hidden])
Date: 2009-11-09 08:41:15

Hi Vicente,

I promised to react on this part:

> Recently I have added some stuff to take care of ADL in the
> Boost.Conversion library base on the Boost.Swap library. The idea been
> to define a function that calls an internal function introdicing the
> default behavior by ADL. Thus when the user has provided some
> functions found by ADL they will take precedence as more specific.
> When not found the introduced default behavion take place.
> Next follows how I have defined convert_to:
> namespace boost {
> // trick to ensure specialization is always possible
> namespace dummy {
> template <typename T> struct base_tag {};
> template <typename T> struct type_tag : public base_tag<T> {};
> }
> // default behavior ussin gthe specialized tag type_tag
> namespace conversion {
> namespace partial_specialization_workaround {
> template < typename To, typename From >
> struct convert_to {
> inline static To apply(const From& val)
> {
> return To(val);
> }
> };
> }
> template < typename To, typename From >
> To convert_to(const From& val, dummy::type_tag<To> const&) {
> return
> conversion::partial_specialization_workaround::convert_to<To,From>::apply(val);
> }
> }
> // specialized implementation namespace conversion_impl {
> template <typename Target, typename Source>
> Target convert_to_impl(Source const& from) {
> using namespace boost::conversion;
> //use boost::conversion::convert_to if ADL fails
> return convert_to(from,
> boost::dummy::type_tag<Target>());
> }
> }
> // generic function calling to the ADL introduction
> template <typename Target, typename Source>
> Target convert_to(Source const& from,
> boost::dummy::base_tag<Target> const&
> p=boost::dummy::base_tag<Target>()) {
> return conversion_impl::convert_to_impl<Target>(from);
> }
> }
> Note that using the dummy trick we ensure that there are no infinite
> cycles. The default behavior could correspond to what you have already
> done.
> If there is nothing wrong on my design, do you think that this could
> be also applied to the GGL library at least for the concepts?

I assume this does not have anything to do with SFINAE?

I like the idea of this conversion library and I think it is also
applicable to geometry. Actually we have a "convert" function which
converts e.g. a box to a polygon (so from min/max go to a polygon with
the points of the box). So if Boost has a generic convert_to function,
we're happy to support geometries there.

After reading your documentation I tried your code to my "fruit"
test-classes for sfinae/tag dispatching, and was able to convert apples
to pears. Tried it using two ways, one using the
partial_specialization_workaround, one overloading the convert_to with
the dummy-tag. Added namespace to check ADL and all is working nicely.

To refer to your question. "At least for the concepts", you probably
mean the geometry concepts. Adapting geometries to concepts is not done
using free functions. It is implemented using traits classes they should
be implemented in namespace ggl::traits.

If you refer to the algorithms, like area, yes, I think it could be done
like this in GGL, also combined with tag dispatching. But it is
currently not done like this. Example c04_a and c04_b show how
functionality can be overriden by specializing either the function or
(partly) specializing the dispatch structure. This is all in namespace
GGL. You're adding a possibility to be able to specialize in your own
namespace, and I think it would be feasable, though I'm not sure if it
is really expected.

Regards, Barend

Boost list run by bdawes at, gregod at, cpdaniel at, john at