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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk