Namespace

Are you using using namepsace foo? Is it an option to instead do foo::bar()?

[Edited by - _Sigma on April 10, 2007 3:17:49 PM]

Let's see if I got it right: you have a code base base that is wrapped on a namespace X, and one that isn't, but they are conflicting? I don't really think they should conflict...

Can you clarify?

I wouldn't think they would conflict either, but we are talking about more than 1 million lines of code in the one code base.

namespace FOO
{
template class Vector
{
......
};
......
};

template class Vector;
{

}

\vector.h(261) : error C2872: 'Vector' : ambiguous symbol
could be '\vector.h(58) : Vector'
or 'foo\foovector.h(63) : FOO::Vector'

You see the issue is the vector and a million other things conflict with one another.

I believe that FOO::vector have FOO scope and vector have global scope, so there would be no conflict, unlest you did something like "using namespace foo;" and included both headers.

Are there includes to the global vector class inside the FOO namespace? Then you have a big problem on your hand.

I'm sorry about all these questions but I can't make any tests here because my VS2005 is missing C++ and I forgot my notebook.

Are the vectors the same or not?

No there not the same so I've began wrapping everything in a new namespace.

The problem is one code base includes files with using namespace foo; so that carries through causing major problems.

Any other ideas, thanks for the help so far.

I hit this problem about 6 years ago and learned a hard hard lesson.

1. You absolutely cannot / should not have any "using" statements in header files. exactly for the reason you state. It is fine in source files that are not meant to be included in other files, but if the file it meant to be #included elsewhere, usings are a bad bad thing.

Unfortunately for you, fixing this would require A), removing the using lines in headers, B) qualifying all references in those same headers, and C) adding usings to any non-headers which depended on the original usings instead of adding using lines themselves.

You could perhaps try wrapping all the offending code in *another* namespace, and treating that namespace properly when it's used by the non-offending side? :s

Quote:

Original post by Zahlman You could perhaps try wrapping all the offending code in *another* namespace, and treating that namespace properly when it's used by the non-offending side? :s

That's my main suggestion. It's the right way to do it.

And what Xai said is right. You should never have "global" using in headers. But hey, I only learned that after going through a problem like yours... :(

yeah, the wrapping non-namespace code into a namespace is the best answer I know, but of course only works if that code never has global usings in its headers :).

Quote:

Original post by adam23 ... The problem is it would take days to fix this by wrapping all of the one very large code base in its own namespace.

Quote:

Original post by adam23 ... but we are talking about more than 1 million lines of code in the one code base

Considering that we are talking about more than a million lines of code, I don't think that taking several days to move it into a namespace is excessive. Any kind of structural change on a code base of that size will take days, if not weeks. If you try to take shortcuts or do some clever hack, you may introduce the risk of bigger problems later.

Quote:

Original post by Xai yeah, the wrapping non-namespace code into a namespace is the best answer I know, but of course only works if that code never has global usings in its headers :).

// foo_wrapper.h#ifndef FOO_WRAPPER_H#define FOO_WRAPPER_Hnamespace wrapper_for_bad_code {  #include "foo.h"}#endif// foo_wrapper.cppnamespace wrapper_for_bad_code {  #include "foo.cpp"}// and REPLACE foo.cpp with foo_wrapper.cpp in the build process

? (You could even make a script to generate all the wrappers.)

Thank you guys for all the help.

Zahlman thats an awesome idea, its really ashame I didn't get back here sooner. I just spent 3 days this week refactoring all the code so there were no global using namespace calls in any of the header files. At one point Visual Studio told me I had 47,000+ errors, but it slowly got better and I finally got everything working.

Next time I'll know what to do, its funny none of the programmers I work with thought of that. Pure genius thanks!!!

Adam