Jump to content
  • Advertisement
Sign in to follow this  
Kylotan

gcc parser bug? (using "unsigned long")

This topic is 4283 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This works in MSVC 2003, but not in g++ 4.1.2:
return unsigned long();
So I have to use the following:
{
    typedef unsigned long ulong;
    return ulong();
}
The errors are: whatever.cpp:295: error: expected primary-expression before 'unsigned' whatever.cpp:295: error: expected ';' before 'unsigned' whatever.cpp:295: error: expected primary-expression before 'unsigned' whatever.cpp:295: error: expected `;' before 'unsigned' Both compilers are happy with returning int(), std::string(), etc. (For the curious, I am forcing the default constructor because it's one of a set of specialised template functions, each of which returns the default value for a given type.) Is this a bug in g++, or perhaps just a corner case that I was unaware of (and which MSVC handles 'better')?

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
I don't have access to g++ right now, but I wonder if perhaps the () is binding tighter than the "unsigned", so that g++ is parsing it as "unsigned (long())", which wouldn't make sense. If that was the case one might expect "(unsigned long)()" to work correctly, so you might try that and see what happens. Just a shot in the dark.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
I don't have access to g++ right now, but I wonder if perhaps the () is binding tighter than the "unsigned", so that g++ is parsing it as "unsigned (long())", which wouldn't make sense. If that was the case one might expect "(unsigned long)()" to work correctly, so you might try that and see what happens. Just a shot in the dark.


I had already tried that, with no luck. But I'm using a mingw g++ which is version 3.something, so maybe it'll work on a newer gcc.

Share this post


Link to post
Share on other sites
gcc is conforming; the Standard requires that the type name used in a function-style cast be a simple-type-specifier, that is, either a (possibly namespace-qualified) user-defined type or typedef, or exactly one of the fundamental types char, wchar_t, bool, short, int, long, signed, unsigned, float, double, or void.

Adding parentheses doesn't work, because that would make the expression a C-style cast which doesn't allow the value-initializing "()" syntax. Yet another of the lovely quirks of C++.

Share this post


Link to post
Share on other sites
Intriguing. Several 'informal' pieces of documentation include unsigned longs as part of the 'simple types', including the docs for IBM's compiler, but it would appear that the standard does not. MSVC's documentation notably doesn't include unsigned longs in there, but compiles the code anyway.

Is there any reason why unsigned longs don't fit into this type list? If not, I would think that MS's implementation is better, despite being non-standard.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Why is it then that above code will not compile but the following does?

template<typename T>
T foo()
{
return T();
}

int main(int argc, char *argv[])
{
foo<unsigned long>();
return 0;
}

Share this post


Link to post
Share on other sites
Presumably because it's a lexical issue, not a semantic issue. 'T' is a valid token in the context of the return statement, but 'unsigned long' isn't. That's also why my code works when you use the typedef.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!