Strange compiler error

[Dave]

Hello all,

Here is the definition I'm using of a static const class member:

template<typename T, typename U>
const U directed_graph_t<T, U>::INFINITY =
(
std::numeric_limits<U>::has_infinity ?
std::numeric_limits<U>::infinity() :
std::numeric_limits<U>::max()
);

This works fine.

However, Comeau does not accept the following very similar definition:

template<typename T, typename U>
const U directed_graph_t<T, U>::INFINITY =
std::numeric_limits<U>::has_infinity ?
std::numeric_limits<U>::infinity() :
std::numeric_limits<U>::max();

The following error is reported:

"ComeauTest.c", line 172: error: expected a ";" (perhaps on the previous
statement)
std::numeric_limits<U>::infinity() :
^

1 error detected in the compilation of "ComeauTest.c".



NOTE: The carat points to the colon at the end of the line. If you're
viewing this with a proportional font, you won't be able to tell that...

Any idea what's up with this?

Thanks,
Dave

 

[Victor Bazarov]

Here is the definition I'm using of a static const class member:

template<typename T, typename U>
const U directed_graph_t<T, U>::INFINITY =
(
std::numeric_limits<U>::has_infinity ?
std::numeric_limits<U>::infinity() :
std::numeric_limits<U>::max()
);

This works fine.

However, Comeau does not accept the following very similar definition:

template<typename T, typename U>
const U directed_graph_t<T, U>::INFINITY =
std::numeric_limits<U>::has_infinity ?
std::numeric_limits<U>::infinity() :
std::numeric_limits<U>::max();

The following error is reported:

"ComeauTest.c", line 172: error: expected a ";" (perhaps on the previous
statement)
std::numeric_limits<U>::infinity() :
^

1 error detected in the compilation of "ComeauTest.c".



NOTE: The carat points to the colon at the end of the line. If you're
viewing this with a proportional font, you won't be able to tell that...

Any idea what's up with this?

I cannot explain it with anything than a bug in Comeau. It doesn't
want to accept the colon even if you remove the '=' sign and keep
the ?: expression in parentheses:

template<typename T, typename U>
const U directed_graph_t<T, U>::INFINITY(
std::numeric_limits<U>::has_infinity ?
std::numeric_limits<U>::infinity() :
std::numeric_limits<U>::max()
);

Greg will thank you when you tell him.

Victor

 

[Rob Williscroft]

Victor Bazarov wrote in

I cannot explain it with anything than a bug in Comeau. It doesn't
want to accept the colon even if you remove the '=' sign and keep
the ?: expression in parentheses:

template<typename T, typename U>
const U directed_graph_t<T, U>::INFINITY(
std::numeric_limits<U>::has_infinity ?
std::numeric_limits<U>::infinity() :
std::numeric_limits<U>::max()
);

The bug (or possibly extension) I belive is in the standard library,
I tried:

#include <iostream>
#include <limits>

template<typename T, typename U>
class directed_graph_t
{
public:

static U const INFINITY;
};


template<typename T, typename U>
U const directed_graph_t<T, U>::INFINITY = (
std::numeric_limits<U>::has_infinity ?
std::numeric_limits<U>::infinity() :
std::numeric_limits<U>::max()
);

int main()
{
using namespace std;
cerr << directed_graph_t< int, int >::INFINITY << "\n";
}


This produced error's with http://www.dinkumware.com/exam/dinkumExam.aspx
using EDG/C++, but when I change INFINITY to inf and it compiles Ok.

I got a similar error with gcc 3.2.3, which was also fixed by changing
INFINITY to inf. But Visual C++ 7.1 *didn't* have a problem with this
and it also uses a dinkumware stdlib.

FWIW.

Rob.

 

[Victor Bazarov]

Victor Bazarov wrote in

The bug (or possibly extension) I belive is in the standard library,
I tried:

#include <iostream>
#include <limits>

template<typename T, typename U>
class directed_graph_t
{
public:

static U const INFINITY;
};


template<typename T, typename U>
U const directed_graph_t<T, U>::INFINITY = (
std::numeric_limits<U>::has_infinity ?
std::numeric_limits<U>::infinity() :
std::numeric_limits<U>::max()
);

int main()
{
using namespace std;
cerr << directed_graph_t< int, int >::INFINITY << "\n";
}


This produced error's with http://www.dinkumware.com/exam/dinkumExam.aspx
using EDG/C++, but when I change INFINITY to inf and it compiles Ok.

I got a similar error with gcc 3.2.3, which was also fixed by changing
INFINITY to inf. But Visual C++ 7.1 *didn't* have a problem with this
and it also uses a dinkumware stdlib.

FWIW.

This is a great catch! Have you been able to find what 'INFINITY' is
in their library? I wonder if it's a macro of some soft...

I know that there isn't any "INFINITY" in the Standard.

Victor

 

[Rob Williscroft]

Victor Bazarov wrote in

This is a great catch! Have you been able to find what 'INFINITY' is
in their library? I wonder if it's a macro of some soft...

I can't say for EDG / Comeau since I have neither, but for gcc,
MinGW 3.2.3, I did a search of ../include/* and found only this:

include/math.h:

#ifndef __NO_ISOCEXT
#if (defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) \
|| !defined __STRICT_ANSI__ || defined __GLIBCPP__

#define NAN (0.0F/0.0F)
#define HUGE_VALF (1.0F/0.0F)
#define HUGE_VALL (1.0L/0.0L)
#define INFINITY (1.0F/0.0F)

Note I rutinely compile my test's with g++ -pedantic and I just
added -ansi as well but the above #define still gets included. It
would appear the above #if takes no account of the fact that C++
is being compiled.

When I did the online EDG test I got the impression from the error
messages that INFINITY expanded to ::something_or_other..., so maybe
this is something other than using gcc as backend.

I know that there isn't any "INFINITY" in the Standard.

From the #if above, I'd punt that its part of C99, but I don't know.

Presumably if this is C99 it may be adopted into the next standard .

Rob.

 

[Victor Bazarov]

Victor Bazarov wrote in

I can't say for EDG / Comeau since I have neither, but for gcc,
MinGW 3.2.3, I did a search of ../include/* and found only this:

include/math.h:

#ifndef __NO_ISOCEXT
#if (defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) \
|| !defined __STRICT_ANSI__ || defined __GLIBCPP__

#define NAN (0.0F/0.0F)
#define HUGE_VALF (1.0F/0.0F)
#define HUGE_VALL (1.0L/0.0L)
#define INFINITY (1.0F/0.0F)

Note I rutinely compile my test's with g++ -pedantic and I just
added -ansi as well but the above #define still gets included. It
would appear the above #if takes no account of the fact that C++
is being compiled.

When I did the online EDG test I got the impression from the error
messages that INFINITY expanded to ::something_or_other..., so maybe
this is something other than using gcc as backend.


From the #if above, I'd punt that its part of C99, but I don't know.

It is, not surprisingly, since you already discovered it.

Presumably if this is C99 it may be adopted into the next standard .

Awful, ain't it?

Victor

 

[Rob Williscroft]

Victor Bazarov wrote in

It is, not surprisingly, since you already discovered it.


Awful, ain't it?

COL (chuckle out loud). Yup.

Still we can *hope* for the "macrospace" thing that some where talking
about earlier this year:

http://tinyurl.com/y4li

In which case *most* of these macro induced conflicts between C and C++
could go away.


Rob.

 

[P.J. Plauger]

INFINITY should not be defined in C++, neither as a macro nor
as a member of numeric_limits.

We don't supply the C library for Microsoft, so I don't know where
the INFINITY came from there.

It is, not surprisingly, since you already discovered it.


Awful, ain't it?

C99 does indeed define the macro INFINITY in math.h. We disable this
define in C++ mode. We're now fleshing out the C99 contribution to
the C++ Library TR (a.k.a. TR1), and it too will omit INFINITY as a
macro. So maybe it won't be so awful in the long run, once there's
a common spec for various implementors to write to.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[P.J. Plauger]

Victor Bazarov wrote in

COL (chuckle out loud). Yup.

Still we can *hope* for the "macrospace" thing that some where talking
about earlier this year:

http://tinyurl.com/y4li

In which case *most* of these macro induced conflicts between C and C++
could go away.

That's certainly the plan.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com