Dear God, WHY?!?!

[Karlos]

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?

[Karlos]

OK, after some caffeine, experimentation and a fair amount of swearing, I have discovered the following:

Code: [Select]

#include <cstdio>

#define PP_CONCAT(a,b) a##::##b

namespace Foo {
  void bar()
  {
    std::puts(&quot;gcc 4 sux&quot;);
  }
};

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 you pass through to the preprocessor (including -traditional-cpp).

However, I have found that the following does appear to work:

Code: [Select]

#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

[lsmart]

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?

[Karlos]

And with that:

Code: [Select]


# 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.

[Karlos]

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.

[Jose]

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.

[Jose]

Maybe the "::" could be passed as an argument, but if you got it working that weird way it's already good.

[Karlos]

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.

[ChaosLord]

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.

[ChaosLord]

@Karlos

Use a different preprocessor.

[Karlos]

@Karlos

Use a different preprocessor.

No need, I found a work around for it. Changing preprocessor is not a good build dependency

[A1260]

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)

[Karlos]

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?

[jj]

rule of thumb ignore anything h has to say.  Its either troling or complete jiberish

[ejstans]

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?