TOPIC:

Hi all Pearlers,

Doing some research I came across this webpage , comparing different ways of determining if a string contains a substring.

Hope it is of interest to some.

Did you intend to share a link with us?

EDIT -I was on my iPhone when I first read the message, and did not notice the link in you message.

? It works
BTW, reading and trying with the X#-runtime sample, i wrote
? (STRING)uXSharpUsual:Contains( "run")
resulting in:
error XS1061: 'XSharp.__Usual' does not contain a definition for 'Contains' and no accessible extension method 'Contains' accepting a first argument of type 'XSharp.__Usual' could be found (are you missing a using directive or an assembly reference?) 9,1 Start.prg strings
while
VAR x :=(STRING)uXSharpUsual
? x:Contains("run")
works flawless.
Is that to expect?

Hi,

try:
? ((STRING)uXSharpUsual):Contains( "run")

Stefan

FoxProMatt_MattSlay wrote: Did you intend to share a link with us?

Yes "this webpage" is the link...

Stefan,
works, thx.
So, it seems, the implicit prioritiy of the conversion is higher than the method call.

Karl

Karl,

FFF wrote: Stefan,
So, it seems, the implicit prioritiy of the conversion is higher than the method call.

Usual don't contain a method :Contains() from what I read from the error message.
Your example is casting the Logic returned from Contains() to a string, which is fine.

Johan,
nope, i cast the usual to a string, for which Contains IS defined.
I was fooled, thinking, "(String)myUsual" would be evaluated prior to myUsual:Contains...

Anyway, the link made an interesting read, THX!

Strange part about his tests is that apparently string:Replace() is (slightly) faster than string:Contains(), at least for when the search string is not actually included in the target string. When the string is actually part of the target string, then the Contains() method is as expected a lot faster than the "replace" method. But because his tests use random strings (so not a common real life scenario), his method with replace is a little faster. In real life conditions, Contains() is better.

Also the reason why IndexOf() appears to be slower, is because by default it does culture dependend string comparisons, while Contains() only does ordinal comparison (compares byte by byte). It is easy to make IndexOf() perform an ordinal comparison as well (with the StringComparison.Ordinal parameter), in which case it has the same performance as Contains().

Plus, IndexOf() is a lot more powerful than Contains(), allows for optionally ignoring case and for specifically search for single chars which is even faster, so the best/more powerful/faster method to use is that, IsIndexOf(). It's just that "Contains()" is much more self explanatory when read in the code, so I personally tend to use it more often.

Hi Chris,

Chris wrote: Strange part about his tests is that apparently string:Replace() is (slightly) faster than string:Contains()

Yes I found that quite interesting, my initial thoughts would be that this would be extremely slow...

then the Contains() method is as expected a lot faster than the "replace" method

Yes this is what I also expected

Also the reason why IndexOf() appears to be slower, is because by default it does culture dependand string comparisons, while Contains() only does ordinal comparison (compares byte by byte). It is easy to make IndexOf() perform an ordinal comparison as well (with the StringComparison.Ordinal parameter), in which case it has the same performance as Contains().

I think this just highlights some of the issue with the "standard" implementation. IndexOf() is so much more powerful and I rather prefer using this, specially in cases of instead of doing:Which one might think will give a "slight" performance improvement, but obviously not.

Plus, IndexOf() is a lot more powerful than Contains(), allows for optionally ignoring case and for specifically search for single chars which is even faster, so the best/more powerful/faster method to use is that, IsIndexOf(). It's just that "Contains()" is much more self explanatory when read in the code, so I personally tend to use it more often.

I also use contains quite a lot, but by intelligently making use of IndexOf() one can eliminate the speed penalty.

Again, interesting read, thx.
One caveat i found with indexof
? VAR x := "ABC"
? x:IndexOf("AB")
? x:IndexOf("")

You get (also) "0" back, if by chance/oversight your search string was "lost" prior to searching.
You'll get the same with contains, but in is case, i'd preferred an exception for "Empty". Can't imagine a "useful" search with ""...

Hi Karl,

you should'nt ask if something is 'useful' in the .Net framework. There are many things where you can ask for the use case.
I always look at the docs and don't ask why. I take it as god given or search for something else that is better for my needs.

Stefan

PS: docs.microsoft.com/de-de/dotnet/api/syst...dexOf_System_String_

Hi Stefan,
God? Oh my God
I had looked at the docs, thx.

BTW, a good sample how automatic translation can fail:
The english doc version has a sample, described:
..." The following example looks for "n" in "animal"
gets in German:
"Das folgende Beispiel sucht nach "n" in "Tier"
Good, that they at least didn't translate the code

oh yeah, i mostly do read the english version. To understand the german version I often have to read it three times to understand what is meant.

FFF wrote: Good, that they at least didn't translate the code

Grrr and there all my efforts to code in German fails miserably...