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: svn commit: r418319 - /incubator/stdcxx/trunk/tests/strings/21.string.io.cpp
Date Wed, 05 Jul 2006 16:00:49 GMT
Anton Pevtsov wrote:
> Martin Sebor wrote:
> 
>>In fact, we might want to have a single throw function, say
> 
> rw_throw(ExceptionId id, const
> 
>>char* file, int line, const char *function, const char *format, ...)
> 
> to throw a particular exception from a test driver's class or function.
> That way we would have a single point of throwing an             >
> exception in the whole test driver which is useful for setting
> breakpoints and to reduce code duplication.
> 
> I am working on this. I suggest to implement this function in a separate
> header (say rw_exception.h).

That's a good idea. We'll be able to move the duplicate definitions
of the exception arrays from all the string tests into the header,
too.

> 
> Also I implemented the exception safety loop in 21.string.io in the same
> to other tests way but faced with a perfomance problem.
> The streambuf virtual functions for long strings (say "x@4096") are
> called very often

Because the virtual function gets called for each character?

> and as a result the test is performed very slowly. I
> suggest to reduce the thrown exception count to 3 or 5 for the long
> strings (throw on first and last elements and on several in the middle)
> and leave this count unchanged for short strings (the streambuf will
> throw on each element).
> What do you think about this?

Reducing the number of thrown exceptions sounds reasonable. But
rather than hardcoding the number across all test cases I wonder
if each test case should (optionally) specify when (or how many
times) the stream buffer should throw the exception. That way
we would be able to precisely control the behavior of each test
case. One way to do it might be to designate a special symbol
(e.g., '!') that, when encountered as the next character in
the input sequence, would cause the virtual function to throw.

Martin

Mime
View raw message