Is it worth using std::tr1 in production?

Question

I'm using MS VC 2008 and for some projects Intel C++ compiler 11.0. Is it worth using tr1 features in production? Will they stay in new standard?

For example, now I use stdext::hash_map. TR1 defines std::tr1::unordered_map. But in MS implementation unordered_map is just theirs stdext::hash_map, templatized in another way.

Longlongan

Answer 1

My advice would be to use an alias for the namespace containing the TR1 items you use. This way, you'll be able to "move" from using the TR1 version to the standard version when your compiler supports it.

namespace cpp0x = std::tr1;

cpp0x::unordered_map<std::string, int> mymap;

for a C++0x compiler, the first line becomes:

namespace cpp0x = std;

and you can leave the rest alone.

Kyla

Answer 2

Yes, everything that's in tr1 will stay there. Some things will be accepted in std::, but they will stay in tr1 also. So none of your code will break once the new standard is finished.

Forgive me: no, they will not. As described here:

Two notes have been added to the proposal to make it clear to users that in the transition from the TR to future standards, the TR components will not remain in namespace std::tr1 and the configuration macros will disappear.

But it's worth noting that compiler vendors willing to support tr1 now, will most probably not pull the earth from under your feet, and provide you with some sort of transition method.

Waaf

Answer 3

unordered_map will be in the new standard, hash_map won't be. Note that the tr1 namespace is not standard either.

Ubiquitous

I didn't know std::tr1 wasn't standard. I don't have the final tr1 standard, but the draft I'm looking at (PDF link) says, "Since the extensions described in this technical report are not part of the C++ standard library, they should not be declared directly within namespace std. Unless otherwise specifed, all components described in this technical report are declared in namespace std::tr1.". open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf – Aloe

@Aloe TR1 is not normative for C++. – Ubiquitous

Answer 4

The vast majority of library code that will be added in C++0x has been around for quite a while in the Boost C++ Libraries. I would strongly recommend using Boost (i.e. boost::unordered_map), since it works on a very large number of ISO C++ 1998 compilers, and will continue to work (probably using the compiler's builtin implementation) on C++0x compilers. In addition, you won't need to change the namespace -- whereas items in std::tr1 that are approved will be moved into std -- since it will always be available in boost::, and you won't have to worry about which elements of tr1 have made it into the standard. In short, Boost is the way to go.

Goodall

I wouldn't totally agree with that. You have the portability advantage if you use the boost implementation, but you lose out on platform-specific optimisations and things like IDE support (for instance, the excellent support for shared_ptr<> in the Visual Studio debugger). – Godchild

@the_mandrill, I'm pretty sure Boost will use the underlying standard implementation if it is available... do you have any benchmarks indicating that the boost version is slower where the standard version is available? If so, on what platform and with what version of Boost? – Goodall

I don't know of any benchmarks, but I remember comparing the boost version of shared_ptr with the one in VS.Net and the boost one appeared much more heavyweight, as it pulls in many more files and has to workaround quirks in a number of compilers. The VS.Net one meanwhile is free to be optimised towards the local compiler. I haven't ever seen the boost implementations use the local versions. – Godchild

Answer 5

For the tr1::unordered_map be aware that there are many various implementations of Hash Maps possible and that the implementation elected by the standard is quite classic... but may not be the most performing for your particular task.

Unfortunately the standard did not require that multiple strategies be implemented (though I suppose it would have required quite a lot of work).

Mantoman

I'm not clear on what you mean by the implementation elected by the Standard. The Standard prescribes O() behavior, not implementations. Is there a different set of O() behavior you'd want in associative containers? – Pulmonate

O() is not always meaningful. For example, in term of rehashing. All hashmaps have amortized constant insertion, yet if you do not have dynamic rehashing, some insertions will be very slow (like when you trigger a realloc on a std::vector::push_back). O(1) gives some leeway here and if you need to perform frequent insertions on a time critical process, it's not enough. – Mantoman