J
Jacek Generowicz
Within our family of projects, we are looking to provide a recommended
practice guideline, concerning hashed containers, which would help
developers using different compilers, to write portable code.
We are primarily interested in
gcc 3.2
MSVC++ 6/7.0/7.1 (?)
icc
gcc 2.95
in approximately descending order of importance.
IIUC ...
- there are three widely used STL implementations which inculde
hashed containers as extensions: Dinkumware, Metrowerks and
SGI. All three agree on the names hash_set, hash_map, hash_multiset
and hash_multimap, and provide very similar interfaces.
- gcc provides hashed containers in an extension, based on the SGI
implementation.
- MSVC++ also provides an extension (in earlier versions this was
based on the HP (now SGI) implementation). Recently it moved from
the std namespace to stdext.
Firstly, I'd welcome any factual corrections to the above.
Secondly, I would like to ask for suggestions as to what standard
practice would be sensible to adopt.
For example:
- Use native extensions; they are all similar or similar enough.
- Provide the SGI implementation for everyone's use. (In what
namespace?)
Tempting though it might be to anticipate the interface proposed to
the standards committee (unordered_* replacing hash_*), such a
suggestion will be rejected on the grounds that it will break too much
code today, for a (not entirely certain) payback too far in the
future.
Thanks,
practice guideline, concerning hashed containers, which would help
developers using different compilers, to write portable code.
We are primarily interested in
gcc 3.2
MSVC++ 6/7.0/7.1 (?)
icc
gcc 2.95
in approximately descending order of importance.
IIUC ...
- there are three widely used STL implementations which inculde
hashed containers as extensions: Dinkumware, Metrowerks and
SGI. All three agree on the names hash_set, hash_map, hash_multiset
and hash_multimap, and provide very similar interfaces.
- gcc provides hashed containers in an extension, based on the SGI
implementation.
- MSVC++ also provides an extension (in earlier versions this was
based on the HP (now SGI) implementation). Recently it moved from
the std namespace to stdext.
Firstly, I'd welcome any factual corrections to the above.
Secondly, I would like to ask for suggestions as to what standard
practice would be sensible to adopt.
For example:
- Use native extensions; they are all similar or similar enough.
- Provide the SGI implementation for everyone's use. (In what
namespace?)
Tempting though it might be to anticipate the interface proposed to
the standards committee (unordered_* replacing hash_*), such a
suggestion will be rejected on the grounds that it will break too much
code today, for a (not entirely certain) payback too far in the
future.
Thanks,