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.