Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: Karlos on August 08, 2009, 02:03:22 PM
-
So, for the first weekend in ages, I'm actually getting to do some amiga coding.
I have some code that is attempting to span the bridge between gcc 2.95 (on the classic) and 4 (on the A1) as well as under linux.
Unfortunately, somebody decided that GCC 4's preprocessor (and working back through older versions, 3's too probably) needed to be really broken.
I have a macro that uses one of two ways of throwing an exception, depeding on compilation options:
method 1:
#define THROW_NESTED_EXCEPTION(cname, except) EXNGPrivate::throw##cname##except
method 2:
#define THROW_NESTED_EXCEPTION(cname, except) throw cname##::##except
This is the (expected) expansion behaviour that you get with 2.95.x
method1:
THROW_NESTED_EXCEPTION(Foo, InvalidBar()); -> EXNGPrivate::throwFooInvalidBar();
method2:
THROW_NESTED_EXCEPTION(Foo, InvalidBar()); -> throw Foo::InvalidBar();
Both work exactly as expected. Method 1 expands into a debugging function call that handles throwing the exception in a different way (for example, logging that the exception is about to be raised, then raising it).
Under GCC 4, I have ran into this nugget of sheer, unadulterated rubbish when compiling with method 2:
THROW_NESTED_EXCEPTION(Application, TooFewArguments());
/extropia/exng2/libsource/systemlib/startup.cpp:93:1: error: pasting "Application" and "::" does not give a valid preprocessing token
/extropia/exng2/libsource/systemlib/startup.cpp:93:1: error: pasting "::" and "TooFewArguments" does not give a valid preprocessing token
In other words, the preprocessor cannot paste together the macro arguments with the scope of resolution operator without considering the interim result as an invalid token. Why for pity's sake?
Searching for this class of error, I find thousands of links (mostly about pasting with "." however) but no actual explanation as to why this is considered an error.
I'm not attempting to stringify (#) the arguments, I just want it to concatenate the arguments in the specified manner and emit the damn code.
Anybody come across this behaviour before?
-
OK, after some caffeine, experimentation and a fair amount of swearing, I have discovered the following:
#include <cstdio>
#define PP_CONCAT(a,b) a##::##b
namespace Foo {
void bar()
{
std::puts("gcc 4 sux");
}
};
int main()
{
PP_CONCAT(Foo,bar());
return 0;
}
just cannot be made to work with the preprocessor as of gcc 2.97. Since 3 and beyond, this results in an "invalid preprocessor token", regardless of the options (http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Preprocessor-Options.html) you pass through to the preprocessor (including -traditional-cpp).
However, I have found that the following does appear to work:
#include
#define PP_CONCAT(a,b,c) a##c::c##b
namespace Foo {
void bar()
{
std::puts("gcc 4 sux");
}
};
int main()
{
PP_CONCAT(Foo,bar(),);
return 0;
}
So, defining an additional argument to the macro to be pasted between the first and the scope of resolution operator seemingly works when you omit to pass anything for that argument.
That is pretty damned weird
-
Hmm, sounds strange. Are you sure you are compiling as C++ instead of vanilla C (i.e. have you invoked g++)? What compiler options are you using?
-
And with that:
# if defined(__GNUC__) && (__GNUC__ < 3) && (__GNUC_MINOR__ <= 97)
# define THROW_NESTED_EXCEPTION(cname, except) throw cname##::##except
# else
# define THROW_NESTED_EXCEPTION_REAL(cname, except, dummy) throw cname##dummy::dummy##except
# define THROW_NESTED_EXCEPTION(a, b) THROW_NESTED_EXCEPTION_REAL(a, b, )
# endif
Talk about having to jump through hoops.
-
Hmm, sounds strange. Are you sure you are compiling as C++ instead of vanilla C (i.e. have you invoked g++)? What compiler options are you using?
Absolutely sure.
On the gcc4 build:
CXXFLAGS = -O3 -Wall -W -Wno-unused-parameter -I$(INCDIR) -I$(INCDIR)platforms/$(PLATFORM) -fPIC -DXP_PLATFORM="$(PLATFORM)/"
the line in the makefile:
$(CXX) -shared -Wl,-soname,$(LIB).$(VER) -o $(LIBDIR)$(LIB).$(VER).$(REV) $(OBJ);
I should point out that the target in this case is a .so (both for linux and OS4.1)
It would appear that "modern ISO compliant C preprocessors" simply don't like pasting together bits of text with operators. Try googling for the error, people all over have had it.
-
Well, I once tried to make a serialization library for C based on the preprocessor. Lost a bunch of moths trying it and ended up completely frustrated cause preprocessors vary in implementations and even crash when you through complicated things at them. Never understood how the boost library can be so based on the preprocessor.
-
Maybe the "::" could be passed as an argument, but if you got it working that weird way it's already good.
-
Maybe the "::" could be passed as an argument, but if you got it working that weird way it's already good.
Tried that, no joy.
After some experimentation I have discovered that pretty much any C/C++ operator (especially ., -> etc) doesn't like being used in ## concatenation. Which is completely stupid.
IMO, that's totally and utterly broken. It should not be up the the preprocessor to dictate what constitutes "valid" output from concatenating two pieces of text. It should just do the job and if the result is meaningless garbage, that's up to the compiler to diagnose.
It isn't the first issue I have had with gcc 4's preprocessor. It has issues with computed includes too.
-
Lost a bunch of moths trying it and ended up completely frustrated cause preprocessors vary in implementations and even crash when you through complicated things at them. Never understood how the boost library can be so based on the preprocessor.
I had/have the same problem.
-
@Karlos
Use a different preprocessor.
-
@Karlos
Use a different preprocessor.
No need, I found a work around for it. Changing preprocessor is not a good build dependency ;)
-
with jupiter lander in mind i guess this set a stop for the new amiga crap games that are floathing up from the sewer every now and then. (burp)
-
with jupiter lander in mind i guess this set a stop for the new amiga crap games that are floathing up from the sewer every now and then. (burp)
Huh?
-
rule of thumb ignore anything h has to say. Its either troling or complete jiberish
-
Tried that, no joy.
After some experimentation I have discovered that pretty much any C/C++ operator (especially ., -> etc) doesn't like being used in ## concatenation. Which is completely stupid.
IMO, that's totally and utterly broken. It should not be up the the preprocessor to dictate what constitutes "valid" output from concatenating two pieces of text. It should just do the job and if the result is meaningless garbage, that's up to the compiler to diagnose.
It isn't the first issue I have had with gcc 4's preprocessor. It has issues with computed includes too.
You are in undefined behavior-land. From the C++98 standard:
"16.3.3 The ## operator
[...]
3 For both object-like and function-like macro invocations, before the replacement list is reexamined for more macro names to replace, each instance of a ## preprocessing token in the replacement list (not from an argument) is deleted and the preceding preprocessing token is concatenated with the following preprocessor token. If the result is not a valid preprocessing token, the behavior is undefined. The resulting token is available for further macro replacement. The order of evaluation of ## operators is unspecified."
The important part here is "If the result is not a valid preprocessing token, the behavior is undefined". Gcc is rather nice to point this out :)
Let's look at your fix:
#define PP_CONCAT(a, b, c) a##c::c##b
This (seemingly) works because 'a' and 'c' are concatenated (and 'c' and 'b' likewise) and since you pass in an empty argument the result is simply 'a' (and 'b') which is a valid preprocessing token. Or is it? Actually, passing in an empty argument results in undefined behaviour, so this is not a good fix...
But what if we suppose passing an in empty argument was in fact well-defined and acted like above? The result would simply be the same as:
#define PP_CONCAT(a, b) a::b
So why mix in the concatenting operator? :)
-
But what if we suppose passing an in empty argument was in fact well-defined and acted like above? The result would simply be the same as:
#define PP_CONCAT(a, b) a::b
So why mix in the concatenting operator? :)
Well, yes, why indeed? It's a synthetic example to highlight the problem.
In actual fact, what I have is two macros, only one of which may be enabled, depending on the options passed in to make.
The first form of the macro does this:
#define THROW_NESTED_EXCEPTION(cname,except) EXNGPrivate::throw##cname##except
So, in the following code:
class Thread {
public:
class SecurityViolationError : public RuntimeError {};
// etc...
protected:
void somethingPrivileged(); // may only be called by the current Thread
private:
static Thread* threadForTask(Task*);
};
//....
void Thread::somethingPrivileged()
{
if (this!=threadForTask(::FindTask(0)) {
THROW_NESTED_EXCEPTION(Thread, SecurityViolationError());
}
// do stuff
}
the following macro:
THROW_NESTED_EXCEPTION(Thread, SecurityViolationError());
becomes:
EXNGPrivate::throwThreadSecurityViolationError();
This function might be defined like so
void EXNGPrivate::throwThreadSecurityViolationError()
{
// do various logging and other debug specific work
throw Thread::SecurityViolationError();
}
In the alternative build option, the above function is never compiled and instead, the macro expands to:
throw Thread::SecurityViolationError();
Is that any clearer?
-
Actually, not clearer...
Is the second macro the following macro:
#define THROW_NESTED_EXCEPTION(cname, except) throw cname##::##except
If so, the argument from the synthetic example applies here as well: Why the ##-operator? No need for it. Try:
#define THROW_NESTED_EXCEPTION(cname, except) throw cname::except
-
Hmmm, actually...
This is starting to look like a redundant artefact from copying the first form of the macro...
-
ROFLMAO
Ok, that works (of course). I guess sometimes a second pair of eyes and a functioning brain is useful :)
I'm actually struggling to remember why I used this form. No doubt it will come back and bite me later. At some point I was maintaining 3 different versions of the code (four if you count x86 and x64 linux targets as different).
Ironically the thread title is even more apt now. Why can't I see the wood for all these bloody trees?!
-
@Karlos
I looked at your code earlier for a while... and all I got was confused...
I just couldn't figure out what the ## was for. I just assumed it was something to do with c++(which I don't know). I have never found any use for ##.
@ejstans
Thanx for straightening him out. :) You saved me a ton of typing.
-
You know, it's one of those stupid things where it takes someone else to point out what is obviously wrong.
The code was written a long time ago and always compiled without warnings under 2.95. It's only this weekend that I've ran into the problem whilst using 4 and only when compiling without the extended debugging.
Basically that set me off barking up the wrong tree :D
I looked at your code earlier for a while... and all I got was confused...
I just couldn't figure out what the ## was for. I just assumed it was something to do with c++(which I don't know). I have never found any use for ##.
Basically it's for concatenation in the preprocessor. I wanted to take the name of an exception and the name of the namespace or class it was nested in and turn it into either a function name or a normal exception throw depending on the compiler options. Turning it into a function name was a valid use of ##:
#DEFINE THROW_NESTED_EXCEPTION(cname, except) EXNGPrivate::throw##cname##except
when invoked thusly:
THROW_NESTED_EXCEPTION(Thread, SecurityViolationError());
generates:
EXNGPrivate::throwThreadSecurityViolationError();
That function in turn throws a Thread::SecurityViolationError after doing some other work.
Unfortunately, I got so blinded by the ## concatenation I didn't actually see what was wrong (or rather redundant) with the second form:
#DEFINE THROW_NESTED_EXCEPTION(cname, except) throw cname##::##except
which is supposed to produce
throw Thread::SecurityViolationError();
The fact is that 2.95.x was happy enough to concatenate "cname" with "::" and "::" with "except". On the face of it, regarding the preprocessor as a pure text processor, it still seems unreasonable that this gives a problem. However, it is expecting a valid preprocessor token to be generated by the ##, not just arbitrary text.
As ejstans observed, the use of ## in the second form was completely redundant anyway. Which is why I'm now wearing a conical paper hat with a big letter D on it ;)