That is a follow-up to the following commit:
> commit 6b51b12ab5
> Author: Laurent Rineau <laurent.rineau@cgal.org>
> Date: Fri Oct 4 16:42:13 2013 +0200
>
> Fix the case when FT is mpq_class
>
> If x and w are mpq_class objects, then the type of x/w is not mpq_class,
> but only a proxy type that is implicitly convertible to
> mpq_class. With the type deduction, CGAL::make_array(x/w, y/w,
> z/w) will not create an array<mpq_class> but an array of the proxy type.
>
> That creates the following compilation error, in a ternary operator:
>
> - with clang:
> include/CGAL/Cartesian/Vector_3.h:78:25: error: incompatible operand types ('array<__gmp_expr<[...], struct __gmp_binary_expr<class __gmp_expr<mpq_t, mpq_t>, class __gmp_expr<mpq_t, mpq_t>, struct __gmp_binary_divides>>, [...]>' and 'array<__gmp_expr<[...], __mpq_struct [1]>, [...]>')
> : base( w != FT_(1) ? CGAL::make_array(x/w, y/w, z/w)
> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> - with g++:
> include/CGAL/Cartesian/Vector_3.h:78:25: error: no match for ternary 'operator?:' (operand types are 'bool', 'std::array<__gmp_expr<__mpq_struct [1], __gmp_binary_expr<__gmp_expr<__mpq_struct [1], __mpq_struct [1]>, __gmp_expr<__mpq_struct [1], __mpq_struct [1]>, __gmp_binary_divides> >, 3ul>', and 'std::array<__gmp_expr<__mpq_struct [1], __mpq_struct [1]>, 3ul>')
> : base( w != FT_(1) ? CGAL::make_array(x/w, y/w, z/w)
> ^
>
> The fix is to specify the template argument of CGAL::make_array.
The first patch in 2013 was on `Vector_3`, but `Vector_2` also suffers
from the issue.
This way we no longer trigger a hard error in strict C++03.
This is only a stop-gap solution. The actual issue is that the internal
namespace is full with unrelated components and does not fulfill its
purposee as an SFINAE barrier anymore.
Fixes#129
If x and w are mpq_class objects, then the type of x/w is not mpq_class,
but only a proxy type that is implicitly convertible to
mpq_class. With the type deduction, CGAL::make_array(x/w, y/w,
z/w) will not create an array<mpq_class> but an array of the proxy type.
That creates the following compilation error, in a ternary operator:
- with clang:
include/CGAL/Cartesian/Vector_3.h:78:25: error: incompatible operand types ('array<__gmp_expr<[...], struct __gmp_binary_expr<class __gmp_expr<mpq_t, mpq_t>, class __gmp_expr<mpq_t, mpq_t>, struct __gmp_binary_divides>>, [...]>' and 'array<__gmp_expr<[...], __mpq_struct [1]>, [...]>')
: base( w != FT_(1) ? CGAL::make_array(x/w, y/w, z/w)
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- with g++:
include/CGAL/Cartesian/Vector_3.h:78:25: error: no match for ternary 'operator?:' (operand types are 'bool', 'std::array<__gmp_expr<__mpq_struct [1], __gmp_binary_expr<__gmp_expr<__mpq_struct [1], __mpq_struct [1]>, __gmp_expr<__mpq_struct [1], __mpq_struct [1]>, __gmp_binary_divides> >, 3ul>', and 'std::array<__gmp_expr<__mpq_struct [1], __mpq_struct [1]>, 3ul>')
: base( w != FT_(1) ? CGAL::make_array(x/w, y/w, z/w)
^
The fix is to specify the template argument of CGAL::make_array.
Freie Universitaet Berlin (Germany), Martin-Luther-University Halle-Wittenberg
(Germany) and RISC Linz (Austria) as they transfer the copyright to other
sites.
In particular remove UNTESTED_XXXXXXXXXXX unused variable that possibly hide true warnings.
In those cases, the string printed while executed now starts with "NOTE: ".
*CGAL internal code no longer rely on depecrated features
by namespace CGAL { and } //namespace CGAL. in all .h and .cpp files
in a directory.
Apply it to all packages in the trunk
Remove macro definition from the config.h file.
- C++0x's std:array from <array>
- TR1's std::tr1::array from <tr1/array>
- boost::array from <boost/array.hpp>
Motivation : GCC's std::array is faster than boost::array.
Move CGALi:make_array to namespace CGAL.
Document CGAL::array.
- Use K::Bool_type, K::Orientation... instead of bool, CGAL::Orientation...
- More functions around Uncertain<> : make_certain(), extract_singleton(),
possible conversions tightenning.
Many conversions still remain, e.g. for switch and if statements, &&, ||...
There is now Ambiant_dimension and Feature_dimension.
The handling of the dynamic dimension case is now done by having
the di,ension tag as the first thing provided, with the integral
constant value available only when it makes sense (INT_MAX no longer needed).