TR1 is "Technical Report 1" that was approved by the standards committee as semi-official additions to augment the standard library. So a bunch of things were approved that are a part of TR1 that library implementors can implement and distribute to users or with compilers. TR1 defines a common interface much like the regular standard does, so that users can write code to the TR1 interface and expect it to work even when they switch to different implementations of TR1. Note that TR1 is not the next version of the standard, as cpjust mentioned. It is just a group of approved libraries to hold people over until the next standard is official.

Boost is a group of libraries created and approved by the Boost organization. Boost is not directly affiliated with the standards committee. Libraries in Boost are generally only implemented in Boost, not in other vendor's libraries.

The relationship between them is that many of the interfaces from the Boost library were used TR1. The reason is that Boost is widely used and tested in actual code, and interfaces that have already been implemented and are already being used are generally better to be standardized than new interfaces.

So some things, like shared_ptr, were implemented in Boost, then included in TR1 as well. So if you want to use shared_ptr, you can use shared_ptr from Boost, or you can use shared_ptr from any other implementation of TR1.

In addition, there are other parts of TR1 that aren't in Boost (at least I think so, Boost may have finished a complete implementation of the TR1 libraries). There are many libraries in Boost that are not in TR1.

In the end, if something is part of TR1, then using it is a good idea, since TR1 is almost standard. If you can't find what you need in TR1, then try Boost because even if it doesn't become standard, Boost is highly respected and widely used.

The reason you see Boost::TR1 is because as I sort of mentioned, Boost has an implementation of TR1. If you want to use TR1, you can use Boost's version. You can also use the one from Dinkumware, and if any other library vendors implement it you can use those as well.

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

When (if) they ever do finally release the new C++ standard, where are all those TR1 libraries going to be? Will they keep them in a TR1 namespace forever, or will they be moved to std:: or something other than TR1?

I've seen experts give advice on how to use std::tr1 so that code will require minimal changes when those libraries are added to std. Something about making a namespace alias. However, even when they put them in std I would imagine that they would remain in std::tr1 as well but deprecated.

Of course, this all assumes that the libraries make it into the standard without any changes, which is not a guarantee.

However, even when they put them in std I would imagine that they would remain in std::tr1 as well but deprecated.

I strongly doubt that. Deprecation is used to flag features that are in an existing standard for removal from a future version of that standard. std::tr1 is not in any ratified standard, so there is no need to deprecate it.

I'd be more inclined to bet on a situation like the <iostream.h> header. That header only ever existed in draft standards, but the standard (as ratified) only has reference to <iostream>. Several compilers (or, more accurately their libraries) support <iostream.h> for historical reasons (such as avoiding breaking code that dates from the time of those draft standards, and was supported by compilers at the time). However, <iostream.h>, as far as the ratified standard is concerned, is never mentioned and has never existed.

They had std from the start. There has been only one standard. Before the language was standardized there was no std namespace. Libraries that supported both standard and pre-standard C++ provided both options, but they were in different headers.