By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,227 Members | 1,290 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,227 IT Pros & Developers. It's quick & easy.

Strange compiler error

P: n/a

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
Jul 22 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
"Dave" <be***********@yahoo.com> wrote...
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
Jul 22 '05 #2

P: n/a
Victor Bazarov wrote in news:g6AAb.325154$275.1084464@attbi_s53:
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.
--
http://www.victim-prime.dsl.pipex.com/
Jul 22 '05 #3

P: n/a
"Rob Williscroft" <rt*@freenet.REMOVE.co.uk> wrote...
Victor Bazarov wrote in news:g6AAb.325154$275.1084464@attbi_s53:
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.


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
Jul 22 '05 #4

P: n/a
Victor Bazarov wrote in news:ubJAb.450059$HS4.3521088@attbi_s01:
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 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.
--
http://www.victim-prime.dsl.pipex.com/
Jul 22 '05 #5

P: n/a
"Rob Williscroft" <rt*@freenet.REMOVE.co.uk> wrote...
Victor Bazarov wrote in news:ubJAb.450059$HS4.3521088@attbi_s01:
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 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.


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
Jul 22 '05 #6

P: n/a
Victor Bazarov wrote in news:j2KAb.450336$HS4.3527340@attbi_s01:
> 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.


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?


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.
--
http://www.victim-prime.dsl.pipex.com/
Jul 22 '05 #7

P: n/a
"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:j2KAb.450336$HS4.3527340@attbi_s01...
"Rob Williscroft" <rt*@freenet.REMOVE.co.uk> wrote...
Victor Bazarov wrote in news:ubJAb.450059$HS4.3521088@attbi_s01:
> 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.
INFINITY should not be defined in C++, neither as a macro nor
as a member of numeric_limits.
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.
We don't supply the C library for Microsoft, so I don't know where
the INFINITY came from there.
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 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.


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?


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
Jul 22 '05 #8

P: n/a
"Rob Williscroft" <rt*@freenet.REMOVE.co.uk> wrote in message
news:Xn*********************************@195.129.1 10.130...
Victor Bazarov wrote in news:j2KAb.450336$HS4.3527340@attbi_s01:
> 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.


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?


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
Jul 22 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.