Re: Comparing strings (revisited)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 25, 2009 at 12:46:16PM +1000, Clancy wrote:

> For some time I have been working on a text based database, in which each
> entry contains
> one or more lines of data, with the various fields delimited by semicolons,
> e.g.
> 
> A;b;20GM;;;;;Restaurant;090508
> n;;;Arintji;;
> a;Federation Square;;;
> p;9663 9900;;;9663 9901;;info@xxxxxxxxxxxxxx;
> 
> All was going well but recently I decided to allocate every entry a unique
> identifier,
> and, in what with hindsight was clearly misguided enthusiasm, decided that
> each identifier
> should be a four digit base 36 number (the 20GM in the first line). This
> did not cause any
> problems until yesterday, when I tried to load a name beginning with 'R',
> and got the
> first name on the list. When I investigated I found that I was searching
> the array
> containing the data using:
> 
> 	if ($ident == $data[$i]['group']['ident'])  { ......
> 
> I then found that I was searching for 20E2, but was getting a match on
> 2000. I tried
> 
> 	'if ((string) $ident == (string) $data[$i]['group']['ident'])',
> 
> but this still matched. However
> 
> 	'if($ident === '
> 
> worked, as did
> 
> 	'if (!strcmp($ident, $data[$i])) {...'.
> 
> After puzzling about this for a long time, I realised that the comparison
> process must
> have been treating the second value as a floating point number, and
> converting it to
> integer, or vice versa.  (In floating point notation 20E2 = 20*10^^2 = 2000).
> I had
> thought that the (string) override meant to treat the actual value as a
> string, but in
> this case it must be converting the (assumed) actual value to a string,
> and then comparing
> the results.
> 
> This surprised me considerably as it is clear from the results I achieve
> in other
> circumstances that the data is actually stored as a raw string.
> 
> $data is a variable format array, and when the original data is read each
> line is exploded
> into a term of the data array: $data[][] = explode(';',$line[$i]);.
> If I print the value
> of the ident (or any other field) it is always shown as the original string,
> and when I
> save an updated version of the data, each term of the data array is imploded
> into a line
> of the data file in its original format. However if this value were actually
> converted to
> a floating point number when it was entered I would have to specify a
> format before I
> could write it out again, and as 20E2 is a rather  non-standard format it
> is most unlikely
> that it would come out as this unaided.
> 
> Is there any way to specify that each field is always to be treated as a
> string when I
> originally explode the input file into the data array?	For someone brought
> up on rigidly
> defined data types dynamic typing can be very confusing!

This is why I originated a thread along these lines some time ago.  I
sympathize with your pain, being a C programmer as well. Apparently, PHP
plays fast and loose with types when doing == comparisons. And empty()
has a really wild way of determining if something is "empty" (an integer
0 is "empty"?). Which is why I originally asked if strcmp() was the
preferred method of comparison for the list members.

In any case, strcmp() does what you want and is the safest way to
compare strings, which is what PHP passes around a lot (data comes out
of databases as strings, comes back from forms as strings, etc.). And
since most of the syntax and library functions of PHP are based on C
paradigms, I'm guessing that the PHP strcmp() function is a thin veneer
over the actual C function.

Paul

-- 
Paul M. Foster

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux