From: Neal Fachan (neal_at_[hidden])
Date: 2001-03-02 16:48:16
They differ enough in template arguments and the types of function objects
to be significant. We could get around it with #ifdefs, but I would like a
From: Beman Dawes [mailto:bdawes_at_[hidden]]
Sent: Friday, March 02, 2001 1:28 PM
To: boost_at_[hidden]; boost_at_[hidden]
Subject: Re: [boost] portable hash_map
At 12:56 PM 3/2/2001 -0800, Neal Fachan wrote:
>We noticed you don't include a hash_map template in the
>Boost libraries. We assume this is because every STL
>implementation we can find includes their own hash_map.
No one has submitted one. In fact, I know of one implementor who is
thinking of submitting one to Boost so we may have one someday.
>Unfortunately, none of these hash_map implementations are
That's true, although for many practical purposes they are often close
enough to be used interchangeably.
>We have portable software which uses the native vendor STL
>on all platforms, so this makes using vendors' hash_maps
>What would you advise us to do? We are leaning towards
>taking SGI STL (STLPort)'s hash_map, but putting it into
>it's own quarantined namespace.
What some of the Boost code does is fall back on std::map if not hash_map
Another thing you might want to do is measure the speed difference between
a hash_map and a std::map in your application. In many applications the
speed difference will not be enough to worry about, or even
detect. Remember, too, hash_map performance may degrade badly on some
platforms. A std::map may be a considerably safer bet.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk