Boost.Preprocessor with __LINE__ in MSVC71

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Boost.Preprocessor with __LINE__ in MSVC71

Wu Yinghui, Freddie
Hi all,

I'm observing an interesting problem on MSVC71 regarding the use of
__LINE__ with Boost.Preprocessor.

The code looks like this
==== snip ====
#include <boost/preprocessor/cat.hpp>
#define UNIQUE_ID   BOOST_PP_CAT(id, __LINE__)
#define UNIQUE_ID2   BOOST_PP_CAT(id, _MSC_VER)
int main()
{
     int UNIQUE_ID2 = 321;
     int UNIQUE_ID = 123;
     bool UNIQUE_ID = false;
}
==== snip ====

The compiler works fine with UNIQUE_ID2, but not UNIQUE_ID. The only
different in them is only the use of __LINE__ instead of _MSC_VER.

Does anyone on the list has more insight on this issue?

Or, what're the common ways to generate an unique identifier
automatically within certain scope?

Cheers,

Freddie

--
Wu Yinghui, Freddie
Research & Development
Software Engineer

Volume Interactions Pte Ltd
1 Kim Seng Promenade, #12-01
Great World City East Tower
Singapore 237994
Tel:   +65 62226962 (Ext 216)
Fax:   +65 62226215
Email: [hidden email]
URL:   http://www.volumeinteractions.com

Important:  This message is intended for the recipient(s) addressed
above.  It contains privileged and confidential information.  If you are
not the intended recipient, please notify the sender immediately by
replying to this message and then delete it from your system.  You must
not read, copy, use, or disseminate this communication in any form.
Thank you.

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users

yhwu.vcf (800 bytes) Download Attachment
signature.asc (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Preprocessor with __LINE__ in MSVC71

Stewart Tootill
There is a known bug with MSVC71 where if you use __LINE__ too much (not sure what the limits are or under what circumstances though), you get a "Fatal Error: Out of Keys" or something similar. Instead of this, for generating unique variable names etc I have seen the __COUNTER__ macro used instead, which provides similar functionality, but doesn't seem to suffer from this issue.

Yours,

Stewart

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of Wu Yinghui,
Freddie
Sent: 08 March 2006 09:00
To: [hidden email]
Subject: [Boost-users] Boost.Preprocessor with __LINE__ in MSVC71


Hi all,

I'm observing an interesting problem on MSVC71 regarding the use of
__LINE__ with Boost.Preprocessor.

The code looks like this
==== snip ====
#include <boost/preprocessor/cat.hpp>
#define UNIQUE_ID   BOOST_PP_CAT(id, __LINE__)
#define UNIQUE_ID2   BOOST_PP_CAT(id, _MSC_VER)
int main()
{
     int UNIQUE_ID2 = 321;
     int UNIQUE_ID = 123;
     bool UNIQUE_ID = false;
}
==== snip ====

The compiler works fine with UNIQUE_ID2, but not UNIQUE_ID. The only
different in them is only the use of __LINE__ instead of _MSC_VER.

Does anyone on the list has more insight on this issue?

Or, what're the common ways to generate an unique identifier
automatically within certain scope?

Cheers,

Freddie

--
Wu Yinghui, Freddie
Research & Development
Software Engineer

Volume Interactions Pte Ltd
1 Kim Seng Promenade, #12-01
Great World City East Tower
Singapore 237994
Tel:   +65 62226962 (Ext 216)
Fax:   +65 62226215
Email: [hidden email]
URL:   http://www.volumeinteractions.com

Important:  This message is intended for the recipient(s) addressed
above.  It contains privileged and confidential information.  If you are
not the intended recipient, please notify the sender immediately by
replying to this message and then delete it from your system.  You must
not read, copy, use, or disseminate this communication in any form.
Thank you.


________________________________________________________________________
This e-mail has been scanned for viruses by MessageLabs.

________________________________________________________________________
This e-mail has been scanned for viruses by MessageLabs.

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Preprocessor with __LINE__ in MSVC71

Paul Mensonides
In reply to this post by Wu Yinghui, Freddie
> -----Original Message-----
> [mailto:[hidden email]] On Behalf Of Wu
> Yinghui, Freddie

> Hi all,
>
> I'm observing an interesting problem on MSVC71 regarding the
> use of __LINE__ with Boost.Preprocessor.
>
> The code looks like this
> ==== snip ====
> #include <boost/preprocessor/cat.hpp>
> #define UNIQUE_ID   BOOST_PP_CAT(id, __LINE__)
> #define UNIQUE_ID2   BOOST_PP_CAT(id, _MSC_VER)
> int main()
> {
>      int UNIQUE_ID2 = 321;
>      int UNIQUE_ID = 123;
>      bool UNIQUE_ID = false;
> }
> ==== snip ====
>
> The compiler works fine with UNIQUE_ID2, but not UNIQUE_ID.
> The only different in them is only the use of __LINE__
> instead of _MSC_VER.

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.

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.

> 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.

Regards,
Paul Mensonides

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Preprocessor with __LINE__ in MSVC71

Paweł Sikora
Dnia środa, 8 marca 2006 10:31, Paul Mensonides napisał:

> > 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.

the __line__ is a *variable* in default m$ debug format, so change
DebugInformationFormat="4" -> "3" in *.vcproj or select appriopriate
option in project gui.

--
to_be || !to_be == 1, to_be | ~to_be == -1

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Preprocessor with __LINE__ in MSVC71

Wu Yinghui, Freddie
In reply to this post by Wu Yinghui, Freddie
 > 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

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users

yhwu.vcf (798 bytes) Download Attachment
signature.asc (193 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Preprocessor with __LINE__ in MSVC71

Sohail Somani
In reply to this post by Wu Yinghui, Freddie
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Wu
> Yinghui, Freddie
> Sent: Wednesday, March 08, 2006 5:45 AM
> To: [hidden email]
> Subject: 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.)

When your debug information is for edit and continue iirc.

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Preprocessor with __LINE__ in MSVC71

Paul Mensonides
In reply to this post by Wu Yinghui, Freddie
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] 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

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Preprocessor with __LINE__ in MSVC71

Wu Yinghui, Freddie
In reply to this post by Wu Yinghui, Freddie
 >>> -----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

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users

yhwu.vcf (800 bytes) Download Attachment
signature.asc (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Preprocessor with __LINE__ in MSVC71

Paul Mensonides
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] 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

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users