Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: num_get thread safety tests (was: Re: next steps)
Date: Fri, 3 Aug 2007 16:30:57 -0600
Message-ID: 
 <C8506D6098A6F545BA3745D0CE359E83017570E3@qxvcexch01.ad.quovadx.com>
In-Reply-To: <46B36EB6.9040308@roguewave.com>
Thread-Topic: num_get thread safety tests (was: Re: next steps)
Thread-Index: AcfV+SVS9ZEiboCyRCOBUXW+9dpYGAAHG6NA
References: <46B34AC8.3060504@roguewave.com>
 <C8506D6098A6F545BA3745D0CE359E8301757037@qxvcexch01.ad.quovadx.com>
 <46B36EB6.9040308@roguewave.com>
From: "Travis Vitek" <tvitek@quovadx.com>
To: <stdcxx-dev@incubator.apache.org>

=20

>Martin Sebor wrote:
>
>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.

Okay, I think I'm going to settle for having separate tests for the get
and put. I believe this is what you had originally intended, and I hope
that is still acceptable.

>
>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.

That is more trouble than I'm wanting to chew on at this time. This
seems rather complicated, and since I'm not yet familiar with how the
testing infrastructure works, I'm worried that I would end up spending
time trying to get this approach to work and not writing tests.

>
>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.

Yes, that is the reason that it didn't appeal to me in the first place.
The reason I like it is that it doesn't add a dependency on the
streambuf or the streambuf_iterator types. If there is a mt issue in
either one of these, then the problem would manifest as a failure in the
locale facet test, which just seems odd. I realize that the liklihood of
a mt issue existing in either the basic_streambuf or the
streambuf_iterator is minimal at the moment but it might change in the
future. :)

>
>So I would suggest to roll your own very simple iterator derived
>from streambuf_iterator 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).

Yes, I realize that. I was just trying to eliminate as much non-facet
related code as I could from the test. Obviously I'm trying so hard as
to not be testing the cases that I should be.

>
>Martin
>

Travis