Instead of having the return type wrapped in a `Needs_FT` tag,
not the call operator overloads that can be called with `RT` are
"tagged" by adding a last argument of type `RT_sufficient` with a
default value.
This commit introduces a new kind of predicate in
`<CGAL/Kernel/interface_macros.h>`. In addition to
- `CGAL_kernel_pred` for predicates,
- `CGAL_Kernel_pred_RT` for predicates that can be implemented using a
ring-type,
now there is also:
- `CGAL_Kernel_pred_RT_or_FT` for predicates with multiple overloads of
`operator()`, some needing a field type and other needing a ring type
(without the division operator).
The C++ code can discriminate between the two cases with a special wrapper
for the return type: `CGAL::Needs_FT<result_type` instead of `result_type`
(defined in `<CGAL/tags.h>`.
In `<CGAL/Filtered_predicate.h>`, in addition to the usual class template
`Filtered_predicate`, there is now also `Filtered_predicate_RT_FT` that
takes three predicates as template parameters instead of two:
- the exact predicate with an ring-type,
- the exact predicate with a field-type,
- the approximate predicate (with `Interval_nt` as number-type).
For the moment, only `Compare_distance_3` in
`<CGAL/Cartesian/function_objects.h>` is using the new
`Filtered_predicate_RT_FT`.
Before this commit, the file
`Kernel_23/test/Kernel_23/include/CGAL/_test_new_3.h` was testing
`Compare_distance_3` only with three points or for points. This commit adds:
- a test with `Point_3, Point_3, Segment_3`, and
- a test with `Line_3, Point_3, Point_3`, that actually needs a field type
with its current implementation.
In the test `Kernel_23/test/Kernel_23/Filtered_cartesian.cpp`, the macro
`CGAL_NO_MPZF_DIVISION_OPERATOR` is defined, to remove the division operator
from `CGAL::Mpzf`. `CGAL::Mpzf` is a ring-type, even with its `operator/`
(because that `operator/` can only compute exact divisions), but with
`CGAL_NO_MPZF_DIVISION_OPERATOR` defined, that is now checked by the compiler.
right after the merge of 4.14 release branch
+ manual fix on one line in:
* Arrangement_on_surface_2/include/CGAL/IO/Arr_text_formatter.h
* .travis/generate_travis.sh
possibly will return true in case the evaluation lead to true or false
as possible values. If the exact value is computed or interval refined,
false could be the true value which has a consequence will give a
different result for point or base vector.
Laurent Rineau