stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Pevtsov" <Ant...@moscow.vdiweb.com>
Subject RE: svn commit: r398856 - /incubator/stdcxx/trunk/tests/strings/21.string.find.cpp
Date Wed, 03 May 2006 16:09:14 GMT
Martin Sebor wrote:
> I agree with that in general but I don't think we can define the
behavior in all these cases. Consider these two examples:
[...]
> Unless you see something wrong with this change, I will go ahead and
change string::find() et al not to throw. Then we will modify the    >
tests to exercise this new behavior. Let me know your thoughts.

Sounds good. I think npos will be more expected than an exception.


Thanks,
Anton Pevtsov


-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Wednesday, May 03, 2006 19:45
To: stdcxx-dev@incubator.apache.org
Subject: Re: svn commit: r398856 -
/incubator/stdcxx/trunk/tests/strings/21.string.find.cpp


Anton Pevtsov wrote:
> This verfies similar to 
> http://issues.apache.org/jira/browse/STDCXX-175
> possible problems.
> 
> Yes, it is tricky, the passed array has not enough length (-1 is 
> interpreted as max_size() + 1), but I think that the method 
> implementation should not create the string with such length.

Yes, that's what I'm thinking as well. I don't think it ever does.

> Formally the behaviour should be undefined, so we can remove these 
> tests as more strict than required by the standard.

I see. I think you're right, it is undefined.

> But I suggest to leave them: all methods pass these tests and the 
> exception throwning looks more useful than undefined behaviour for 
> this situation.

I agree with that in general but I don't think we can define the
behavior in all these cases. Consider these two examples:

     string s ("abc");
     s.find ("def", 0, 5);
     s.find ("def", 0, -1);

There is no way for us to detect that 5 is too large in the first call
to find() so the the function returns npos because "def" is not found.
But in the second example which is equally invalid we throw, even though
we could just as easily return npos. I think we might as well return
npos is all such cases for consistency. Doing so also simplifies the
implementation.

Unless you see something wrong with this change, I will go ahead and
change string::find() et al not to throw. Then we will modify the tests
to exercise this new behavior. Let me know your thoughts.

Martin

Mime
View raw message