RE: [boost] portable hash_map

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
cleaner solution.

-----Original Message-----
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
 >compatible.

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
 >troublesome.
 >
 >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
is present.

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.

--Beman

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/