From: Daryle Walker (darylew_at_[hidden])
Date: 2008-07-14 13:28:54
On Jul 14, 2008, at 7:48 AM, David Abrahams wrote:
> on Sun Jul 13 2008, Daryle Walker <darylew-AT-hotmail.com> wrote:
>> 1. BOOST_AUTO_TEST_CASE_TEMPLATE is #defined in "boost/test/
>> 2. This template depends on boost::type and
>> 3. template_test_case_gen is defined in "boost/test/
>> test_case_template.hpp", which happens to #include "boost/type.hpp"
>> 4. Neither of the appropriate headers are directly #included in
>> 5. I guess that one or both headers were indirectly #included in
>> "unit_test_suite.hpp", but that indirect header purged the headers I
>> needed, and the author _forgot_ that another header was counting on
>> the old indirect #include.
>> I worked around the problem for now by directly #including "boost/
>> test/test_case_template.hpp" in my test file.
>> But I shouldn't have to do this.
>> Worse, this has happened before with Boost.Test, in regards to the
>> floating point comparison tests. Those test macros called a function
>> that wasn't in the same header, nor #included; i.e. the user has to
>> add an extra #include for the floating-point test macros to work.
>> The floating-point incident was a deliberate design decision, but I
>> guess that my problem here was caused by accident.
>> The point: DIRECTLY #include everything a macro needs in that macro's
>> header. I'm sick & tired of hunting all the extra headers I need.
>> Worse, I'll have to re-hunt when my test program craps out if/when
>> the author re-arranges all the macros & headers.
>> My point  is only a guess because I wasted two hours searching the
>> trac/subversion site for where & when the author broke the build. I
>> didn't find it, and I figured that I shouldn't have to.
>> When you fix this, let me know so I can remove the extra #include
>> my test file.
>> (Apologies in advance if the real problem is that my subversion
>> working copy is severely fried.)
> Thanks for diagnosing this. Please put a ticket about this at
> http://svn.boost.org. If you could check the boost trunk (using the
> Trac browser it should be easy) first to make sure that it's not
> that'd be a bonus.
When you suggested to check the trunk, I wondered how could I check
if I couldn't find the code before. Then that and the floating point
comparison policy reminded me to check how I handled this for the
Boost.Rational tests. When I checked, I handled the problem the same
way. I guess this isn't a bug; I forgot that this is a design
decision, just like the floating point comparison case. Sorry.
Of course, one could strongly argue that this design decision is a
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk