[property_tree] Compilation Problem when #including <boost/property_tree/json_parser.hpp>
Hi,
On VS2010, the following code does not compile if I restore the commented
out #include:
*// #include
On 2/10/2014 5:29 AM, Adi Shavit wrote:
Hi,
On VS2010, the following code does not compile if I restore the commented out#include:
*// #include
* struct X { enum Labels { ERROR, ONE, TWO, THREE }; // problem => ^^^^^ };
void f() { X::Labels r = X::ERROR; // problem => ^^^^^ }
The VS2010 errors are:
t.cpp(5): error C2059: syntax error : 'constant' t.cpp(5): error C2143: syntax error : missing ';' before '}' t.cpp(5): error C2238: unexpected token(s) preceding ';' t.cpp(7): error C2059: syntax error : '}' t.cpp(7): error C2143: syntax error : missing ';' before '}' t.cpp(7): error C2059: syntax error : '}' t.cpp(11): error C2589: 'constant' : illegal token on right side of '::' t.cpp(11): error C2059: syntax error : '::'
It seems that somewhere inside the #include hierarchy the symbol ERROR is #defined to cause this code to fail. Renaming ERROR to something else avoids this problem.
I do not know where ERROR is occuring. But it is certainly not a good idea to have an enumeration name be a common all-uppercase name.
I think I tracked it into 'boost/spirit/home/classic/iterator/impl/file_iterator.ipp' but I'm not sure where exactly it is coming from.
It seems that somewhere inside the #include hierarchy the symbol ERROR
is #defined to cause this code to fail. Renaming ERROR to something else avoids this problem.
I do not know where ERROR is occuring. But it is certainly not a good idea to have an enumeration name be a common all-uppercase name.
That's true. But still, having commonly named MACROs introduced by a 3rd-party header is even less ideal. Adi
On 12/02/2014 19:58, Quoth Adi Shavit:
I do not know where ERROR is occuring. But it is certainly not a good idea to have an enumeration name be a common all-uppercase name.
That's true. But still, having commonly named MACROs introduced by a 3rd-party header is even less ideal.
Have you tried searching for ERROR in Boost and your CRT headers? In 1.53 at least this is not defined by any Boost headers. But if you're on Windows then this *is* defined by the Windows SDK. So it is never valid to use this as an identifier in programs compiled for Windows (or at least, not without undefining it first). The Windows SDK defines a very large number of such macros, several even in PascalCase. So you always need to watch out for these.
Have you tried searching for ERROR in Boost and your CRT headers? In 1.53 at least this is not defined by any Boost headers.
I couldn't find it either. As I said changing the enum name fixed the problem. I never had this problem until I included that particular header file. That's why I find it strange. I wonder if some part of the include hierarchy can by changed to avoid this. This may cause problems for others who cannot easily change a name. Adi
participants (3)
-
Adi Shavit -
Edward Diener -
Gavin Lambert