[boost] Re: boost and CW6 Mac problems

From: jsiek_at_[hidden]
Date: 2000-10-15 12:22:22

The graph library optionally uses slist and hash_set. Having this
option is important, since slist uses less space than list, and
hash_set is nice performance characteristics for some situations.

Now, because we don't have a way to do standard conforming forward
declarations for these containers, the only way for the graph library
to place the proper "hooks" in is to do a #include of <slist> and
<hash_set>. Now, I obviously don't want to do a #include if those
headers don't exist, hence the need for the BOOST_NO_SLIST and
BOOST_NO_HASH.

I don't agree that the solution is to just remove the usage of slist
and hash_set from the graph library. I see nothing wrong with having
the BOOST_NO_SLIST and BOOST_NO_HASH defines. I see no reason why we
should not take advantage of them if they happen to be there.

Perhaps an alternative solution would be to create a boost::slist and
boost::hash_set?

Cheers,

Jeremy

Daryle Walker writes:
 > >> 
 > >> #define BOOST_NO_SLIST
 > >> #define BOOST_NO_HASH
 > >> 
 > > I am wondering the value of these #defines.  The standard doesn't include
 > > slist and hash classes.  The original SGI implementation does but there
 > > shouldn't be a standard conforming library that provides them in namespace
 > > std.
 > 
 > I agree.  These #defines can punish standardized headers for ones that may
 > be slightly off (by actually having <slist> and <hash>).  They can be
 > removed.  Any headers referencing these headers, or have classes or
 > templates using stuff from these headers, could have the problematic stuff
 > removed.