views:

121

answers:

3

Below is something that did happen to me and I couldn't get what's wrong. My coworker and me screwed our heads around this. It was in a cross-platform library using the cross-platform toolkit wxWidgets on Windows

#include <wx/wx.h> 

class Graph {
public:
  // ...
  // main1.cpp:4:10: error: expected identifier before '(' token
  double GetYValue(double x);
};

We were trying hard to find any weird glyph placed instead of an ASCII e or something, but didn't find any such issue. What was going on!?

+9  A: 

WinGDI.h ln 640: #define GetYValue(cmyk) ((BYTE)((cmyk)>> 8))

Gotta love windows.h

This is why I recommend AGAINST using camel case for most things.

Noah Roberts
But most (every one I have read) standards say use all upper case for MACROS. Thus my advice is don't make macros that are not all uppercase and don't make functions that are all uppercase.
Martin York
Yeah haha this was the issue xD http://msdn.microsoft.com/en-us/library/dd372091%28VS.85%29.aspx silly windows.h ...
Johannes Schaub - litb
Yeah, `<windows.h>` is a pest. It pollutes thousands of common identifiers as macros. That header best confined to a few `.cpp` files only. And wxWidgets just drags it in everywhere, so the same advice applies. Or just drop CamelCase altogether in favour of the std_lib_convention (whatever that's named). The C++ std lib is much less polluting.
sbi
CamelCase is the naming convention used in wxWidgets...
UncleBens
And that's not the only thing wxWidgets gets wrong. Still though, decent library for what it does...for the most part.
Noah Roberts
I've given up on wxWidgets since Qt became LGPL :)
Johannes Schaub - litb
+7  A: 

I don't use wxWidgets myself, but in http://gambit.sourcearchive.com/documentation/0.2006.01.20/plotctrl_8cpp-source.html I find strange code fragment

#ifdef GetYValue   // Visual Studio 7 defines this
    #undef GetYValue
#endif

Look at the wxWidgets headers. Probably are there a code fragment like this or you should do something like this?

Oleg
+1 haha i had no idea others stumbled over this too!
Johannes Schaub - litb
+6  A: 

My first guess would be that <wx/wx.h> has a macro named GetYValue (and probably another named GetXValue) that are supposed to take some sort of combined X/Y value and "unwrap" them into their individual components, on the general order of:

#define GetXValue(xy) ((xy)>>16)
#define GetYValue(xy) ((xy)&x0ff)

With that expanded, your code would look something like:

double ((xy)>>16)(double x);

...at which point the compiler has a hissy fit -- except, of course, that it probably gave up parsing sooner than that, since the double x appears to be trying pass two tokens as parameters to a macro that only expects 1.

Edit: I see I was guessing fairly close, but guessed wrong about what sort of "Y" was involved here -- the others would apparently be GetCValue, GetMValue, etc., instead of GetXValue. Oh well...

Jerry Coffin
+1 nice explanations all around. Wasn't sure what i'm going to accept. Such a hard decision!
Johannes Schaub - litb