<CGAL/Kernel/Cartesian_coordinate_iterator_2.h>
<CGAL/Kernel/Cartesian_coordinate_iterator_3.h>
To:
<CGAL/Filtered_kernel/Cartesian_coordinate_iterator_2.h>
<CGAL/Filtered_kernel/Cartesian_coordinate_iterator_3.h>
det2x2_by_formula
det3x3_by_formula
det4x4_by_formula
det5x5_by_formula
det6x6_by_formula
to:
determinant
How cute... a name independent of the dimension, and even readable !
sign_of_determinant2x2
sign_of_determinant3x3
sign_of_determinant4x4
sign_of_determinant5x5
sign_of_determinant6x6
to:
sign_of_determinant
So that we have less dimension-dependent namings, at least internally...
as the default is now the empty string "".
It should fix the problem that we have lost the assertion messages
(seeing "what(): basic_string::_S_construct NULL not valid" instead),
for packages that use package-specific assertion macros.
* CGAL_error to CGAL_error_msg
* introduced a macro CGAL_error()
* added some words about CGAL_error to the developers manual
* renamed most of assert(x) into CGAL_assertion(x)
* renamed exit(x) with x != 0 , CGAL_assertion(false) and assert(false) into CGAL_error
* CORE left untouched, OpenNL changed
of "forwarding constructors".
Quoting some comment in the code:
"
This is a simple tag which is used as additional (first) argument in
some kernel functors, to tell them to return the base (rep) class,
instead of the main type (e.g. Kernel_base::Point_2 instead
of Kernel::Point_2). This is a minor optimization which prevents
useless copies of the "reps".
Those functors are only those used in the constructors of the kernel
types like Point_2, so it's limited.
The real solution will be to use "forwarding constructors", when they
will be available in C++.
In the mean time, this should be a mostly/hopefully internal hack.
"
Construct_point_2 functors be the Rep class (the base).
This avoids conversions Rep -> Point_2 -> Rep, hence
useless copies of objects.
The result_type of the functors does not change
(we therefore return a type which is only convertible
to result_type, but hopefully this is fine, and what standard
requirements on functors are anyway).
A real fix for this would require the language addition of
"forwarding constructors".