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 Thu, 06 Jul 2006 23:34:25 GMT
Anton Pevtsov wrote:
> Martin Sebor wrote:
> 
>>Because the virtual function gets called for each character?
> 
> 
> Yes. Moreover, the one call of the operator in the test may result in
> calls to several virtual functions (one by one).

Hmm, I guess since we're throwing an exception on each call to
the virtual function until the input or output function finally
succeeds in processing all N characters we end up with an O(N*N)
algorithm. That might be tolerable for short character sequences
but it quickly becomes a bottleneck for long strings (e.g., the
ones that are 4K long).

> Here is the question: are there any restrictions on the order and number
> of the streambuf virtual functions calls?
> If no, shall we exercise the exception throwing from all virtuals or it
> will be enough to verify xsgetn, xsputn, overflow, underflow?

I don't know of any requirements on the exact order of calls
to the virtual members. Output functions (such as operator<<)
are permitted to call only overflow(), sync(), or xsputn()
(see 27.6.2.1, p2). The restrictions on Input functions are
less clearly specified (27.6.1.1, p2) but it stands to
reason they are intended to be analogous (i.e., underflow(),
and xsgetn(), and perhaps also sync()).

So throwing from just those 5 would be fine. The tests should
also verify that none of the other virtual functions is called
(since it's not permitted).

> 
> Martin Sebor wrote:
> [...]
> 
>>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.
> 
> I think this is a good idea, I'll implement this approach for overflow
> and underflow and may be for some other virtual functions.

Okay, looking forward to seeing it :)
Martin

Mime
View raw message