Subject: Re: [boost] Unittest capability for meta-programs feedback request
From: Christopher Jefferson (chris_at_[hidden])
Date: 2011-09-28 03:47:30
On 28 Sep 2011, at 04:42, Ben Robinson wrote:
> On Tue, Sep 27, 2011 at 11:09 AM, Dave Abrahams <dave_at_[hidden]> wrote:
>> on Tue Sep 27 2011, Gennadiy Rozental <rogeeff-AT-gmail.com> wrote:
>>> Dave Abrahams <dave <at> boostpro.com> writes:
>>> Now if you can come up with another approach to test these
>>> expectations I'd be happy to listen.
>> We already have an approach; it requires integration with the test
>> system. Yes, it's imperfect, but it does do the kind of testing needed
>> to see that MyComponent<int> is prohibited.
>> Can you elaborate on this in greater detail? Currently, if I want to prove
> a static assertion fails, my admittedly cumbersome technique is to uncomment
> the test for that condition, compile to produce the error, then re-comment
> out the test. This becomes very tedious for large numbers of regression
Because we have quite a lot of these kinds of tests, we have added to our private tester code the following:
If you use wrap code in:
#ifdef DM_FAILING_CODE_UNIQUEID (where you can change UNIQUEID to different values)
(which we find by grepping. The ifndef is to make it more likely we'll notice a mis-spelling of the macro)
Then the tester does:
'compiling file.cc should pass, compiling with each of the DM_FAILING_CODE_UNIQUEIDs turned on should fail.
This makes it possible to write tests like:
std::pair<int, int> p;
std::pair<void*, void*> q;
p = q;
p == q;
I don't know if such a thing would be interesting to boost. It would seem much simpler, while still allowing one to write compact compile-time tests, rather than needing many, many files.
The only problem we have had is that it is easy to miss a mis-spelt DM_FAILING_CODE, so we are thinking about changing to #ifndef instead, to make them more likely to be caught :)
> Thank you,
> Ben Robinson, Ph.D.
>> Dave Abrahams
>> BoostPro Computing
>> Unsubscribe & other changes:
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk