Changed the calls mpfr_get_z_exp -> mpfr_get_z_2exp for MPFR>2 (the old
function name may be deprecated in future versions).
Added comments in the Gmpfr code about Gmpfr destructors.
Updated my mail address in source files.
On Windows, with MSVC, std::fabs is an intrinsic function with /Oi (implied
with /O1, /O2, and so on) *if* /fp:strict is not used. We should reevaluate
the need to use /fp:strict (and maybe use /fp:precise, the default,
combined with #pragma fenv_access).
First step: bench! This macro will help.
::test.
The error message was:
/home/lrineau/CGAL/boost/1.44-beta1/include/boost/type_traits/has_new_operator.hpp: In function 'int main()':
/home/lrineau/CGAL/boost/1.44-beta1/include/boost/type_traits/has_new_operator.hpp:24: error: 'template<class U, U x> struct boost::detail::test' is not a function,
/home/lrineau/CGAL/CGAL-3.7-I-139/cmake/platforms/x86-64_Linux-2.6_g++-4.4.4_F13/test/Number_types/to_interval_test.cpp:30: error: conflict with 'template<class NT> void test(const NT&)'
/home/lrineau/CGAL/CGAL-3.7-I-139/cmake/platforms/x86-64_Linux-2.6_g++-4.4.4_F13/test/Number_types/to_interval_test.cpp:73: error: in call to 'test'
| ------------------------------------------------------------------------
| r58141 | lrineau | 2010-08-18 15:08:04 +0200 (Wed, 18 Aug 2010) | 5 lines
| Changed paths:
| M /branches/CGAL-3.7-branch/Algebraic_kernel_d/include/CGAL/Algebraic_kernel_d/Float_traits.h
| M /branches/CGAL-3.7-branch/Number_types/include/CGAL/CORE_BigFloat.h
|
| Fix the "bug" of CORE-1.7 in 64 bits. The bug was actually in CGAL
| Number_types and Algebraic_kernel_d! The basis of CORE::BigFloat is not
| 2^14: it is 2^CORE::CHUNK_BIT. CORE::CHUNK_BIT is 14 in 32 bits, but *30*
| in 64 bits!
|
| ------------------------------------------------------------------------
Update: See revision 58145.
-- Laurent Rineau Wed Aug 18 16:26:15 CEST 2010
svn+ssh://lrineau@scm.gforge.inria.fr/svn/cgal/branches/CGAL-3.6-branch
........
r56835 | lrineau | 2010-06-17 12:56:52 +0200 (Thu, 17 Jun 2010) | 6 lines
Remove the constructor Gmpfr(long double) on Microsoft Visual C++. A big
comment in the source code explains why.
The testsuite will check that the construction of Gmpfr from a long double
on MSVC still works and produces the right Gmpfr.
........
r56864 | afabri | 2010-06-18 11:04:47 +0200 (Fri, 18 Jun 2010) | 1 line
Use tie from boost::
........
r56865 | afabri | 2010-06-18 11:11:49 +0200 (Fri, 18 Jun 2010) | 1 line
Use bind from boost::
........
r56866 | afabri | 2010-06-18 11:38:50 +0200 (Fri, 18 Jun 2010) | 1 line
Use bind from boost:: (detected in Mesh_3 VC10 testsuite)
........
r56867 | lrineau | 2010-06-18 11:39:24 +0200 (Fri, 18 Jun 2010) | 3 lines
cmake-2.8.2rc2 is out.
/bigobj is necessary
........
r56868 | afabri | 2010-06-18 11:52:37 +0200 (Fri, 18 Jun 2010) | 1 line
Add #include <fstream>
........
r56869 | afabri | 2010-06-18 11:55:33 +0200 (Fri, 18 Jun 2010) | 1 line
Shorten filename as with path it exceeds easily 256 letters which poor Visual C++ can't handle
........
r56870 | afabri | 2010-06-18 12:24:30 +0200 (Fri, 18 Jun 2010) | 1 line
Use tie from boost::
........
r56876 | lrineau | 2010-06-18 16:40:36 +0200 (Fri, 18 Jun 2010) | 3 lines
New try to fix the issue of Gmpfr(long double) with MSVC and libmpfr-1.dll
compiled by Mingw.
........
r56895 | lrineau | 2010-06-20 23:16:40 +0200 (Sun, 20 Jun 2010) | 3 lines
Using boost::bind is not sufficient" "bind" without qualifier was
ambiguous, according to MSVC2010, with std::bind (from C++0x).
........
r56896 | lrineau | 2010-06-20 23:18:29 +0200 (Sun, 20 Jun 2010) | 3 lines
Qualify "bind" with "boost::", to avoid the ambiguity (according to
MSVC2010), with std::bind (C++0x).
........
r56897 | lrineau | 2010-06-20 23:19:17 +0200 (Sun, 20 Jun 2010) | 2 lines
Stupid typo!
........
Luis Peñaranda
Laurent Rineau
Andreas Fabri
Marc Glisse
Eric Berberich
Sébastien Loriot
Michael Hemmer
Daniel Russel
Sylvain Pion
Michael Kerber