My prediction is that it will be four to six years before all the compilers boost users care about ship with the full tr1 in the box.
Wow, I sure hope you're wrong. That's an awful long time considering that they have open implementations to use as a starting point.
Maybe, the impression I'm getting is that commercial TR1 implementations will be available soon, but that they won't ship with compilers until they become part of the official standard. I guess time will tell.
So during that time period it will be a real service to users if we provide major portions of the TR.
Agreed.
John's approach looks like a good way to do that, although so far I've only read the docs but not actually tried it in practice.
One thing I just realized that isn't covered in John's docs is how libraries that depend on the tr1 libs need to cope with this change. I'm thinking of libs that depend on shared_ptr (serialization, date-time in 1.33) or function (signals, thread), etc. Seems like these will need to be modified follow the user configuration of the appropriate headers -- at least where for interfaces. It might be ok if the dependency is an implementation detail, but probably would be best if all could be switched over.
Well they have two choices: 1) Do nothing, and carry on using the Boost versions. 2) Use the TR1 forwarding headers, and switch to the std::tr1 versions. Probably (1) is a safer bet until we see what kind of quality we get from early TR1 implementations. John.