 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Jacek Generowicz
Guest
|
 Posted: Thu Aug 28, 2003 8:09 pm Post subject: Pre-standardizing hash_map & friends. |
 |
|
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,
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Ben Hutchings
Guest
|
| Posted: Sat Aug 30, 2003 10:52 am Post subject: Re: Pre-standardizing hash_map & friends. |
|
|
In article <tyfoeya2lao.fsf (AT) pcepsft001 (DOT) cern.ch>, Jacek Generowicz wrote:
| Quote: | 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.
snip
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.
|
VC++ uses the Dinkumware library.
There's also STLPort, but that's based on SGI STL. Apparently Borland
is now distributing that.
| Quote: | 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.
|
So long as you don't want to customise the hash function or
relations, there's no problem.
However, if you do you'll find that they use quite different template
parameters, and SGI's hash containers require an equivalence relation
whereas Dinkumware's require an ordering relation (I don't know about
Metrowerks). It may be possible to write a wrapper that hides these
differences, but it would require both relations to be specified, and
in the absence of typedef templates it would result in odd-looking
type names.
| Quote: | - Provide the SGI implementation for everyone's use. (In what
namespace?)
|
Definitely not std!
| Quote: | 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.
|
The interface has been accepted for the Library Technical Report,
though that isn't actually a standard.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Early Ehlinger
Guest
|
| Posted: Wed Sep 03, 2003 12:46 am Post subject: Re: Pre-standardizing hash_map & friends. |
|
|
"Jacek Generowicz" <jacek.generowicz (AT) cern (DOT) ch> wrote:
| Quote: | 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.
|
No - they are either identical or different. If they are different, they
are not similar enough and the differences will become yet another sore
point in an environment where you're supporting enough differences
(gcc,msvc,icc - all in multiple versions, too!) as it is.
I would run, nay, I would sprint from this option as quickly as possible.
| Quote: | - Provide the SGI implementation for everyone's use. (In what
namespace?)
|
I'm not sure I would go with the SGI implementation (I'm not familiar enough
with it or the alternatives), but this would be much simpler to support; now
you would only need to work on making sure that the standard extensions work
identically on the various compilers you intend to support.
--
-- Early Ehlinger CEO, ResPower Inc - Toll-Free : 866-737-7697
-- www.respower.com -- 500+ GHz Supercomputer Starting At USD$0.50/GHz*Hour
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Jacek Generowicz
Guest
|
| Posted: Wed Sep 03, 2003 3:06 pm Post subject: Re: Pre-standardizing hash_map & friends. |
|
|
"Early Ehlinger" <early (AT) respower (DOT) com> writes:
| Quote: | "Jacek Generowicz" <jacek.generowicz (AT) cern (DOT) ch> wrote:
- Use native extensions; they are all similar or similar enough.
I would run, nay, I would sprint from this option as quickly as possible.
|
My feelings are similar, but there is some pressure on me to follow
this route, maybe with some facade to make them look similar from the
outside.
"Worse is better"
| Quote: | - Provide the SGI implementation for everyone's use. (In what
namespace?)
I'm not sure I would go with the SGI implementation (I'm not familiar enough
with it or the alternatives),
|
We are obliged to write open software, and it seems that SGI is the
best candidate from that POV, but I'll have to check this properly.
| Quote: | but this would be much simpler to support; now you would only need
to work on making sure that the standard extensions work identically
on the various compilers you intend to support.
|
Indeed.
To what extent are the extensions coupled to the rest of the template
library ? Is it likely that we would end up having to provide the
whole of the chosen library, or would it be possible to take the
extension and nothing else, continuing to use the native
implementation for the parts which are already in the standard ?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
