|
Geometry : |
Subject: [geometry] Report not yet implemented feature at runtime
From: Samuel Debionne (samuel.debionne_at_[hidden])
Date: 2015-03-09 13:58:40
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:feature/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 list run by mateusz at loskot.net