incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: num_get thread safety tests
Date Fri, 03 Aug 2007 18:45:21 GMT
Martin Sebor wrote:
> [redirected to stdcxx-dev from a private thread]
> 
> Travis Vitek wrote:
>> As mentioned, I'm already started on the locale tests. I'm actually
>> thinking it might make more sense to have the new test
>> [22.locale.num.get.mt.cpp] verify the correctness of the output as well
>> as the mt safety of the get operations. The existing
>> 22.locale.num.put.mt.cpp test could remain as-is, or maybe I should just
>> roll both the get and put tests into one?
> 
> I suppose that would be okay just so long as it's possible to still
> exercise one facet without the other. Which I suspect might defeat
> your goal of integrating the testing of both facets into the same
> program.
> 
> The problem with creating a dependency between the two facets is
> that a bug in one might prevent the other from ever being tested
> or might cause false positives in the other, making debugging the
> problem more difficult. At the same time, exercising both of the
> facets simultaneously would be valuable in its own right so it
> would be nice to be able to do both.
> 
> An idea that would let us have it both ways is to integrate the
> tests for both (all three when you count numpunct) facets into
> the same program, still keeping the option of running them
> independently of one another, exercising them all at the same
> time by default and, when one fails, invoking the program again
> and exercising them independently, one after another. This
> approach would involve at least two processes: one to drive and
> monitor the tests, and another one or more running the tests
> themselves. The infrastructure for this approach has already been
> put in place: see the rw_process_create() API in the test driver.
> Unfortunately, the tests for the API have been failing on a number
> of platforms so there are issues with it that remain to be resolved.
> 
>>
>> So here is a quick one for you. The locale facets are all templatized on
>> the iterator type. For simplicity I'm thinking that I should just
>> instantiate the facets using character pointers instead of the default
>> [i,o]streambuf_iterator template. This will avoid testing the stream buf
>> iterators in each of the facet tests. Do you have any issues with that?
> 
> This approach makes the assumption that the implementations of
> the facet specializations for charT* are the same as those for
> the streambuf_iterators. This happens to be a safe assumption
> to make at the moment but it might change in the future. The
> other "issue" with this approach is that the specializations
> that are used in the vast majority of cases are those on
> the streambuf iterators and not those on pointers.
> 
> So I would suggest to roll your own very simple iterator derived
> from streambuf_iterator

I meant streambuf here, not iterator of course.

Martin

> that operates on a plain character buffer.
> There should be examples of how to do this in the test suite,
> including the test driver itself (see the header rw_streambuf.h).
> 
> Martin


Mime
View raw message