cpp: preprocessing can bite
Ready for a new type of post? cpp? What is it? Well, KDE and Qt are primarily written in C++. I do have experience in that language. And sometimes a question pops up that begs for an answer.So here goes.
qnamespace.h:833: error: expected identifier before numeric constant
qnamespace.h:833: error: expected unqualified-id before numeric constant
Say what? Pretty cryptic error message. So, what's happening in qnamespace.h at that particular line?// documented in qcursor.cpp
enum CursorShape {
ArrowCursor,
UpArrowCursor,
CrossCursor,
....
Line 833 is the one that starts with the enum. At this point, the problem still evaded me. So, let's have a look at the source that is compiled. It contained among others these lines#include "config.h" // HAVE_LIBXSS
#ifdef HAVE_LIBXSS // Idle detection.
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/extensions/scrnsaver.h>
#include <fixx11h.h>
#endif // HAVE_LIBXSS
#include <kapplication.h>Well, after undefining HAVE_LIBXSS after the inclusion of the config header, the error went away. Hmmm. Could it be that somewhere in the X11 headers the name CursorShape is used? So, fire up a konsole, navigate to the directory holding the relevant headers and execute find . -type f | xargs grep CursorShapewhich turns up#define CursorShape 0 /* largest size that can be displayed */Aha! The plot thickens. Because when this is preprocessed before the enum in qnamespace.h, that particular enum will come out like enum 0 {... which is obviously not a good thing.This is a classic case of how preprocessing can bite a programmer and yield an error message that seems totally unrelated to what is actually wrong. So, the solution is to change the order in which headers are included. In this particular case that meant moving the X11 headers to the end of the #include stanzas.
Now, before you start falling all over me that this is not a solution, yes, I know it is not a proper solution. I'm aware of the fact that if one uses CursorShape after having included the X11 headers, I will get exactly the same trouble. In this case, that didn't happen. And for now, the code works.
Update -- I should have known. No, this piece is not about how to fix it, it is about how preprocessing can bite you. And yes - #undef CursorShape would be an alternate approach but equally bad. And no - including fixx11.h didn't.
Bookmarks