Re: [Boost-users] Boost.Preprocessor with __LINE__ in MSVC71
-----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.
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
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. :) 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
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Wu Yinghui, Freddie
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. :)
Maybe. I'm trying to avoid documenting bugs in preprocessor implementations in the docs. For VC++ in particular, this is only one of many.
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.
I'm sure it does. Rarely do compilers diagnose ODR violations. The Typeof library does this also.
#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.)
It is documented, but I can't remember if it has been part of an official release yet. It has been in the CVS for quite a while.
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.
Sure. There are times (very few times, IMO) where it is necessary to intentionally violate the rules defined by the standard. All I'm doing is giving the obligatory warning. Regards, Paul Mensonides
participants (2)
-
Paul Mensonides
-
Wu Yinghui, Freddie