From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-15 15:30:57
----- Original Message -----
> 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
> 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.
I agree with Jeremy that what we've done so far is OK.
> Perhaps an alternative solution would be to create a boost::slist and
I also think that this solution is "More OK", since after all, any library's
interface of these non-standard elements may differ in arbitrary ways. One
thing we could do, for example, is to "simply" hijack these classes from
STLport. Even that solution is likely to amount to lots of work, and will
have some undesirable side-effects (e.g., some users will wish we were using
their library's built-in component). I'm not sure it's worth it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk