C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  __LINE__          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Ermo Guest Posted: Sun Jul 25, 2004 12:23 am    Post subject: __LINE__ I've always thought __LINE__ macro was handled by the preprocessor, and so: #define NEWLABEL Label##__LINE__ would have expanded in Label1 if NEWLABEL was placed on the first line, Label2 on the second line , Label3 on the third line and so on... I was wrong! The macro always expand to Label__LINE__. Anyway, is there a method to get the former behaviour? Thanks. -- Replace "fake" with "muchomail" for real address [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alf P. Steinbach Guest Posted: Sun Jul 25, 2004 10:56 am    Post subject: Re: __LINE__ * Ermo: Quote: I've always thought __LINE__ macro was handled by the preprocessor, It is. Quote: and so: #define NEWLABEL Label##__LINE__ would have expanded in Label1 if NEWLABEL was placed on the first line, Label2 on the second line , Label3 on the third line and so on... I was wrong! The macro always expand to Label__LINE__. That's the effect of '##' -- try it with any other macro name and you'll get the same effect. Quote: Anyway, is there a method to get the former behaviour? Generally, send __LINE__ through two levels of "expansion" macros, like so (this is from my personal modified version of the ScopeGuard header): #define CONCATENATE_DIRECT(s1, s2) s1##s2 #define CONCATENATE(s1, s2) CONCATENATE_DIRECT(s1, s2) #ifdef _MSC_VER // Necessary for edit & continue in MS Visual C++. # define ANONYMOUS_VARIABLE(str) CONCATENATE(str, __COUNTER__) #else # define ANONYMOUS_VARIABLE(str) CONCATENATE(str, __LINE__) #endif Note the check for Microsoft Visual C++. The __LINE__ macro is very very broken in Visual C++ 7.1, so it doesn't compile ScopeGuard correctly (also lots of other stuff it doesn't handle correctly, rambling, std::auto_ptr, rambling, friend, rambling, grrrr!). -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Seungbeom Kim Guest Posted: Sun Jul 25, 2004 9:31 pm    Post subject: Re: __LINE__ Ermo wrote: Quote: I've always thought __LINE__ macro was handled by the preprocessor, and so: #define NEWLABEL Label##__LINE__ would have expanded in Label1 if NEWLABEL was placed on the first line, Label2 on the second line , Label3 on the third line and so on... I was wrong! The macro always expand to Label__LINE__. Even if the problem were solved as Alf P. Steinbach had suggested, how are you going to refer to that label elsewhere in the program? -- Seungbeom Kim [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top John Torjo Guest Posted: Mon Jul 26, 2004 1:01 pm    Post subject: Re: __LINE__ Seungbeom Kim <musiphil (AT) bawi (DOT) org> wrote Quote: Ermo wrote: I've always thought __LINE__ macro was handled by the preprocessor, and so: #define NEWLABEL Label##__LINE__ would have expanded in Label1 if NEWLABEL was placed on the first line, Label2 on the second line , Label3 on the third line and so on... I was wrong! The macro always expand to Label__LINE__. Even if the problem were solved as Alf P. Steinbach had suggested, how are you going to refer to that label elsewhere in the program? I guess he'll never use such a thing directly. I sometimes need things like these myself - for static initialization for instance (when I need to generate a unique name). Best, John John Torjo Freelancer -- [email]john (AT) torjo (DOT) com[/email] Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32) (source code available) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ben Hutchings Guest Posted: Mon Jul 26, 2004 10:50 pm    Post subject: Re: __LINE__ Ermo wrote: Quote: I've always thought __LINE__ macro was handled by the preprocessor, and so: #define NEWLABEL Label##__LINE__ would have expanded in Label1 if NEWLABEL was placed on the first line, Label2 on the second line , Label3 on the third line and so on... I was wrong! The macro always expand to Label__LINE__. Anyway, is there a method to get the former behaviour? Macro references are expanded like this: 1. Parameter names are replaced by the corresponding arguments, thus: - If the name is preceded or followed by "##" it is replaced by the unmodified argument token sequence. - If the name is preceded by "#", the "#" and the name are replaced by a string literal containing the argument's tokens with spaces between them. - Otherwise it is replaced by the macro-expansion of the corresponding argument. 2. Each "##" and the tokens before and after it are replaced by a token that is the concatenation of the two (if possible). 3. The result is macro-expanded again, except for macro references that would cause recursion. So your macro doesn't work because the token concatenation is done before __LINE__ can be expanded. You can avoid this by referring to another macro that does the concatenation: #define NEWLABEL CONCAT(Label, __LINE__) Even CONCAT can't do the concatenation directly, though, because "##" inhibits macro expansion in arguments. Instead it has to refer to a third macro: #define CONCAT(x, y) CONCAT2(x, y) #define CONCAT2(x, y) x ## y So NEWLABEL expands to CONCAT(Label, __LINE__) expands to CONCAT2(Label, <line-number>) expands to Label ## <line-number> becomes Label<line-number> [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Allan W Guest Posted: Tue Jul 27, 2004 10:47 am    Post subject: Re: __LINE__ Quote: Ermo wrote: #define NEWLABEL Label##__LINE__ I was wrong! The macro always expand to Label__LINE__. Seungbeom Kim <musiphil (AT) bawi (DOT) org> wrote Even if the problem were solved as Alf P. Steinbach had suggested, how are you going to refer to that label elsewhere in the program? [email]jtorjo (AT) yahoo (DOT) com[/email] (John Torjo) wrote Quote: I guess he'll never use such a thing directly. I sometimes need things like these myself - for static initialization for instance (when I need to generate a unique name). A superior way is to use a simple name, surrounded by braces for a local scope. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ermo Guest Posted: Wed Jul 28, 2004 2:39 am    Post subject: Re: __LINE__ Quote: how are you going to refer to that label elsewhere in the program? I'm using the CPP for an assembly source and I'd like to be able to refer jumps to unique labels inside macros. -- Replace "fake" with "muchomail" for real address [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.