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  
Share this Question
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  
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.victimprime.dsl.pipex.com/  
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  
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.victimprime.dsl.pipex.com/  
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  
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.victimprime.dsl.pipex.com/  
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  
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   This discussion thread is closed Replies have been disabled for this discussion.   Question stats  viewed: 1295
 replies: 8
 date asked: Jul 22 '05
