Boost logo

Geometry :

Subject: Re: [geometry] Run-Time specified geometries
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2013-10-24 10:59:22

On 24 October 2013 15:48, Samuel Debionne
<samuel.debionne_at_[hidden]> wrote:
>>> The main difficulty I have encountered with dynamic
>>> algorithms is that there are instantiated with every possible type the
>>> variant can take. Some kind of filtering (e.g. types should have same
>>> dimensions) using traits and tag dispatching must be in place within the
>>> variant visitor. The other difficulty is with the return type that may
>>> depends on the input types, but no meta function (think result_of) is
>>> available.
>> Yes, so all possible instances need to be available.
> Is there a way with the current implementation to know what
> specialization of an algorithm is available, i.e. which combinations of
> template arguments (geometry types) do not lead to the MPL assert
> Right now I'm using my own MPL metafunction "is_implemented" in my
> variant visitors but it's not very practical :
> [...]

Sorry, my time is too short now to check your code in details, perhaps
someone else will comment on that.

Meanwhile, you may check the support_status generator

Here is my slightly modified version with plain-text/pretty-printed output

> Finally I'm wondering if SFINAE could be of any help...

Boost.Geometry tries to avoid SFINAE:

By the way, just noticed Bruno has made a few more algorithms variant-aware:

r86414 | bruno.lalande | 2013-10-24 07:10:34 +0100 (Thu, 24 Oct 2013) | 1 line

Made 'correct' variant-aware.
r86401 | bruno.lalande | 2013-10-23 11:13:28 +0100 (Wed, 23 Oct 2013) | 1 line

Converted convex_hull to the multi-stage approach and made it variant-aware.

Bruno, thanks for this work!

Best regards,

Mateusz  Loskot,

Geometry list run by mateusz at