Faulty check whether 'long long' is available in tolerance.h

[Alpar Juttner]

The current check

#if defined __GNUC__ && !defined __STRICT_ANSI__

evaluates to false somehow (using autotools' default settings)

It would be nice if we had a reliable HAVE_LONG_LONG define which could be used throughout the library.

[Alpar Juttner]

The situation is very strange. As it turned out, the -ansi compiler option defines __STRICT_ANSI__, but it does not even warning if long long is used.

My proposal (see the changeset [bac03d6fae99] attached) is to simply assume that if a compiler survives our template-abuse attack, then it will also have long long type. Thus we don't have to check if it is available or not.

IMHO, it is enough to think about a more sophisticated solution only when we first come across a decent C++ compiler that somehow does not support long long.

What's your opinion?

[Akos Ladanyi]

I agree.

[Balazs Dezso]

Long long checking in build environment

[Balazs Dezso]

I have uploaded a patch, which checks the long long in cmake and automake.

[Alpar Juttner]

Replying to deba:

I have uploaded a patch, which checks the long long in cmake and automake.

I rebased this changeset so that I could merge it into both the 1.0 and the main branches, see [7992dcb0d0e6].

[Peter Kovacs]

I found that the dimacs solver doesn't use 'long long' in [1c5d6e47921f] (on lime.cs.elte.hu), although it is available.

And the changeset [7992dcb0d0e6] also seems faulty. In bits/default_map.h

#if defined HAVE_LONG_LONG

is used, but in tolerance.h

#if HAVE_LONG_LONG

is used.

I'm not sure, but I think the later one should be used everywhere, so in the dimacs solver as well. (It also contains #ifdef HAVE_LONG_LONG.)

[Alpar Juttner]

Replying to kpeter:

I found that the dimacs solver doesn't use 'long long' in [1c5d6e47921f] (on lime.cs.elte.hu), although it is available.

This is my mistake - I should have been more aggressively against the stupid idea of this HAVE_LONG_LONG. We should have just assume that long long is there instead for taking the extra hassle for nothing.

But: what's the real reason for this? Isn't

#include<lemon/config.h>

missing from somewhere?

And the changeset [7992dcb0d0e6] also seems faulty. In bits/default_map.h

#if defined HAVE_LONG_LONG

is used, but in tolerance.h

#if HAVE_LONG_LONG

is used.

Hmmm. Strange. I can't see HAVE_LONG_LONG in the current version of lemon/tolerance.h.

I'm not sure, but I think the later one should be used everywhere, so in the dimacs solver as well. (It also contains #ifdef HAVE_LONG_LONG.)

Anyhow, Most people will use #ifdef in cases like that, so I strongly want this form to work.

[Alpar Juttner]

Replying to kpeter:

I found that the dimacs solver doesn't use 'long long' in [1c5d6e47921f] (on lime.cs.elte.hu), although it is available.

I hope [39aaeea2d471] solves this issue.

[Peter Kovacs]

Replying to alpar:

I hope [39aaeea2d471] solves this issue.

The dimacs solver works properly with this changeset. I think it solves this issue. Btw. whether we have this HAVE_LONG_LONG macro or not, it seems a good idea to include the config file globally.