Boost logo

Geometry :

Subject: Re: [geometry] Run-Time specified geometries
From: Samuel Debionne (samuel.debionne_at_[hidden])
Date: 2013-12-02 06:41:08

Hello Bruno,

Sorry for reopening this thread after such a long time.

> Nope, if a compile-time choice must be made about how to handle invalid
> algorithm invocation, IMO it has to be done within the "not_implemented"
> class itself. For compile-time failure, it would be just like it is now.
> For runtime failures, it would have to define a generic apply() function
> that throws.

I agree that it would be much better to handle static/runtime error
handling in a common place such as the "not_implemented" class.

Lately, I have been trying to implement such a "generic apply()
function that throws" in the not_implemented class. The main issue is
the return type deduction. I cannot see a mechanism to deduce the return
type at this high level without changing the interface of
not_implemented that would impacts all the underlying algorithm

To remind about the context :

    typename Term1 = void,
    typename Term2 = void,
    typename Term3 = void
struct not_implemented
    : nyi::not_implemented_tag
    //generic apply here

What kind of Concept Term1, Term2, Term3 are expected to comply ?

Strategy seems to implement a services::return_type<Stragegy> traits
that could be a good starting point. I guess they should also be
overloaded for combination of types that are not implemented (and return

I you have any idea about a solution, I'd appreciate.

Geometry list run by mateusz at