Re: [boost] [geometry] view_as concept casting

Subject: Re: [boost] [geometry] view_as concept casting
From: David Abrahams (dave_at_[hidden])
Date: 2009-01-08 11:33:04

on Thu Jan 08 2009, Barend Gehrels <barend-AT-geodan.nl> wrote:

> Hi Luke,
>
> I don't think we have addressed exactly the same thing, but something
> similar. We check geometry types at compile time, indeed using a generic
> geometry type system.
> Area calculation, for example, is implemented differently for box
> (rectangle) than for polygon. So we have two overloads:
>
> template <typename B> double area(const B& box)
> {...}
> template <typename P> double area(const P& polyon)
> {...}
>
> This alone leads to ambiguities of course. Therefore we use enable_if:
> template <typename B> double area(const B& box,
>    typename boost::enable_if_c<geometry_type<B>::type
>         == TYPE_BOX>::type*  = 0)
> template <typename P> double area(const P& polyon,
>     typename boost::enable_if_c<geometry_type<P>::type
>         == TYPE_POLYGON>::type*  = 0)
>
> This works perfectly and distinguishes all geometry types at compile
> time, as long as the library or the developer provides the meta function
> geometry_type<T>::type which is currently implemented as an enumeration
> of TYPE_POINT, etc.

Seems like you might be better off using tag dispatching... or something
like

http://article.gmane.org/gmane.comp.lib.boost.devel/120718
http://article.gmane.org/gmane.comp.lib.boost.devel/120728

> Furthermore, you mention:  "concept checking boilerplate around bool
> return type goes here". We've encountered problems with the concept
> checking on return types. The combination of BCCL and overloads based on
> SFINAE gives compiler problems here. We therefore use
> BOOST_CONCEPT_REQUIRES instead of _ASSERT in such cases.

I think you mean the opposite, right?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com