Bug #17614 2010-10-15 22:34

austin_hastings

Squirrel script '==' fails for wxStrings

In a squirrel script, I wrote:

=====

function compare_wxstrings( left, right ) {

Log( _T( "\nComparing strings |" )

+ left + _T( "| and |" ) + right +_T( "|" ) );

if( left != right ) { Log( _T( "\tdifferent" ) ); } else { Log( _T( "\t! different" ) ); }

if( left > right ) { Log( _T( "\tgreater" ) ); } else { Log( _T( "\t! greater" ) ); }

if( left < right ) { Log( _T( "\tlesser" ) ); } else { Log( _T( "\t! lesser" ) ); }

if( left == right ) { Log( _T( "\tsame" ) ); } else { Log( _T( "\t! same" ) ); }

}

=====

I called it with:

compare_wxstrings( _T("a"), _T("a") ); // expect same

compare_wxstrings( _T("b"), _T("c") ); // expect lesser, different

compare_wxstrings( _T("e"), _T("d") ); // expect greater, different

======

The greater/lesser compares work okay, but the == compare always fails. (!!)

I tried this:

=====

local x = _T("x");

compare_wxstrings( x, x );

=====

And it reports 'same'.

Looking at the wxString OpCmp source code, it certainly appears that if opcmp is being called, it should return the 0 that the wxString.Cmp function returns.

Looking at the squirrel VM source, it looks as though the == comparison generates an OP_EQ, which is handled differently from the .gt. and .lt. operators.

I don't know if the C::B bindings is lacking an integration function that would hook up == to wxString, or if perhaps the squirrel object model assumes value semantics and does not support using == for other than identity comparisons.

But I do know that == really ought to return true in the test cases above.

Category

Application::WrongBehaviour

Group

 

Status

Closed

Close date

2010-12-05 14:56

Assigned to

biplab