C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Scope control for the preprocessor? Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Peter C. Chapin Guest Posted: Sun Apr 04, 2004 10:59 pm    Post subject: Scope control for the preprocessor? I understand that there are some proposals out there for adding scope control directives to the preprocessor. I did a Google search and turned up some discussion on a Boost mailing list about using #region/#endreg to define a scope and using #import/#export to control macro visibility in and from that scope. The discussion was not particularly detailed, however, and I didn't find anything more on the Boost web page. What is the current status of these ideas? Is a feature like this in the works for the next C++ standard? Are there any documents on-line that describe preprocessor scope control proposals? I am frustrated by the need to decorate names in template bodies with leading underscores in order to reduce potential damage from the preprocessor. Such excessive use of underscores definitely impacts readability in a negative way. The compiler I use is open source and I'm considering the possibility of modifying its preprocessor to support some kind of scope control feature. If I do so, however, I would like to follow the evolving thinking on this matter. Peter [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top White Wolf Guest Posted: Tue Apr 06, 2004 9:08 am    Post subject: Re: Scope control for the preprocessor? Peter C. Chapin wrote: Quote: I understand that there are some proposals out there for adding scope control directives to the preprocessor. I did a Google search and turned up some discussion on a Boost mailing list about using #region/#endreg to define a scope and using #import/#export to control macro visibility in and from that scope. The discussion was not particularly detailed, however, and I didn't find anything more on the Boost web page. AFAIK it is not a Boost proposal and it is not exactly the same as I read above. Quote: What is the current status of these ideas? You could say that it is accepted for further consideration - but the results of the votes can be interpreted in the opposite way as well. AFAIK I am not at the liberty of discussing the actuall votes. However IMHO - since the author of the paper (Bjarne Stroustrup) - was not present, it is fair to say that we should hear about this paper again in the future, when he has the chance to discuss the topic and answer questions/reservations. Quote: Is a feature like this in the works for the next C++ standard? Yes and no. It is in the works, since there is a proposal. It is not, because the proposal has not been unambiguously accepted or rejected. But since its author was not present to "defend it", I would not just give up on it yet. :-) Quote: Are there any documents on-line that describe preprocessor scope control proposals? Not _yet_. The post-Sydney mailing will be on the Web the next week, then you will be able to see it at http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/ since the Committee decided that all but the "impossible to allow" papers of the work will be published to all. Quote: I am frustrated by the need to decorate names in template bodies with leading underscores in order to reduce potential damage from the preprocessor. Such excessive use of underscores definitely impacts readability in a negative way. The compiler I use is open source and I'm considering the possibility of modifying its preprocessor to support some kind of scope control feature. If I do so, however, I would like to follow the evolving thinking on this matter. Then wait a little bit until the proposal matures. As for the leading underscores for the template arguments... I would not do that. Nothing (but habit) says they have to be all uppercase and (IMHO) you can just as easily protect them from macro beasts by prefixing them with lowercase letter(s), such as ta (for template argument). To summarize: you will soon see the first (or second) version of the proposal at the above given official URL. But I advice you not to start implementing it yet, since there is no consensus about the issue, so it may just change - and even an incompatible way to what is proposed today. -- WW aka Attila ::: The programmer's national anthem is 'AAAAAAAARRRRGHHHHH!!'. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top John Potter Guest Posted: Tue Apr 06, 2004 8:43 pm    Post subject: Re: Scope control for the preprocessor? On 4 Apr 2004 18:59:35 -0400, "Peter C. Chapin" <pchapin (AT) sover (DOT) net> wrote: Quote: I am frustrated by the need to decorate names in template bodies with leading underscores in order to reduce potential damage from the preprocessor. Such excessive use of underscores definitely impacts readability in a negative way. I'm not sure that I understand you or that you understand the subject practice. The implementers of the standard library use leading underscores in their template parameters to place them in the implementation reserved namespace. This protects the standard library from user macros in the user namespace. A user which follows the same practice is violating the implementation reserved namespace. Are you a standard library implementer or language user? John [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Peter C. Chapin Guest Posted: Tue Apr 06, 2004 8:44 pm    Post subject: Re: Scope control for the preprocessor? "White Wolf" <wolof (AT) freemail (DOT) hu> wrote in news:c4s85d$kbj$1 (AT) phys-news1 (DOT) kolumbus.fi: Quote: Yes and no. It is in the works, since there is a proposal. It is not, because the proposal has not been unambiguously accepted or rejected. But since its author was not present to "defend it", I would not just give up on it yet. Okay, thanks for the information. I understand that proposals of this nature need to be studied carefully before (or if) they are accepted. I am glad that there is at least some consideration being given to this matter. If export was more widely implemented perhaps it would be less of an issue but currently with large amounts of code in header files, the lack of scope control on the preprocessor is a significant problem, I feel. Quote: Not _yet_. The post-Sydney mailing will be on the Web the next week, then you will be able to see it at http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/ Great! I will look for it. Quote: Then wait a little bit until the proposal matures. As for the leading underscores for the template arguments... I would not do that. Nothing (but habit) says they have to be all uppercase and (IMHO) you can just as easily protect them from macro beasts by prefixing them with lowercase letter(s), such as ta (for template argument). It seems to me that any such decorations reduce readibility. This is particularly true since all local names in function templates also need to be protected from the preprocessor as well. Decorating template argument names, function argument names, and local names produces an effect where one tends to only see the decorations and not the actual logic of the function (look at the code in the STLport headers to see what I mean). In addition no amount of decorations can, in theory, prevent the possibility of corruption by the preprocessor... it can only reduce its probability. Quote: To summarize: you will soon see the first (or second) version of the proposal at the above given official URL. But I advice you not to start implementing it yet, since there is no consensus about the issue, so it may just change - and even an incompatible way to what is proposed today. Okay. Thanks again for your thoughts. I look forward to reading the paper and following developments in this area. Peter [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Peter C. Chapin Guest Posted: Wed Apr 07, 2004 2:33 pm    Post subject: Re: Scope control for the preprocessor? John Potter <jpotter (AT) falcon (DOT) lhup.edu> wrote in news:4wvcc.11749$NL4.1008 @newsread3.news.atl.earthlink.net: Quote: Are you a standard library implementer or language user? I am, potentially at least, a library implementor. My desire is to write templates without fear of molestation from user macros... and without resorting to what I feel is the rather ugly practice of decorating names that, by all rights, should be local to a template body. Is there any other language where a user program can import a module and have that importation change the interpretation of code in another module? When you look at it that way the situation with C/C++ is something of a scandal! For example, consider Ada: with Abc; with Xyz; -- The contents of package Xyz are not corrupted by Abc. How about Java: import abc; import xyz; // The contents of package xyz are not corrupted by abc. Now C++: #include <abc> #include <xyz> // Alas, the contents of xyz might be corrupted by things in abc. It seems like this matter deserves correction... or at least mitigation. Peter [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Hendrik Schober Guest Posted: Wed Apr 07, 2004 7:29 pm    Post subject: Re: Scope control for the preprocessor? Peter C. Chapin <pchapin (AT) sover (DOT) net> wrote: Quote: John Potter <jpotter (AT) falcon (DOT) lhup.edu> wrote in news:4wvcc.11749$NL4.1008 @newsread3.news.atl.earthlink.net: Are you a standard library implementer or language user? I am, potentially at least, a library implementor. [...] If you're not a _std_ lib implementer, your usage of underscores is very limited. Identifiers in global scope starting with an underscore, identifiers starting with an underscore followed by an upper-case letter, and identifiers containing two consecute underscores anywhere are reserved for the implementation. (I am not sure I have this right. I simply avoid leading underscores altogether.) To be specific: This template< typename _T > void f(); is not allowed. Quote: Peter Schobi -- [email]SpamTrap (AT) gmx (DOT) de[/email] is never read I'm Schobi at suespammers dot org "Sometimes compilers are so much more reasonable than people." Scott Meyers [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top White Wolf Guest Posted: Thu Apr 08, 2004 10:41 am    Post subject: Re: Scope control for the preprocessor? Peter C. Chapin wrote: [SNIP] Quote: Decorating template argument names, function argument names, and local names produces an effect where one tends to only see the decorations and not the actual logic of the function (look at the code in the STLport headers to see what I mean). In addition no amount of decorations can, in theory, prevent the possibility of corruption by the preprocessor... it can only reduce its probability. Yes, indeed. However I have assumed that we are talking about probable (likely to happen) collisions (of ALL_UPPERCASE_NAMES) and not possible collisions. If you have code made by a madman #define-ing macros using lowercase letters you are done. How will you make a function (forget templates) which return int? What if int is redefined to char * or MyBigInt? So I do not really understand the fears about function arguments and local variables getting redefined. :-( -- WW aka Attila ::: 'Good manners will open doors that the best education cannot.' -- Clarence Thomas, U.S. Supreme Court Justice [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top White Wolf Guest Posted: Thu Apr 08, 2004 10:45 am    Post subject: Re: Scope control for the preprocessor? Peter C. Chapin wrote: [SNIP] Quote: Is there any other language where a user program can import a module and have that importation change the interpretation of code in another module? When you look at it that way the situation with C/C++ is something of a scandal! Is it? How about ANY language using include files and macros? Like every assembler I have ever used. Like CA-Clipper and its clones. Like C... And you can continue for long. While the preprocessor is not the nicest thing for todays use, it is at least insulting to cry scandal while you seem to see no difference between *modules* and *headers* - which questions your understanding of the topic. C++ has no notion of modules, it has translation units. And you are right, it is not Ada and it is not Java. The latter makes me feel good. However crying scandal (while not knowing the reasons and showing no signs of even trying) will not get you closer to what you want. People have told you, that using leading underbars to protect your names is illegal. They told this to help you, not to make you defensive. Please give them the courtesy of not judging them too fast. And give the courtesy to the people who have designed this language (many on their own time) by not rushing to conclusions while examining the design from a very limited perspective. I can assure you that most of us would like to get rid of the C preprocessor and have something much nicer instead. But none of us can seriously say that it is even remotely possible. There are too many tools, libraries, existing code etc. depending on it. Steps are taken to ease your work, but it will not encourage those making these steps if you attack them. -- WW aka Attila ::: Geologists rock your world. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Beman Dawes Guest Posted: Thu Apr 08, 2004 10:52 am    Post subject: Re: Scope control for the preprocessor? "Peter C. Chapin" <pchapin (AT) sover (DOT) net> wrote Quote: ... The compiler I use is open source and I'm considering the possibility of modifying its preprocessor to support some kind of scope control feature. You might want to check out the Wave C/C++ preprocessor at http://www.codeproject.com/cpp/wave_preprocessor.asp IIRC, they have already implemented various proposals for preprocessor improvements. Wave is built with Spirit and other Boost tools. --Beman [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Joe Greer Guest Posted: Thu Apr 08, 2004 11:46 pm    Post subject: Re: Scope control for the preprocessor? I think the root problem is the lack of a module mechanism in C++. Namespaces can help, but not entirely. For example, it would help protect against the template function lying in the background waiting to accept your function call with an invalid argument. There is also an issue of access rights. You want to expose a certain interface to your users, but your implementation requires other classes which need more from your class than your users will, but you have to add methods to the public interface to allow your implementation classes access. friend-ship is too much like using a 16lb hammer to hang a picture, so what do you do? The preprocessor has it's uses and will always have the ability to mess things up, but I think true modules would help. joe [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Peter C. Chapin Guest Posted: Fri Apr 09, 2004 11:33 am    Post subject: Re: Scope control for the preprocessor? "White Wolf" <wolof (AT) freemail (DOT) hu> wrote in news:c51mps$3e8$1@phys- news1.kolumbus.fi: Quote: Yes, indeed. However I have assumed that we are talking about probable (likely to happen) collisions (of ALL_UPPERCASE_NAMES) and not possible collisions. If you have code made by a madman #define-ing macros using lowercase letters you are done. Well, there are examples of such macros... for example getc and getchar from the C standard library. Furthermore the C standard specifically states that *any* function in the library might actually be a macro. Thus the following is dangerous to have in a header file: inline int some_function(int pow) { return pow + 1; } If math.h is #included before the header that contains this inline function then "pow" might be a macro and syntax errors could result. Of course I could #undef pow before defining the above, but that might break later uses of the pow macro downstream. I've also known of cases where people have created a macro replacement for an ordinary function in an effort to "edit" source files using such a function. For example #define malloc(x) my_malloc(x) This technique might be used even for functions I know nothing about #define first(x) my_first(x) Thus effectively preventing me from using "first" as a name in anything that might appear in a header. Finally there are cases where a programmer might want to use uppercase letters in names without fear of preprocessor molestation. Consider namespace myspace { enum color { RED, GREEN, BLUE }; } As far as the C++ language is concerned the names "RED", "GREEN", and "BLUE" are nicely protected from material in other headers (here I assume the author has full control over "myspace"). However, a macro definition of RED can cause a syntax error in the enum definition. (I've been burned by this situation several times). Peter [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Peter C. Chapin Guest Posted: Fri Apr 09, 2004 11:48 am    Post subject: Re: Scope control for the preprocessor? "White Wolf" <wolof (AT) freemail (DOT) hu> wrote in news:c51oli$5qf$1 (AT) phys-news1 (DOT) kolumbus.fi: Quote: Is it? How about ANY language using include files and macros? Like every assembler I have ever used. Like CA-Clipper and its clones. Like C... I'm not familiar with CA-Clipper, but I would say that assembler and C are also rather primitive in this regard. Quote: While the preprocessor is not the nicest thing for todays use, it is at least insulting to cry scandal while you seem to see no difference between *modules* and *headers* - which questions your understanding of the topic. I didn't mean to cause offense. Let me assure you that I have a high degree of respect for C++ or I wouldn't be spending so much time working with it. However, textually including declarations in a translation unit in order to make them visible to that unit is a weakness of the language and it causes problems. This seems indisputable to me. The #include directive is used to introduce declarations of functions, types, and templates. In this respect the mechanism serves the same purpose as, for example, "withing" a package in Ada. This is fine. However, one kind of entity that can be introduced into a program by #include is the preprocessor macro. The problem with macros is that they do not honor any of the normal scope rules and thus have the potential to edit, and thus destroy, declarations that have been introduced by other headers. This means that, in effect, the importation of one module into a translation unit is modifying the interpretation of another, independent module that is also imported into that translation unit---an unthinkable occurance in many other languages. Quote: People have told you, that using leading underbars to protect your names is illegal. That's fine. I'd just as soon not use leading underscores. I think they make the code difficult to read. However, I understand the need. For example extern int printf(const char *__format, ...); Using just "format" here is possibly more dangerous than "__format". However, I'm not too worried about who can use underscores and who can't. What I'm looking for is a way to decisively prevent the preprocessor from mangling what I put in my header files. This is a problem that any programer faces: compiler vendor or language user. Even if the compiler vendor can use names in the implementation namespace, that doesn't really help the language user protect him/herself from macros introduced by other language users. Quote: I can assure you that most of us would like to get rid of the C preprocessor and have something much nicer instead. But none of us can seriously say that it is even remotely possible. I'm not asking to remove the preprocessor. That is obviously not going to happen. However, I am interested in proposals for adding scope control features to the preprocessor. Removing the preprocessor is infeasible and possibily not even desirable (there are many neat things that can be done with it). However, we can, perhaps, make the preprocessor smarter and greatly reduce the difficulties that it causes in this area. To put this conversation into context, I am toying with the idea of writing an STL for Open Watcom. When I look at other STL implementations, for example, the ones in gcc or STLport, I can't help but notice the heavy use of underscores for even local names that the language says are protected. I can only assume this was done to protect all those names from preprocessor mangling. However, I find that unacceptable... it's just too ugly for words. Instead I'd rather modify the Open Watcom preprocessor to implement some sort of scope control feature (even if an extremely minimal one for Open Watcom's internal use only) and then use that feature to protect the library headers I create. Obviously, though, if I'm going to spend time implementing scope control in Open Watcom's preprocessor I'd like to do so in a way that is at least somewhat in line with the evolving C++ standard. That was the motivation for my original post. Peter [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top P.J. Plauger Guest Posted: Fri Apr 09, 2004 9:15 pm    Post subject: Re: Scope control for the preprocessor? "Peter C. Chapin" <pchapin (AT) sover (DOT) net> wrote Quote: "White Wolf" <wolof (AT) freemail (DOT) hu> wrote in news:c51mps$3e8$1@phys- news1.kolumbus.fi: Yes, indeed. However I have assumed that we are talking about probable (likely to happen) collisions (of ALL_UPPERCASE_NAMES) and not possible collisions. If you have code made by a madman #define-ing macros using lowercase letters you are done. Well, there are examples of such macros... for example getc and getchar from the C standard library. Furthermore the C standard specifically states that *any* function in the library might actually be a macro. Thus the following is dangerous to have in a header file: inline int some_function(int pow) { return pow + 1; } Not in C90 because it doesn't support inlines. Not in C99 because pow can only be a function macro, which causes no replacement in the above. Not in C++ because the C library is explicitly prohibited from using macro overrides for any of its functions (except for setjmp which must *always* be a macro in C++). Quote: If math.h is #included before the header that contains this inline function then "pow" might be a macro and syntax errors could result. Not with the example you gave. Quote: Of course I could #undef pow before defining the above, but that might break later uses of the pow macro downstream. Shouldn't, because the C Standard requires that math.h first declare pow as a header, then optionally mask it with a macro of the same name. If you undef the macro you simply expose the underlying function declaration, which had better work the same way. Quote: I've also known of cases where people have created a macro replacement for an ordinary function in an effort to "edit" source files using such a function. For example #define malloc(x) my_malloc(x) And this is explicitly disallowed by the C Standard. Quote: This technique might be used even for functions I know nothing about #define first(x) my_first(x) Thus effectively preventing me from using "first" as a name in anything that might appear in a header. Exactly, which is why all conforming headers use names like _First instead of first. Quote: Finally there are cases where a programmer might want to use uppercase letters in names without fear of preprocessor molestation. Consider namespace myspace { enum color { RED, GREEN, BLUE }; } As far as the C++ language is concerned the names "RED", "GREEN", and "BLUE" are nicely protected from material in other headers (here I assume the author has full control over "myspace"). However, a macro definition of RED can cause a syntax error in the enum definition. (I've been burned by this situation several times). But not by the standard headers, which are prohibited from defining names like this as macros. P.J. Plauger Dinkumware, Ltd. http://www.dinkumware.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Paul Mensonides Guest Posted: Sat Apr 10, 2004 11:55 am    Post subject: Re: Scope control for the preprocessor? "Peter C. Chapin" <pchapin (AT) sover (DOT) net> wrote Quote: "White Wolf" <wolof (AT) freemail (DOT) hu> wrote in news:c51mps$3e8$1@phys- news1.kolumbus.fi: Yes, indeed. However I have assumed that we are talking about probable (likely to happen) collisions (of ALL_UPPERCASE_NAMES) and not possible collisions. If you have code made by a madman #define-ing macros using lowercase letters you are done. Well, there are examples of such macros... for example getc and getchar from the C standard library. Furthermore the C standard specifically states that *any* function in the library might actually be a macro. Thus the following is dangerous to have in a header file: inline int some_function(int pow) { return pow + 1; } If math.h is #included before the header that contains this inline function then "pow" might be a macro and syntax errors could result. Of course I could #undef pow before defining the above, but that might break later uses of the pow macro downstream. Even if pow was implemented as an object-like macro that expanded to a function-like macro or a name for some other kind of construct such as a function, why is the existence of something causing an error surprising? That can happen from many parts of the language that have nothing to do with the preprocessor. Consider, for example, how many template metaprograms break with a definition like this in the right place (given a conformant compiler): template<class T, class U> T operator+(T, U); With this declaration, many constant expressions involving enumerations are no longer constant expressions. The minor problem is that macro definitions dominate names such that they cannot, in general, be used for other purposes. This is one of the reasons for guidelines like macro names should be entirely in uppercase and macro definitions should be #undef'd when they are no longer necessary. However, every once in a while, names that don't follow those guidelines slip through. The majority (by far) are caught as compilation errors when they are accidentally invoked. The major problem is not macro definitions that cause compilation errors, but macro definitions that make accidental silent changes that don't cause compilation errors. This happens, but not very often. Quote: I've also known of cases where people have created a macro replacement for an ordinary function in an effort to "edit" source files using such a function. For example #define malloc(x) my_malloc(x) This technique might be used even for functions I know nothing about #define first(x) my_first(x) Thus effectively preventing me from using "first" as a name in anything that might appear in a header. This is a faulty header that needs to be fixed. No code should *ever* let a lowercase macro name escape unless it is explicitly intended and documented as an interface. Even in that case, lowercase macro names should be avoided. Quote: Finally there are cases where a programmer might want to use uppercase letters in names without fear of preprocessor molestation. Consider namespace myspace { enum color { RED, GREEN, BLUE }; } As far as the C++ language is concerned the names "RED", "GREEN", and "BLUE" are nicely protected from material in other headers (here I assume the author has full control over "myspace"). Why would you assume that the author has full control over "myspace"? It is easy to break that header: // yourheader.h namespace myspace { enum color { RED, GREEN, BLUE }; } // myheader.h namespace myspace { struct RED { }; } // trans.cpp #include "myheader.h" #include "yourheader.h" The point is that the code is actually *not* protected from breakage by any language feature at all. Namespaces and scopes are effectively a way to structure and classify a set of interfaces (and by extension, names). They are not a protection mechanism against name clashes. Granted, the above will always yield a compile-time error, which is fine, but that is not always the case. There are ways of causing link-time errors and ways of causing silent changes. Hence, there are idioms and guidelines used in coding, and things break when those idioms and guidelines are not followed. Quote: However, a macro definition of RED can cause a syntax error in the enum definition. (I've been burned by this situation several times). There is no legitimate excuse for naming non-macros (such as enumerators) with all uppercase letters. This is not an issue of preference, but of code quality and robustness. Here is the guideline in full.... Define all non-local macros with all uppercase names, use all uppercase names for *nothing* else, and undef all local macros. Otherwise, you defeat the purpose of the guideline and get "burned". I'm certainly not saying that it isn't annoying that macro definitions dominate names, because it is. However, the problems that it causes are almost always obvious compile-time errors (as a direct result of people not following good coding practices). Very rarely does a "loose" macro name collide with a core language name in such a way that compilation does not yield errors. The problem is not nearly as big as some make it out to be because of coding guidelines that apply to macros just as they apply to all other constructs in the language. Failure to adhere to such guidelines leads to problems with macros or anything else. Further, the ability of a macro to restructure or change tokens in a way that ignores the syntax and semantics of the language proper is a critically useful tool. It is powerful, and as such, it must be used carefully and only when the use of it offers significant benefits. Regards, Paul Mensonides [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Paul Mensonides Guest Posted: Sat Apr 10, 2004 6:22 pm    Post subject: Re: Scope control for the preprocessor? "Paul Mensonides" <leavings (AT) comcast (DOT) net> wrote Quote: // yourheader.h namespace myspace { enum color { RED, GREEN, BLUE }; } // myheader.h namespace myspace { struct RED { }; } // trans.cpp #include "myheader.h" #include "yourheader.h" Oops, those two can coexist. Make that: // myheader.h namespace myspace { static const int RED = 1; } Regards, Paul Mensonides [ 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 Goto page 1, 2  Next Page 1 of 2   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.