Open efifogel opened 3 years ago
GMPXX does not support long long
. You can disable the use of GMPXX. Something like -DWITH_GMPXX=false
for CMake? Or #undef CGAL_USE_GMPXX
in your file. If it then fails because of boost, you may also need #define CGAL_DO_NOT_USE_BOOST_MP 1
, and you should be back to good old Gmpq.
int64_t
is the standard way to get a 64-bit signed integer type.
What the connection? I don't want to disable it. I'm actually using it. Anyway, as I've said, it used to work, and now it doesn't.
On Tue, May 11, 2021, 20:53 Marc Glisse @.***> wrote:
GMPXX does not support long long. You can disable the use of GMPXX through CMake (something like -DWITH_GMPXX=false?).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/CGAL/cgal/issues/5700#issuecomment-838908949, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVBNOFKDUUQPFX4ZK5RBELTNFVK5ANCNFSM44R3ZBPA .
Filtered_kernel works by converting your objects to those in Simple_cartesian<Interval_nt>
and Simple_cartesian<Exact_rational>
. Exact_rational used to be a typedef for Gmpq. Now, by default, it is mpq_class
or mpq_rational
. Disabling those 2 "new" types makes it use Gmpq again, as it used to.
Absolutely not. My (real) program uses gmpq and gmpz. I cannot disable them. As I've said, it used to work the way it is.
//) o /__ // (__ ( ( ( (/ (/-(-'(/ /
On Wed, 12 May 2021 at 07:02, Marc Glisse @.***> wrote:
Filtered_kernel works by converting your objects to those in Simple_cartesian
and Simple_cartesian . Exact_rational used to be a typedef for Gmpq. Now, by default, it is mpq_class or mpq_rational. Disabling those 2 "new" types makes it use Gmpq again, as it used to. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/CGAL/cgal/issues/5700#issuecomment-839414995, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVBNOFIAPYNHSR5F6J4OLTTNH4UNANCNFSM44R3ZBPA .
Will you please read my message? I am talking of making Gmpq/Gmpz the default by disabling other types. If you are also using GMPXX (not just GMP) or Boost.Multiprecision directly, then disabling them could be a problem, but it doesn't seem to be the case from what you are saying. Using int64_t instead of long long would help on 64-bit linux, and on windows using the MPIR fork of GMP might also help. I am not saying the current situation is perfect, just trying to suggest some workarounds.
ok, you are trying to help suggesting a workaround and I've dismissed you---sorry. It turns out that the code compiles on Windows (MSVC), so there is another workaround: On Windows , where "long long" is mandatory it works, and on Linux, where "long" and "long long" are equivalent, one can use (single) "long". Nevertheless, I would still like it to be fixed, because it's code that we are about to publish (in a published paper).
//) o /__ // (__ ( ( ( (/ (/-(-'(/ /
On Wed, 12 May 2021 at 10:40, Marc Glisse @.***> wrote:
Will you please read my message? I am talking of making Gmpq/Gmpz the default by disabling other types. If you are also using GMPXX (not just GMP) or Boost.Multiprecision directly, then disabling them could be a problem, but it doesn't seem to be the case from what you are saying. Using int64_t instead of long long would help on 64-bit linux, and on windows using the MPIR fork of GMP might also help. I am not saying the current situation is perfect, just trying to suggest some workarounds.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/CGAL/cgal/issues/5700#issuecomment-839540826, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVBNOFSUVLLQF2FMBM3NRTTNIWFLANCNFSM44R3ZBPA .
It turns out that the code compiles on Windows (MSVC),
Probably because you have installed MPIR and not GMP.
so there is another workaround: On Windows , where "long long" is mandatory it works, and on Linux, where "long" and "long long" are equivalent, one can use (single) "long".
int64_t
conveniently does that.
Issue Details
This compilation error is the results of a combination of things. First, the code used to work ~2 years ago. I don't know when it broke. Secondly, on Windows "int", "long int", and "long long int" translate to 32, 32, and 64-bit integral types, respectively, while in Linux they translates to 32, 64, and 64-bit integral types, respectively, So, to assure getting a 64-bit integral type "long long" is used.
The (interesting) error message follows.
Source Code
Environment