Wayne, There might still be conflicts if the compiler can't place everything into it's proper namespace. In addition, some sdk's force everything into std namespace or into the global namespace. If you use "using namespace boost;", you're basically doing the same thing. There are a couple of options that could be used separately. 1. One is to not use "using namespace". Preface everything used from there with boost:: or std::. More typing, less pain, less chance for conflict. 2. The second is wrap the offending sdk in it's own namespace. Here is what I have come up with. I have three files here. c.h is the original function. b.h wraps it in it's own namespace, and main.cpp can only use it with the new namespace. Simple example, but hopefully it illustrates what I'm trying to get across. -------------------------------------------------- c.h ------------------------------------------------- #ifndef _C_H #define _C_H inline int garbage_method() { return 0; } #endif // -------------------------------------------------- b.h -------------------------------------------------- #ifndef _B_H #define _B_H namespace garbage_namespace { #include "c.h" } #endif // -------------------------------------------------- main.cpp -------------------------------------------------- #include "b.h" int main() { return garbage_namespace::garbage_method(); } -----Original Message----- From: Dernoncourt, Wayne CTR NAVAIR 3184, ,10 [mailto:wayne.dernoncourt@navy.mil] Sent: Friday, February 06, 2004 5:43 AM To: Boost Users mailing list Subject: RE: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C: Well that worked much better as far as it went (747 updated files out of 747 targets wth no skipped files and no failures). The version of the bjam binary was a little larger (~5k) than the one I compiled<scratches head>, but using this produced no errors. Unfortunately we still have at least a few problems. As I described originally we are using a highly specialized third party SDK. Part of this SDK redefines reverse_iterator (as well as min & max) evidently the MS Visual C++ reverse iterator is broken in some way. From a cursory examination of the two implementations, it appears that both the two are very similiar in functionality if not implementation. The issue with min/max could be eliminated by commenting out line 59 of boost/config/stllib/dinkumware.hpp (line defines BOOST_NO_STD_MIN_MAX). There doesn't appear to be a similiar line for the reverse iterator. One of the issues appears to be that this third party SDK doesn't seem to use namespaces for the SDK. From my limited understanding, for namespaces to be used effectively, the different libraries/SDK's would need to be in their own namespaces. If Boost had theirs and the third party used the global namespaces, there could still be conflicts. Is my understanding correct?