Arkadiy Vertleyb wrote:
The Spirit typeof tests seem to just include the registration files. Is more comprehensive testing being planned?
<cite -- email correspondence on testing typeof registration> Joel de Guzman wrote:
Tobias Schwinger wrote:
Joel de Guzman wrote:
Tobias Schwinger wrote:
Is there a way to tweak the existing test suite to apply Typeof to the types involved?
Hmmm...I'm not sure if that's a good idea --but I'm not sure. I'm afraid of entanglement. Wouldn't it be better to have separate tests?
I just added simple separate tests that just include Spirit plus typeof
cool!
headers to ensure none of the forward declarations (those in the typeof.hpp files which are not tied to the component header) have been broken. These tests also catch typos in the registration. If we want to find forgotten registrations, however, the tests must cover all there is in Spirit -- but we can also wait for someone to complain, I figure (and -on second thought- I think I like it).
I think this is the right way to go. I'm not quite fond of the carpet bombing approach to testing anyway. If we add typeof tests to all the tests, then that would amount to 2X testing time (more considering the compile time of Boost.Typeof is relatively not insignificant). A more focused set of tests is my preference. In fact, when we have Spirit-2, I'd re-focus those tests we already have there. It's already taking up too much testing resources as it was.
</cite> The infrastructure beyond registration (to actually utilizy typeof support for building grammars) boost/spirit/utility/rule_parser.hpp libs/spirit/example/techniques/no_rules_with_typeof/* is still in experimental state; there is no documentation except a preliminary manual in the header, there are no tests except the examples and right now even these few require a *very* decent compiler to work (GCC 3.4 emulated/native Typeof and VC8 with some issues left work. VC7.1 seems to randomly ICE inside Typeof in some -sometimes surprisingly simple- cases, so if you're looking for a new challenge, please go ahead ;-) ). Regards, Tobias