[test] Broken header (via indirect #includes)
I was fixing up a test file, and the compilation failed complaining that "'type' is not a member of 'boost'" within the innards of a "BOOST_AUTO_TEST_CASE_TEMPLATE" line. I figured out that the error was referring to the obscure boost::type class template in "boost/ type.hpp". I included that file, and then the compiler complained saying that "'template_test_case_gen' is not a member of 'boost::unit_test::ut_detail'." Doing a multiple-file search, I realized the true problem. 1. BOOST_AUTO_TEST_CASE_TEMPLATE is #defined in "boost/test/ unit_test_suite.hpp" 2. This template depends on boost::type and boost::unit_test::ut_detail::template_test_case_gen 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 "unit_test_suite.hpp" 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 [5] 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 from my test file. (Apologies in advance if the real problem is that my subversion working copy is severely fried.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
on Sun Jul 13 2008, Daryle Walker <darylew-AT-hotmail.com> wrote:
1. BOOST_AUTO_TEST_CASE_TEMPLATE is #defined in "boost/test/ unit_test_suite.hpp" 2. This template depends on boost::type and boost::unit_test::ut_detail::template_test_case_gen 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 "unit_test_suite.hpp" 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 [5] 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 from my test file.
(Apologies in advance if the real problem is that my subversion working copy is severely fried.)
Daryle, 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 fixed, that'd be a bonus. Thanks again, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
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/ unit_test_suite.hpp" 2. This template depends on boost::type and boost::unit_test::ut_detail::template_test_case_gen 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 "unit_test_suite.hpp" 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 [5] 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 from my test file.
(Apologies in advance if the real problem is that my subversion working copy is severely fried.)
Daryle,
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 fixed, 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 bug itself.... -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
on Mon Jul 14 2008, Daryle Walker <darylew-AT-hotmail.com> wrote:
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 fixed, 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 bug itself....
Then open a ticket about that :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Daryle Walker <darylew <at> hotmail.com> writes:
I worked around the problem for now by directly #including "boost/test/test_case_template.hpp" in my test file.
This was always the case as with FP comparison.
But I shouldn't have to do this.
Original intension was to avoid adding dependencies if you don't need them. I guess it causing more problems then help. I'll add both to the appropriate header. Gennadiy
participants (3)
-
Daryle Walker -
David Abrahams -
Gennadiy Rozental