Boost logo

Boost Users :

From: Eugene M. Kim (gene_at_[hidden])
Date: 2008-02-13 17:17:45

Boost already did its fair share by encasing the name inside the
boost::lambda namespace, and more importantly, by not using a macro but
an enum. I'm afraid it's the other file that defines EXCEPTION as a
macro is to blame, for the identical reason: It shouldn't have defined a
preprocessor macro with such a common name.

I'd suggest fixing it in the header file (say, except.h) that defines
the EXCEPTION macro: Rename all occurrances of EXCEPTION to something
like FOOBAR_EXCEPTION (where FOOBAR is the name/acronym of the project
where EXCEPTION belongs, or something like that), then turn EXCEPTION
into a compatibility macro that can be left undefined if necessary:

#define FOOBAR_EXCEPTION <insert what used to be EXCEPTION here>
This way, the existing client code that uses the unqualified "EXCEPTION" 
macro would continue to work; in your code, you would define 
FOOBAR_WITHOUT_LEGACY_EXCEPTION before including except.h so it does not 
introduce the problematic macro.
Also if you have control over the header file, you could deprecate the 
EXCEPTION macro in favor of FOOBAR_EXCEPTION at the same time.  Then 
when most of the existing code finished migration toward using 
FOOBAR_EXCEPTION and/or when the deprecation phase concludes, #ifndef 
FOOBAR_WITHOUT_LEGACY_EXCEPTION can be replaced with #ifdef 
Knut Hunstad wrote:
> Hi!
> I haven't used boost much yet, but have been looking into lambda
> expressions. I am working within a huge system, where one of the include
> files has a macro definition for EXCEPTION. Which is also used as an enum
> value in boost/lambda/detail/arity_code.hpp (within namespace
> boost::lambda):
> enum { NONE = 0x00, // Notice we are using bits as flags here.
> FIRST = 0x01,
> SECOND = 0x02,
> THIRD = 0x04,
> EXCEPTION = 0x08,
> RETHROW = 0x10};
> Using common names such as this in a general library seems a bit risky to
> me. Any header before "boost/lambda.hpp" which defines macros for any of
> these enum values, will cause trouble. I don't have insight enough in boost
> to suggest the correct solution (or to conclude that I have to fix the
> problem in my own code and let boost::lambda remain unchanged :-). For me
> right now the fix was simply replacing the (4) occurences of this EXCEPTION
> with LAMBDAEXCEPTION in the boost files.
> Where do I go to put this up as a fix-suggestion? I would like to avoid
> having to remember this replace every time I upgrade boost...
> Best regards,
> Knut Hunstad
> Vianova Systems AS
> Norway
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at