Re: [Boost-users] Boost.Preprocessor with __LINE__ in MSVC71

From: Wu Yinghui, Freddie (yhwu_at_[hidden])
Date: 2006-03-08 20:33:09

 >>> -----Original Message-----
 >>> That's what I feel. The error message indicate that the
 >>> compiler somehow considers "id" and __LINE__ two identifier
 >>> when the error occurs. I tried using the /P parameter to dump
 >>> the preprocessed source, and that looked fine, though. So I
 >>> guess it is the problem with MSVC compiler mixing
 >>> preprocessing and parsing phases together...
 >
 > Yes.  There is nothing that the pp-lib can do about it.

I agree. But I pointed this out after much effort trying to debug the 
mysterious bug. Maybe it'd be better to document this in pp-lib's manual 
as "known issues?" That'd make future victims' lives easier. :)

 >>>  > What do you mean by "certain scope"?  Or, more precisely,
 >>> given a  > finite scope such as that defined by a function,
 >>> why do you need  > unique identifiers?  Most of the time when
 >>> people want unique  > identifiers, they want an identifier
 >>> that is unique across an entire  > program or, at minimum,
 >>> inside a translation unit.
 >>>
 >>> Well... The scope can be the whole program, or in a
 >>> namespace, or in a translation unit. The unique ID is used in
 >>> a macro in the library for some tidious code that can be
 >>> automatically generated using preprocessor.
 >
 >For the record, doing this sort of thing is almost guaranteed to 
produce ODR
 >violations.  With that said...

Well... I think I know what I'm doing now. The use of __LINE__ (or 
__COUNTER__ on MSVC) is working for me after combining with some salt as 
keyword. Thanks for your concern, but the current solution seems suffice 
for me purpose.

 >>> Anyway, thanks for Stewart Tootill's suggestion. I had to
 >>> resort to using __COUNTER__ at the meantime, which seemed
 >>> working so far. (But one thing that worries me is that
 >>> __COUNTER__ is only unique within a translation unit. So what
 >>> if I need a unique identifier throughout the
 >>> program?)
 >
 >The pp-lib contains a similar construct, but it must be manually 
 >updated.  E.g.
 >#include BOOST_PP_UPDATE_COUNTER()
 >BOOST_PP_COUNTER() // 1
 >#include BOOST_PP_UPDATE_COUNTER()
 >BOOST_PP_COUNTER() // 2
 >BOOST_PP_COUNTER() // 2
 >#include BOOST_PP_UPDATE_COUNTER()
 >BOOST_PP_COUNTER() // 3

But this is not documented. :( I didn't know its existence until you 
told me and then I did a grep.)

 >I could provide the means to seed this value for a translation unit, 
but I'm not
 >sure if this is really a good idea.  Thoughts?

I don't think there is a general solution for "all cases" here. (At 
least I don't have one with me right now.) But given some restricted 
usage, this solution actually works out quite well.

BTW, I think I'm still sticking to __LINE__/__COUNTER__ solution for 
now, since it is not possible for me to encode the "#include ..." line 
into my macro.

 >Regards,
 >Paul Mensonides

Thanks a lot for your efforts and insight!

Cheers,

Freddie