Re: [Boost-users] Boost.Preprocessor with __LINE__ in MSVC71
What is going wrong? I tried it on VC7, VC7.1, and VC8, and it appeared to work correctly on all three versions of the compiler.
Does anyone on the list has more insight on this issue?
I've seen strange problems related to __LINE__ on VC before, but I can't remember off the top of my head what the issue was. (Thinking...) It has something to do with the generation of debug information. Okay, yes, I see the error that you are getting now. It only happens in during a debug build.
You are right. It occurs only in debug builds. (Sorry for forgetting to mention this.)
This is just one of the *many* ways in which VC's preprocessor is wacky. It suffices to say it isn't even in the ballpark of implementing the phases of translation correctly.
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...
Or, what're the common ways to generate an unique identifier automatically within certain scope?
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. 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?)
Regards, Paul Mensonides
Thanks for your comments. Cheers, Freddie
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Wu Yinghui, Freddie
This is just one of the *many* ways in which VC's preprocessor is > wacky. It suffices to say it isn't even in the ballpark of > implementing the phases of translation correctly.
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 produce ODR violations. With that said...
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 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? Regards, Paul Mensonides
participants (2)
-
Paul Mensonides -
Wu Yinghui, Freddie