Solved String compare

While porting a plugin implementation between R19, R20, R21 I noticed a potential problem I might have introduced.

In R19 I had been using:

String stringA, stringB;
...
Bool match = (stringA.Compare(stringB) == 0);

In R20, due to the introduction of maxon::String the return value of the comparison was replaced from an Int to an enum COMPARERESULT.
For some obscure reason I managed to overlook this and had ported the original implementation to:

maxon::String stringA, stringB;
...
Bool match = (stringA == stringB);

Thus completely neglecting the Compare function.
While this seems to work, I am now looking into converting all my existing R20 code to again use the Compare function.
But I am wondering what possible problems I would face by keeping the current equality operator?

Daniel

hello,
if you want to retrive a Bool you can use IsEqual

the operator == is using the function "IsEqual" witch does use the ComparePart function like so

return ComparePart(str, STRINGCOMPARISON::MEMORY, 0, StringEnd()) == COMPARERESULT::EQUAL;

Cheers,
Manuel

MAXON SDK Specialist

MAXON Registered Developer

@C4DS said in String compare:

But I am wondering what possible problems I would face by keeping the current equality operator?

You potentially run into problems once the enum or the type changes. If the type is not deductable to Bool then your code simply will not work. This is the best case as you will get the error at compile time.

However, it may get worse. Since old style enum values a re just Int, value with 0 and 1 may get collapsed to true and false that can lead to undefined behavior.
Although Maxon is very clear and disciplined about structuring their types, I would not rely on it. There's always a chance those types and orders may change.

So, if you ask me: Make it right before it breaks. 😉

edit: For the equality comparison, seems like it's just wrapped around the builtin lower level compare. So, it should be safe to use it.

@mp5gosu
Thanks for the response, but I am not sure to understand what you are trying to say.

You're replying on the fact of using the equality operator that one could potentially run into problems.
Then you add a statement that using the equality operator is safe to use.
I am confused.

Furthermore, I don't see what old style enum values have to do with the current situation?
In R19 I perform a Compare which returns an Int. I compare this with 0, resulting in a Bool.
No enum is involved here, as far as I understand.
In R20 code no old style enums are used at all.

Oh yes, I misunderstood your post - almost completely. 🙂

Somehow I thought, you're still using Compare in R21 - which you obviously don't do. But you're planning to do so.
Sorry for the confusion.

As for the equality operator: Cannot tell for sure, but it seem that from the deprecated operator (which will vanish some time) uses an implementation that also does character-wise comparison. So still, it is currently a valid way to compare strings, although not future-proof.

@mp5gosu
OK, got.
For R20 I could keep using the equality operator, for R21 and future this would probably not be the best solution.

I will update both R20 and R21 code with the appropriate Compare.

Maybe someone from SDK team will chime in and clarify the equality operator issue (if any).

hello,
if you want to retrive a Bool you can use IsEqual

the operator == is using the function "IsEqual" witch does use the ComparePart function like so

return ComparePart(str, STRINGCOMPARISON::MEMORY, 0, StringEnd()) == COMPARERESULT::EQUAL;

Cheers,
Manuel

MAXON SDK Specialist

MAXON Registered Developer

@m_magalhaes
Thanks for bringing this up, as it seems I had overlooked it on multiple occasions.
Which also points me to the fact that the R19 SDK did have a String::operator == ()
Also overlooked that all those years. I need better glasses.