Geometry Boost List: Re: [geometry] Report not yet implemented feature at runtime

Subject: Re: [geometry] Report not yet implemented feature at runtime
From: Mats Taraldsvik (mats.taraldsvik_at_[hidden])
Date: 2015-03-13 07:19:42

> -----Opprinnelig melding-----
> Fra: Geometry [mailto:geometry-bounces_at_[hidden]] På vegne av
> Samuel Debionne
> Sendt: 13. mars 2015 11:53
> Til: Boost.Geometry library mailing list
> Emne: Re: [geometry] Report not yet implemented feature at runtime
> 
> An alternative to Variant could be type erasure.
> 
> Before trying out this solution, has someone already try to use
> Boost.TypeErasure to implement, for example, any_point<> ?
> 
> More generally, if input types can vary at runtime (for example, if they
> depend on user input), is there any recommended solution for
> Boost.Geometry user ?
> 

Just a heads up from a Boost.Geometry user. :)

I think that using type erasure might be a good approach.

Boost.Geometry already uses boost::concepts, which will be adopted into the C++ standard/TS with Concepts Lite.  Andy Prowl proposed(1) virtual concepts, which is a runtime (type erased) concept, which corresponds to boost::type_erasure.

There is a rumour that Andrew Sutton is also working on virtual concepts, like Andy Prowl proposed, so we might get this into a future standard/TS as well.

Therefore, using type erasure with boost::type_erasure might be a sound approach that complements the existing concepts-driven architecture in boost.geometry. 

(1) https://groups.google.com/a/isocpp.org/d/topic/std-proposals/4gEt2OBbSQM/discussion 

Regards,
Mats Taraldsvik

> 
> Le 09/03/2015 18:58, Samuel Debionne a écrit :
> > Hi,
> > The rational of this proposed feature is the following (pseudo code) :
> >
> > variant<point_xy, point_xyz, polygon_xy, polygon_xyz> geometries_t;
> > geometries_t a, b;
> >
> > bg::within(a, b);
> >
> > With the present implementation this code would not compile since
> > within() is not implemented for all the combinations of the bounded
> > types of the variant (not_implemented uses MPL_ASSERT to report this
> > error at compile time).
> >
> > The following proposal introduce an other mechanism to report
> > incompatible type (or not yet implemented features) at runtime and is
> > prototyped here :
> >
> >
> https://github.com/boostorg/geometry/compare/develop...sdebionne:feat
> u
> > re/nyi_runtime_error
> >
> > The specifications are :
> >
> > - maintain backward compatibility (default to compile time error)
> > - specialization on a per algorithm basis and per compile unit
> > (meaning that some part of the applications may use compile time
> > errors while other part may use runtime errors)
> > - should be quite easy to adapt the existing algorithm (see the
> > example with within)
> >
> > I can't think of a solution to implement this as a pure extension (e.g.
> > without modifying the core library). In short, this is what I have in mind :
> >
> > An algorithm should be identified by an "algorithm tag" (this could be
> > extended to strategies as well) :
> >
> > BOOST_GEOMETRY_REGISTER_ALGORITHM(within)
> >
> > At the dispatch stage, the algorithm inherit from the new
> > not_implemented<> interface that takes the algorithm tag as first
> > template parameter :
> >
> > template <...>
> > struct within
> >   : not_implemented<within_tag, Tag1, Tag2>
> >   {};
> >
> > Finally, in the code that invokes the algorithm, set whether to use
> > runtime errors:
> >
> > // Enable runtime errors
> > BOOST_GEOMETRY_NYI_RUNTIME_ERROR(within_tag)
> >
> > try {
> >   bg::within(a, b);
> > } catch (bg::not_implemented_runtime_error& ex) {
> >   std::cerr << ex.what() << " is not yet implemented."
> > }
> >
> > Is there any interest in this feature?
> > _______________________________________________
> > Geometry mailing list
> > Geometry_at_[hidden]
> > http://lists.boost.org/mailman/listinfo.cgi/geometry
> >
> 
> _______________________________________________
> Geometry mailing list
> Geometry_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/geometry