Re: hash_map include, how?

[Bernd Strieder]

Paulo Matos wrote:

> 
> Bernd Strieder wrote:
>> hash_map is a deliberate extension provided by libstdc++. The correct
>> way will be #include <hash_map> after C++0x is out. If #include
>> <hash_map> would be used now, but in C++0x substantial changes would
>> have to be done, this would be very annoying. By moving it to ext/
>> both versions could exist for a smooth transition. Compare to the
>> iostream.h to iostream transition on the introduction of namespaces.
>>
>> I think hash_map has been included in TR1 for C++0x, so #include
>> <tr1/hash_map> could have its merits, too. But TR1 is only a
>> temporary story. So code using it would have its disposal time
>> already set.
>>
>> If you use hash_map now, your code will be depending on non-portable
>> non-standard extensions, that might be changing without notice
>> between compiler releases, if you prefer the worst-case to deal with.
>>
> 
> Thanks for the explanation... So, I guess currently, the way to go is
> to:
> #include <ext/hash_map>
> 
> using __gnu_cxx::hash_map;
> 
> on g++ 4.1.1 at least, right?
> 
> Rest assured that with your explanation I got it... my software will
> not be portable... probably not even between different versions. :-)

Portability is always a question of the work to be done. At times
porting feels more like redesign. If headers disappear, then porting
means more or less copying the old header, or using another header
where the content has been moved.

I'm sorry, I was inaccurate. I should have looked another time into tr1.
There is #include <tr1/unordered_map>. This probably means ext/hash_map
will be a GNU extension forever, your chances to write easily portable
(in the future) code are better with tr1/unordered_map, which has high
chances to be moved up after C++0x.

All the code in tr1 uses std::tr1::, so after C++0x porting will
probably be just removing all occurrences of tr1/ and tr1::

Bernd Strieder