 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
François Charton
Guest
|
 Posted: Wed Mar 30, 2005 2:13 pm Post subject: More AnsiString comparisons |
 |
|
Hello,
I am still looking for a comparison function for AnsiStrings, which would
look like
int UnknownCompareFunction(String A, String B)
and return an integer, (positive if A>B, negative if B>A and zero if A=B),
with results strictly equivalent to those of AnsiString::operator< and
AnsiString::operator>
Apparently, the AnsiString comparison operators compare strings on a byte
per byte ascii value basis, which means that functions like
AnsiCompareStr(String A, String B) won't do (for instance, they order
lowercase and uppercase versions of a letter in the opposite order than
their ascii code).
On the other hand, CompareStr(A,B)
seems to provide the same results (on all the cases I tested so far).
strcmp(A.c_str(),B.c_str()) does likewise, but I woud prefer to stick to VCL
functions.
However, looking at the VCL code, I have noticed that these two functions
(operator< and CompareStr), though both implemented in assembly, use fairly
different code. The operator relies on a call to LStrCmp(AnsiString
A,AnsiString B) defined in system.hpp, whereas CompareStr() is coded in pure
assembly. In particular, special cases (like one member of the comparison
being an empty string) are handled differently (though the result might be
same, I don't know enough assembly language to be sure).
The safest solution would probably be, then, to call LStrCmp() directly. But
I could not call such a function from my code. Apparently, its prototype is
not defined in the VCL headers, and it is not documented in the help, so I
suppose it is not for "external use"...
So far, I use CompareStr(), which seems to work fine, but might get wrong on
some special case. Is it the case? If so, should I try to call LStrCmp()
directly, (how)? or is there a better "prepackaged" solutions?
Thanks in advance
Francois
|
|
| Back to top |
|
 |
Remy Lebeau (TeamB)
Guest
|
| Posted: Wed Mar 30, 2005 7:20 pm Post subject: Re: More AnsiString comparisons |
|
|
"François Charton" <fcharton (AT) carthage (DOT) fr> wrote
| Quote: | So far, I use CompareStr(), which seems to work fine, but might
get wrong on some special case. Is it the case? If so, should I try
to call LStrCmp() directly, (how)? or is there a better "prepackaged"
solutions?
|
If you have two AnsiStrings, and want the same results as the comparison
operators, then why not just call the operators themselves? What EXACTLY
are you trying to accomplish in the first place?
Gambit
|
|
| Back to top |
|
|
Chris Uzdavinis (TeamB)
Guest
|
| Posted: Wed Mar 30, 2005 10:23 pm Post subject: Re: More AnsiString comparisons |
|
|
"Remy Lebeau (TeamB)" <no.spam (AT) no (DOT) spam.com> writes:
| Quote: | "François Charton" <fcharton (AT) carthage (DOT) fr> wrote in message
news:424ab120 (AT) newsgroups (DOT) borland.com...
So far, I use CompareStr(), which seems to work fine, but might
get wrong on some special case. Is it the case? If so, should I try
to call LStrCmp() directly, (how)? or is there a better "prepackaged"
solutions?
If you have two AnsiStrings, and want the same results as the comparison
operators, then why not just call the operators themselves? What EXACTLY
are you trying to accomplish in the first place?
|
The problem is that he wants similar results as strcmp, with <0, 0, >0
results.
The problem is an efficient algorithm:
if (a < b)
return -1;
else
if (a == b) return 0;
else
return 1;
The problem with the above code which makes direct use of the
operators (assuming a and b are AnsiStrings), is that calling
operator< and then operator== on the string can be wasteful.
Especially if they are extremely long strings and their only point of
divergence is near the end of the strings.
It's more efficient to do this:
return strcmp(a.c_str(), b.c_str());
But his concern is that the comparisons used by strcmp may not be
idental to the comparisons used by the operators in AnsiString.
(locale differences, ordering of upper/lower letters, etc.)
I can only suggest making a good test suite, ensuring they all pass
using the "slow" if/else/else version, and then change the algorithm
to use strcmp() as shown above, and ensure that the test suite still
passes. Without tests, it's hard to know when something breaks...
especially if the changes only occur at boundry or other specific
cases.
I like strcmp better than VCL compare functions just for the sake of
it being standardized across all platforms and between all C and C++
compilers. VCL functions only work with Borland, and add unnecessary
dependency on VCL code. (Admittedly, if you're already stuck using
AnsiString, then it doesn't hurt as much to lock yourself in more,
unless there is any desire to ever make the code more portable instead
of less.)
--
Chris (TeamB);
|
|
| Back to top |
|
|
François Charton
Guest
|
| Posted: Thu Mar 31, 2005 5:55 pm Post subject: Re: More AnsiString comparisons |
|
|
"Chris Uzdavinis (TeamB)" <chris (AT) uzdavinis (DOT) com> a écrit dans le message de
news: >
| Quote: | The problem is that he wants similar results as strcmp, with <0, 0, >0
results.
The problem is an efficient algorithm:
if (a < b)
return -1;
else
if (a == b) return 0;
else
return 1;
|
Quite so. I am using a dichotomic search on a fairly large base of strings,
the loop goes :
int end=n-1;
int start=0;
while(end>=start) {
int pos=(end+start)/2;
String S=StringBase[pos];
if(TstString==S) return pos;
if(TstString
else start=pos+1;
}
return -1;
Now, the comparisons are all the more wasteful as the < operator for string
actually calls a function LStrCmp, which does the same as strcmp(), and
tests its sign...
| Quote: | But his concern is that the comparisons used by strcmp may not be
idental to the comparisons used by the operators in AnsiString.
(locale differences, ordering of upper/lower letters, etc.)
|
Actually, strcmp() seems to be sorting strings in the same order as the
operator, but I am concerned about some odd/untested case (empty strings,
special characters and the like). Besides, wouldn't the casts in
strcmp(A.c_str(),B.c_str())
imply some overhead (I know, I should look at the generated code to be sure,
but...)
| Quote: | I like strcmp better than VCL compare functions just for the sake of
it being standardized across all platforms and between all C and C++
compilers. VCL functions only work with Borland, and add unnecessary
dependency on VCL code. (Admittedly, if you're already stuck using
AnsiString, then it doesn't hurt as much to lock yourself in more,
unless there is any desire to ever make the code more portable instead
of less.)
|
I use the VCL because it is an very efficient way to design and maintain an
interface. As such, a large part of my application is Borland specific, so
why not use the good borland-isms, like AnsiStrings?
Another point for the use of VCL (or any) compare functions in strings is
that it allows one to use templates, or the stl. Once you have a comparator
defined, any function defined (and tested) on integers or float (which use
comparators) is valid for strings. Also, the < notation is very readable,
and in many cases quite sufficient.
Francois
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
