When Boost.TR1 is configured to make use of your standard library's native TR1 implementation, then it doesn't do very much: it just includes the appropriate header.

When Boost.TR1 is using the Boost implementation of a particular component, then it includes the appropriate Boost header(s) and imports the necessary declarations in namespace std::tr1 with using declarations. Note that only those declarations that are part of the standard are imported: the implementation is deliberately quite strict about not including any Boost-specific extensions in namespace std::tr1, in order to catch any portability errors in user code. If you really need to use Boost-specific extensions then you should include the Boost headers directly and use the declarations in namespace boost:: instead. Note that this style of implementation is not completely standards-conforming, in particular it is not possible to add user-defined template specializations of TR1 components into namespace std::tr1. There are also one or two Boost libraries that are not yet fully standards conforming, any such non-conformities are documented in the TR1 by subject section. Hopefully, occurrences of non-standard behavior should be extremely rare in practice however.

If you use the standard conforming header includes (in boost/tr1/tr1) then these header names can sometimes conflict with existing standard library headers (for example shared_ptr is added to the existing standard library header <memory> rather than it's own header). These headers forward on to your existing standard library header in one of two ways: for gcc it uses #include_next, and for other compilers it uses the macro BOOST_TR1_STD_HEADER(header) (defined in boost/tr1/detail/config.hpp) which evaluates to #include <../include/header>. This should work "straight out the box" for most compilers, but does mean that these headers should never be placed inside a directory called "include" that is already in your compiler's search path.