Re: [Boost-users] [bcp] [shared_ptr] [wave] Extracting subset of boostforshared_ptr - 3.2MB?

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-18 13:16:25

David Abrahams <dave_at_[hidden]> writes:

> "John Maddock" <john_at_[hidden]> writes:
>
>>> Unfortunately bcp isn't smart enough to not look into optional
>>> dependencies that are guarded by #ifdef. In this particular case it
>>> follows the dependency to detail/quick_allocator.hpp, which in turn
>>> brings in the type_traits and mpl libraries. But quick_allocator.hpp
>>> is only used if you #define BOOST_SP_USE_QUICK_ALLOCATOR.
>>
>> Peter, this comes up so often, I wonder is it worth while "hiding" that 
>> optional dependency behind a #define, as in:
>>
>> #define BOOST_SP_QA <some-header.hpp>
>>
>> #ifdef BOOST_SP_USE_QUICK_ALLOCATOR
>> #include BOOST_SP_QA
>> #endif
>>
>
> If doing that works to fool bcp, we need a better system.  It would be
> a lot of work, but maybe it would be the first real use of Wave as a
> library rather than just as a preprocessor.  We could use the graph
> library to do a real search with some knowledge of compiler and
> configuration #defines.  It would be a conservative search, so it
> would follow *all* PP #ifdef branches unless it could prove that they
> shouldn't be followed.  Wow, that sounds like an interesting but
> difficult dynamic programming problem.  I wonder if it's even
> tractable?

I like Peter's idea much better in the near term ;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com