Re: [boost] Unittest capability for meta-programs feedback request

Subject: Re: [boost] Unittest capability for meta-programs feedback request
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-09-28 07:08:52

Le 28/09/11 09:47, Christopher Jefferson a écrit :
> 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
>> tests.
> 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)
> #endif
>
> (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.
Hi,

this doesn't solves the issue as even if you have less files you will 
have as many tests.
>
> 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.
>
Boost author are free to organize theirs test using this technique but I 
don't think it is more convenient to analyze when a failure occurs.

Best,
Vicente