Closed
Bug 53062
Opened 25 years ago
Closed 25 years ago
Move |Find| and |RFind| up into |nsAReadableString|
Categories
(Core :: XPCOM, defect, P3)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
People
(Reporter: scc, Assigned: scc)
Details
Attachments
(4 files)
|
3.36 KB,
patch
|
Details | Diff | Splinter Review | |
|
7.98 KB,
patch
|
Details | Diff | Splinter Review | |
|
6.99 KB,
patch
|
Details | Diff | Splinter Review | |
|
7.26 KB,
patch
|
Details | Diff | Splinter Review |
This is critical for Vidur's parser work.
| Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
| Assignee | ||
Comment 1•25 years ago
|
||
| Assignee | ||
Comment 2•25 years ago
|
||
I still need to test the |Find| patch, above; I'm working on |RFind|. These
implementations should have the same performance as our old favorites in |
ns[C]String|.
| Assignee | ||
Comment 3•25 years ago
|
||
Ooops. That first nested |while| should read
while ( aSearchStart != aSearchEnd && *aPatternStart != *aSearchStart )
........................................................^
Sorry.
| Assignee | ||
Comment 4•25 years ago
|
||
When I attach the next patch it will include |RFind| and a fixed version of the
previously attached |Find|
| Assignee | ||
Comment 5•25 years ago
|
||
OK, after discussion with Vidur ... we probably don't want to make this signature
a member function. The following patch fixes the error mentioned above; moves
the implementation to non-member functions in "nsReadableUtils.h", and to avoid
the possibility of `type-unification errors' ... made the visible API be non-
template functions. The implementation remains templatized.
| Assignee | ||
Comment 6•25 years ago
|
||
| Assignee | ||
Comment 7•25 years ago
|
||
Note also that error handling is sligtly improved in the above patch (detecting
empty search range)
| Assignee | ||
Comment 8•25 years ago
|
||
OK, new patch includes a (theoretically) working equivalent for |RFind|. More
testing to do, and either Vidur or I will also add equivalents for |FindChar|.
| Assignee | ||
Comment 9•25 years ago
|
||
Comment 10•25 years ago
|
||
An iterator version of |FindChar|:
template <class CharT>
inline // probably wishful thinking
PRBool
FindCharInReadable_Impl( CharT aChar,
nsReadingIterator<CharT>& aSearchStart,
nsReadingIterator<CharT>& aSearchEnd )
{
while ( aSearchStart != aSearchEnd )
{
PRInt32 fragmentLength;
if ( SameFragment(aSearchStart, aSearchEnd) )
fragmentLength = aSearchEnd.get() - aSearchStart.get();
else
fragmentLength = aSearchStart.size_forward();
const CharT* charFoundAt = nsCharTraits<CharT>::find(aSearchStart.get(),
fragmentLength, aChar);
if ( charFoundAt ) {
aSearchStart.advance( charFoundAt - aSearchStart.get() );
return PR_TRUE;
}
aSearchStart.advance(fragmentLength);
}
return PR_FALSE;
}
NS_COM
PRBool
FindCharInReadable( PRUnichar aChar, nsReadingIterator<PRUnichar>& aSearchStart,
nsReadingIterator<PRUnichar>& aSearchEnd )
{
return FindCharInReadable_Impl(aChar, aSearchStart, aSearchEnd);
}
NS_COM
PRBool
FindCharInReadable( char aChar, nsReadingIterator<char>& aSearchStart,
nsReadingIterator<char>& aSearchEnd )
{
return FindCharInReadable_Impl(aChar, aSearchStart, aSearchEnd);
}
| Assignee | ||
Comment 11•25 years ago
|
||
| Assignee | ||
Comment 12•25 years ago
|
||
well this has been checked in too, right Vidur? (LXR makes it look like it's
in, anyway)
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Component: XPCOM → String
Resolution: --- → FIXED
Updated•5 years ago
|
Component: String → XPCOM
You need to log in
before you can comment on or make changes to this bug.
Description
•