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

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

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

[Karlos]

@Karlos

Use a different preprocessor.

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

[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?

[Karlos]

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:

Code: [Select]

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

Code: [Select]

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?

[Karlos]

Hmmm, actually...

This is starting to look like a redundant artefact from copying the first form of the macro...

[Karlos]

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]

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

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