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 namespacestd::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 namespacestd::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 namespaceboost:: 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 namespacestd::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.