C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  namespaces, class libraries, and VERY large projects Goto page 1, 2, 3  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Guest Posted: Wed Aug 23, 2006 11:23 pm    Post subject: namespaces, class libraries, and VERY large projects I have a question about the way people choose to partition large C++ projects (millions of LOC, lots of class libraries) using namespaces. I have seen three ways of doing it which will be discussed below: As an example, suppose we have libraries A, B, C and D. Suppose A is the foundation library, B and C use it, and D uses B and C and also makes direct calls to stuff in A. 1. Give each class library its own namespace, qualify all usage. Consider code in C. It will have to qualify stuff coming from A and B. Similarly, in D, the code will have to qualify stuff coming from A, B and C. 2. Give each class library its own namespace, employ "using namespace" for all used namespaces at the start of each ".cpp" file. For source in D this will often mean saying: using namespace A; using namespace B; using namespace C; at the start of each ".cpp". 3. Employ nested namespaces. A is the outermost, then B, then C (even though they are peers), then D. No qualifications are needed anywhere, neither are using directives. Historically I have always used (1) but I worry about excessive qualifications that could be distracting when applied to very large projects. I have always avoided (2) since it seems to me to open up ambiguities that namespaces are supposed to avoid. I have only recently come across (3) and have not yet made up my mind about it. Regards, Andrew Marlow [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Maxim Yegorushkin Guest Posted: Thu Aug 24, 2006 2:34 am    Post subject: Re: namespaces, class libraries, and VERY large projects apm35 (AT) student (DOT) open.ac.uk wrote: Quote: I have a question about the way people choose to partition large C++ projects (millions of LOC, lots of class libraries) using namespaces. I have seen three ways of doing it which will be discussed below: As an example, suppose we have libraries A, B, C and D. Suppose A is the foundation library, B and C use it, and D uses B and C and also makes direct calls to stuff in A. 2. Give each class library its own namespace, employ "using namespace" for all used namespaces at the start of each ".cpp" file. For source in D this will often mean saying: using namespace A; using namespace B; using namespace C; at the start of each ".cpp". [] Quote: I have always avoided (2) since it seems to me to open up ambiguities that namespaces are supposed to avoid. You could just give it a try and see if names clash. If they do you can always disambiguate by again fully qualifying the name of by adding using X::Y;. It might be not worth your worries. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top albrecht.fritzsche Guest Posted: Thu Aug 24, 2006 2:37 am    Post subject: Re: namespaces, class libraries, and VERY large projects apm35 (AT) student (DOT) open.ac.uk wrote: Quote: I have seen three ways of doing it which will be discussed below: As an example, suppose we have libraries A, B, C and D. Suppose A is the foundation library, B and C use it, and D uses B and C and also makes direct calls to stuff in A. 1. Give each class library its own namespace, qualify all usage. 2. Give each class library its own namespace, employ "using namespace" for all used namespaces at the start of each ".cpp" file. 3. Employ nested namespaces. A is the outermost, then B, then C (even though they are peers), then D. No qualifications are needed anywhere, neither are using directives. Historically I have always used (1) but I worry about excessive qualifications that could be distracting when applied to very large projects. I have always avoided (2) since it seems to me to open up ambiguities that namespaces are supposed to avoid. Why not using both - using (1) is the "correct" way. But what is wrong with using (2) (moderately) in your source files? The compiler will always tell you if it cannot decide between names from different namespaces. It is for me a compromise - yes, writing std::endl 100 times in a cpp file is correct, but having a using std::endl; or using namespace std; on top OTOH might improve the readability and ease of coding and still being correct. So, my answer would be the canonical "it depends...". But I haven't seen (3) with namespace nesting according to conceptional dependencies - the only namespace nesting I am used to is something like (at its extreme) namespace COMPANY_NAME { namespace PRODUCT_NAME { namespace LIBRARY_NAME { ... } } } Ali [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze Guest Posted: Thu Aug 24, 2006 6:33 pm    Post subject: Re: namespaces, class libraries, and VERY large projects apm35 (AT) student (DOT) open.ac.uk wrote: Quote: I have a question about the way people choose to partition large C++ projects (millions of LOC, lots of class libraries) using namespaces. I have seen three ways of doing it which will be discussed below: As an example, suppose we have libraries A, B, C and D. Suppose A is the foundation library, B and C use it, and D uses B and C and also makes direct calls to stuff in A. 1. Give each class library its own namespace, qualify all usage. Consider code in C. It will have to qualify stuff coming from A and B. Similarly, in D, the code will have to qualify stuff coming from A, B and C. 2. Give each class library its own namespace, employ "using namespace" for all used namespaces at the start of each ".cpp" file. For source in D this will often mean saying: using namespace A; using namespace B; using namespace C; at the start of each ".cpp". 3. Employ nested namespaces. A is the outermost, then B, then C (even though they are peers), then D. No qualifications are needed anywhere, neither are using directives. Historically I have always used (1) but I worry about excessive qualifications that could be distracting when applied to very large projects. I have always avoided (2) since it seems to me to open up ambiguities that namespaces are supposed to avoid. I have only recently come across (3) and have not yet made up my mind about it. I've only seen (1) in actual practice. (3) seems abherant. On very large projects, it's not unusual to define a single fassade class to interface with each subsystem (or sometimes two or more, if the subsystem presents different views). In such cases, a "using A::Fassade" at the start of the source file would be a quite acceptable variant of (2). Generally, however, I prefer to be very explicit when addressing another subsystem, and make it clear, even in the body of the code, what is external. The qualifications aren't excessive, but contain information which I would consider important. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top jk Guest Posted: Thu Aug 24, 2006 6:38 pm    Post subject: Re: namespaces, class libraries, and VERY large projects as others say either 1 or 2 are fine. 3 sounds a little iffy as you are implying a hierarchy which doesnt exist? Quote: I have always avoided (2) since it seems to me to open up ambiguities that namespaces are supposed to avoid. (as you probably know) using declarations and directives are fine as long as you dont stick them in your headers. If you get a nameclash you can explictly resolve it as the libraries are still in their respective namespaces. note how, although this is a clash, it differs from the case of two libraries clashing without the use of namespaces considerably . Mostly id expect library name clashes to be pretty rare hence you'd get most value out of just putting a using directive at the top of each implementaion file, but your milage may vary, especially if you are using two libraries which do similar things. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alan McKenney Guest Posted: Thu Aug 24, 2006 6:56 pm    Post subject: Re: namespaces, class libraries, and VERY large projects Maxim Yegorushkin wrote: Quote: apm35 (AT) student (DOT) open.ac.uk wrote: I have a question about the way people choose to partition large C++ projects (millions of LOC, lots of class libraries) using namespaces. <snip> Quote: 2. Give each class library its own namespace, employ "using namespace" for all used namespaces at the start of each ".cpp" file. <snip> Quote: I have always avoided (2) since it seems to me to open up ambiguities that namespaces are supposed to avoid. You could just give it a try and see if names clash. If they do you can always disambiguate by again fully qualifying the name of by adding using X::Y;. It might be not worth your worries. Maxim, you may be right in this case, but this approach -- what I call the "let's jump off that bridge when we come to it" approach -- can be really expensive in the long run. I've had a fair amount of experience with multi-million LOC projects, and I've found, over and over again, that the cost of a wrong decision about structure can be high over the long haul. It starts out small, but as your project gets more mature, a sub-optimal decision ends up being a constant drain on programming time, maintenance time, and training time. Unfortunately, by the time you realize it was a mistake, it's too expensive to change it. (Typically, you'd have to essentially rewrite your entire code base.) Decisions consciously made with considerable discussion and forethought from the beginning can be sub-optimal, but decisions made without a lot of thought are far more often the ones that you spend the rest of the life of the project cursing. Now, it's not always possible to make correct decisions in advance -- (a) you don't really understand what you'll need until you've already done the project, (b) even when you're done, you don't know the costs that an alternate approach might have incurred, and (c) requirements change substantially, even during the (initial) development phase of a project, so as to invalidate the assumptions on which your initial choices were made. But still, I think the OP was right to try to find out what other people's experience is, so as to at least avoid making a well-known mistake (better to make a new, untried mistake.) -- Alan McKenney [line eater fodder] [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Nicola Musatti Guest Posted: Thu Aug 24, 2006 11:06 pm    Post subject: Re: namespaces, class libraries, and VERY large projects apm35 (AT) student (DOT) open.ac.uk wrote: [slightly reordered:] Quote: 1. Give each class library its own namespace, qualify all usage. Consider code in C. It will have to qualify stuff coming from A and B. Similarly, in D, the code will have to qualify stuff coming from A, B and C. Historically I have always used (1) but I worry about excessive qualifications that could be distracting when applied to very large projects. If you avoid namespace nesting you can limit the tedium and clutter caused by qualification. Quote: 2. Give each class library its own namespace, employ "using namespace" for all used namespaces at the start of each ".cpp" file. For source in D this will often mean saying: using namespace A; using namespace B; using namespace C; at the start of each ".cpp". I have always avoided (2) since it seems to me to open up ambiguities that namespaces are supposed to avoid. As long as you're in control of your own code this shouldn't be a real problem, but in the kind of project you have in mind you're not in control of any portion of code almost by definition. A possible compromise could be to stick to (1) in general, but to insert using directives within functions or even blocks that actually happen to be too cluttered or where you need to exercise a form of control on overload resolution. Quote: 3. Employ nested namespaces. A is the outermost, then B, then C (even though they are peers), then D. No qualifications are needed anywhere, neither are using directives. I have only recently come across (3) and have not yet made up my mind about it. I consider the evident mismatch between the use relationships among libraries and the way namespaces are supposed to nest a strong evidence that this is not a correct approach. Cheers, Nicola Musatti [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Guest Posted: Thu Aug 24, 2006 11:08 pm    Post subject: Re: namespaces, class libraries, and VERY large projects kanze wrote: Quote: apm35 (AT) student (DOT) open.ac.uk wrote: I have a question about the way people choose to partition large C++ projects (millions of LOC, lots of class libraries) using namespaces. [snip] I have seen three ways of doing it 1. Give each class library its own namespace, qualify all usage. [snip] Historically I have always used (1) but I worry about excessive qualifications that could be distracting when applied to very large projects. I have always avoided (2) since it seems to me to open up ambiguities that namespaces are supposed to avoid. I have only recently come across (3) and have not yet made up my mind about it. I've only seen (1) in actual practice. (3) seems abherant. (3) seems very odd (ahem) to me also. I thought I would see if anyome had come across it. Quote: I prefer to be very explicit when addressing another subsystem, and make it clear, even in the body of the code, what is external. The qualifications aren't excessive, but contain information which I would consider important. Well this is my view, but I have found that when the libraries are undergoing active development they can sometimes be refactored and using style (1) means developers that are affected have to edit alot more code. -Andrew Marlow [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gennaro Prota Guest Posted: Fri Aug 25, 2006 8:01 pm    Post subject: Re: namespaces, class libraries, and VERY large projects On 23 Aug 2006 14:23:29 -0400, apm35 (AT) student (DOT) open.ac.uk wrote: Quote: I have a question about the way people choose to partition large C++ projects (millions of LOC, lots of class libraries) using namespaces. What surprised me about your post (and all replies) is that you seem to only consider classes. Are you purposedly avoiding discussion of functions and function templates? Because that's where the real dance begins (or "", choose your smiley here) -- Gennaro Prota [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Fri Aug 25, 2006 8:02 pm    Post subject: Re: namespaces, class libraries, and VERY large projects In article <1156494025.476662.198960 (AT) p79g2000cwp (DOT) googlegroups.com>, kanze <kanze@gabi-soft.fr> writes Quote: There are two problems with this: -- You won't get the name clash immediately. You'll get it considerably down the road, when someone adds a symbol to one of the namespaces. And you'll suddenly find yourself with a lot of code to modify, as a result of what should have been a benign change. OTOH, with namespace directives you can disambiguate when faced with namespace clashes by using fully elaborated names. I think that for large code bodies I would generally opt for fully elaborated names except inside an unnamed namespace where I might consider a using directive. I am less certain when it comes to student code. Certainly I lean towards using short namespace aliases so that code does not spread across an excessive number of lines. -- Francis Glassborow ACCU Author of 'You Can Do It!' and "You Can Program in C++" see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Fri Aug 25, 2006 8:02 pm    Post subject: Re: namespaces, class libraries, and VERY large projects In article <1156504186.905931.305630 (AT) h48g2000cwc (DOT) googlegroups.com>, Earl Purple <earlpurple (AT) gmail (DOT) com> writes Quote: I use fewer namespaces than you then because I do not even give every library its own namespace. Every project has its own namespace, but a project can contain many libraries. Projects are considered separate entities that may share some common code. But IMO, it is exactly libraries where the benefit of namespaces is most evident. I hate libraries that are not encapsulated in a namespace because I cannot easily and safely mix them with other libraries. -- Francis Glassborow ACCU Author of 'You Can Do It!' and "You Can Program in C++" see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alan McKenney Guest Posted: Fri Aug 25, 2006 8:03 pm    Post subject: Re: namespaces, class libraries, and VERY large projects werasm wrote: Quote: Alan McKenney wrote: Quote: Yes, what is your advice or comment on the OP's question (1,2 or 3 - or something not mentioned maybe?). It may be beneficial to him/us to know, since you have such a vast amount of experience. I'm afraid I can't contribute any experience with the use of namespaces to partition projects. Most of my experience has not been with C++. My recent experience has been with C++, but I've not been in a position to make these decisions, I've just had to live with the consequences. Even when I have been in a position to make such decisions, other programmers often do what they feel like, anyway. I've used namespaces in my pieces of projects, but have not been able to get other people to do so. Actually, I've focused more of my energy on things like standard-compliance, const-correctness, extensibility, robustness, configurability, and portability. (I think most programmers tend to do whatever will get their code written, compiled, and out the door quickest.) OK, now that I've finished whining: I would go with explicitly qualified names, with "using" statements for frequently used names. And your "using" statements should be in your .cpp files, not in headers. You want don't want to have to be hunting through a million .h files to find out where a name comes from. Don't use "using namespace" statements. If the likelihood of name collisions is high enough to require namespaces, then you'll have to get rid of them, anyway, and adding qualifiers everywhere in a million lines of code after you've written, debugged, and forgotten them is a *lot* harder than doing it right the first time. (A general rule: do your best to write code you won't have to revisit. The cost of changing one line of code goes up both as time passes and as the amount of code that depends upon it goes up.) I don't even use "using namespace std" or "using std::string" or "using std::cout" statements. It makes it easer to find them with search commands. I don't have a lot of experience with nested namespaces. My experience with nested classes has run into enough annoying restrictions that I would not use nested namespaces on a big project until I had a fair amount of experiences on projects small enough that un-nesting them later on wouldn't be a big problem. -- Alan McKenney [line eater fodder] [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Earl Purple Guest Posted: Fri Aug 25, 2006 11:17 pm    Post subject: Re: namespaces, class libraries, and VERY large projects Quote: In article <1156504186.905931.305630 (AT) h48g2000cwc (DOT) googlegroups.com>, Earl Purple <earlpurple (AT) gmail (DOT) com> writes I use fewer namespaces than you then because I do not even give every library its own namespace. Every project has its own namespace, but a project can contain many libraries. Projects are considered separate entities that may share some common code. Francis Glassborow wrote: Quote: But IMO, it is exactly libraries where the benefit of namespaces is most evident. I hate libraries that are not encapsulated in a namespace because I cannot easily and safely mix them with other libraries. The libraries are encapsulated in a namespace, just that several different libraries that come from the same source could use the same namespace. Good examples here are the standard libraries, where everything is in std. They don't split it into namespaces std::collections, std::streams, std::numerics etc. Similarly boost - I think everything under boost is simply in namespace boost, but detail that the user does not use directly (but does see, even if only as a forward declaration) is declared in namespaces underneath. Using boost as a good standard, I have adopted that approach, on the whole. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Abrahams Guest Posted: Fri Aug 25, 2006 11:19 pm    Post subject: Re: namespaces, class libraries, and VERY large projects "Alan McKenney" <alan_mckenney1 (AT) yahoo (DOT) com> writes: Quote: (I think most programmers tend to do whatever will get their code written, compiled, and out the door quickest.) OK, now that I've finished whining: I would go with explicitly qualified names, with "using" statements for frequently used names. Official terminology: "using-declarations." Quote: And your "using" statements should be in your .cpp files, not in headers. You want don't want to have to be hunting through a million .h files to find out where a name comes from. Don't use "using namespace" statements. Official terminology: "using-directives." Quote: If the likelihood of name collisions is high enough to require namespaces, then you'll have to get rid of them, anyway, and adding qualifiers everywhere in a million lines of code after you've written, debugged, and forgotten them is a *lot* harder than doing it right the first time. I used to be virulently opposed to using-directives, but there are a few places where they really make sense. For example, when composing namespaces: namespace domain2 { using namespace domain1; // additional stuff } They also make sense at function scope (or even namespace scope in a ...cpp file) when trying to make certain kinds of idiomatic code read well: using namespace mpl::placeholders; // for _1, _2, ... _N typedef mpl::fold< seq , mpl::if<boost::is_base_and_derived<_2,_1>, _1, _2> , void Quote: ::type t; (A general rule: do your best to write code you won't have to revisit. The cost of changing one line of code goes up both as time passes and as the amount of code that depends upon it goes up.) I don't even use "using namespace std" or "using std::string" or "using std::cout" statements. It makes it easer to find them with search commands. Me neither, as a rule. Quote: I don't have a lot of experience with nested namespaces. Nested namespaces are great! However, I have a hard time imagining a project that could be structured so that all lookups can be unqualified due to namespace nesting. Normally, you want the outer-level components to be drawing on those in inner namespaces, not the other way around. Projects don't typically form a hierarchy with the highest-level components at the leaves. Nested namespaces can be made more convenient with namespace aliases. How come nobody ever mentions namespace aliases? namespace mpl = boost::mpl; Quote: My experience with nested classes has run into enough annoying restrictions that I would not use nested namespaces on a big project until I had a fair amount of experiences on projects small enough that un-nesting them later on wouldn't be a big problem. See namespace aliases. A further problem with trying to avoid qualification is the unexpected effects of argument dependent lookup, even when calling functions within the same namespace: namespace foo { bar: y; template <class T> int f(T) { ... } int z = f(y); // might not call foo::f! } Qualification is the best way to suppress those. namespace foo { bar: y; template <class T> int f(T) { ... } int z = foo::f(y); } -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top werasm Guest Posted: Fri Aug 25, 2006 11:34 pm    Post subject: Re: namespaces, class libraries, and VERY large projects Alan McKenney wrote: Quote: werasm wrote: Alan McKenney wrote: I'm afraid I can't contribute any experience with the use of namespaces to partition projects. Most of my experience has not been with C++. Accepted. Quote: I've used namespaces in my pieces of projects, but have not been able to get other people to do so. Actually, I've focused more of my energy on things like standard-compliance, const-correctness, extensibility, robustness, configurability, and portability. Agreed. Quote: (I think most programmers tend to do whatever will get their code written, compiled, and out the door quickest.) As long as they follow your principle of attempting to write it to not revisit it later. Quote: OK, now that I've finished whining: I did not experience it as whining :-) Quote: I would go with explicitly qualified names, with "using" statements for frequently used names. Yes, that is what I do. I also sometimes use typedefs - especially if the name is required in the interface. Quote: And your "using" statements should be in your .cpp files, not in headers. You want don't want to have to be hunting through a million .h files to find out where a name comes from. I absolutely agree - I never have using statements in my headers. Typedefs in my classes, OTOH works great. Quote: Don't use "using namespace" statements. If the likelihood of name collisions is high enough to require namespaces, then you'll have to get rid of them, anyway, and adding qualifiers everywhere in a million lines of code after you've written, debugged, and forgotten them is a *lot* harder than doing it right the first time. I have worked on fairly large projects (Million+), and have never found this to be problem if I follow the rule of <never> having using directives or using declarations in my header files. Furthermore using directives in the source (.cpp) file should be below the headers. In general, if I require a name in the interface (.h), I typedef it as part of the class in whose scope it will be used. struct x { typedef some_long_name::y y; } y is now unambigious in the scope of all x's member functions, and needn't be qualified. If its namespace happens to change, the interface would be influenced regardless, and all that needs changing is the qualifier in the typedef. If OTOH the name is not required in the interface, I use using declarations in my .cpp (source) file. For templates though, I have sometimes found typedefs in anonymous namespaces (in the cpp, of course) to work better. Quote: (A general rule: do your best to write code you won't have to revisit. The cost of changing one line of code goes up both as time passes and as the amount of code that depends upon it goes up.) Oh yes. Quote: I don't even use "using namespace std" or "using std::string" or "using std::cout" statements. It makes it easer to find them with search commands. I actually also tend to type std without thinking (its short), even if a using directive does exist in the source file - its not worth the bother, really. If however, the namespace name becomes longer, and is qualified often in a .cpp file, then using namespace very_long_name seems good, and very local if problems do appear later. The only problem that I can foresee is that, if one has more than one "using directive" in a sourcefile, and a class is added to one of those namespaces with a similar name to another class in one of the other namespaces. Also, this new class name then would have to be visible in one of the headers included in the applicable cpp file (A forward declaration in the correct namespace one of the headers would suffice to make it visible). In this case recompilation of the applicable source file is certainly inevitable. Disambiguiting the problem cases would not be much work. Also, this case in my experience is quite rare (I have not had such problems before, in fact). Good libraries usually only make the names of the actual component visible in the header file, except where templates are used. Names only used by the libraries (implementation) tends to get hidden in nested namespaces - never to be used by the client (like boost::detail). This lessens the possibility of ambiguities even more. The question boils down to: Is it more work qualifying each name with a namespace from the outset (in all source files), or is it more work getting the code out of the door, and if these rare cases do happen, fix them by explicit qualification. Using "using-directives" in the ..cpp (source) file can only cause that .cpp file to break. Quote: I don't have a lot of experience with nested namespaces. My experience with nested classes has run into enough annoying restrictions that I would not use nested namespaces on a big project until I had a fair amount of experiences on projects small enough that un-nesting them later on wouldn't be a big problem. I have come to the conclusion that nesting is good for hiding names that you don't want clients to be aware of. I have made use of nesting for other reasons - using nesting to seperate packages (IMHO, a definite don't), or domains - no benefit really (lot more work), rather distinguish by class name. If name clashes exist within the same library, well, then one name would have to change - the one that started existing later. I have contemplated using nesting for versioning (I made provision in my file structure for the possibility). This may seem like a strange idea. But sometimes, when a component (or a group of interrelating classes) starts out, it's interface may be vastly different from where it ends. In this case, if existing clients (or project) already make use of the old interface (this may include an entire range of interrelating classes), this restrics one with respect to name usage, and eventually you have to release an brand new library, not compatible in the least with the previous. If the concept of versioning by nesed namespaces were used, the two groups of classes being similar, but different enough to be seperate, can now live seperately. New clients can use the latest version (always), and old clients can continue using the version that they use. An entire library re-design is not necessary. Names don't need to change for qualification of the later group. Is that not to a certain extent, where the name tr1 came from? I have started using this idea - one's file structure must of course support this. By default I would only perform this type of qualification when absolutely necessary. From the outset I don't use namespaces for versioning. I do structure my directories for the possibility though. LibDir ---> v0 Original source ---> v1 New source, may make use of original source where appropriate. Kind Regards, Werner [ 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, 3  Next Page 1 of 3   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.