On 31-Oct-08, at 2:57 PM, Keith DeLong wrote:
Agreed that results should be consistent between platforms
But you should also not count on an int32 key grabbing something
inserted using an int64 key and vice versa
Strings have this behavior because of encoding (try Hello as ASCII
and
Hello as UTF16)
Int32 / Int64 may behave the same
Hey Norman,
While I agree it's easy to get into trouble because of legacy
Integer support and lousy string conversion support in RB.
The string issue has nothing to do with lousy string issues
Dictionaries don't use the VALUE, they use a hash of the variable and
the hash for a UTF16 string (say hello) is different than the hash for
UTF8 for the same string (which makes sense since it IS different bytes)
Some strings will behave "properly" because the bytes are the same
(ASCII and UTF8 for all code points < 128)
Special casing a dictionary to take into account the encodings would
actually be a significant hit
I'd asked about this the first time I ran into it about 2 years ago
and that was the answer
Whenever I use strings that might possibly be different encodings I
convert the string to UTF-8 and use that as the key so thing work as
you expect they should.
A simple subclass takes care of that once and for all.
We have a ton of legacy code that uses dim Integer instead of explicit
Int32 of Int64 declarations. RB needs to be cooperative to the
legacy code
or get rid of Integer all together and force the pain ;-)
Integer and Int32 should behave the same
Again, the VALUE is not used, a HASH is and since an Int64 has 8 bytes
and an int32 only 4 they generate different hashes as far as I
understand things
And while String.CLong has been a big help after years with Integer =
String.Val as the only way to convert strings to number (via an awful
implicit double to integer conversion.)
I'll plead again for the day when strings get some love so they have
the
same consistency Variants have received the past few years:
String.DoubleValue
String.Int64Value
String.Int32Value
String.CurrencyValue
String.DateValue
Datevalue ?
Like the magic "use parse date to guess what format this date is in"
routine ? :P
Numerics I could easily see
(Yes, I've filed a feedback on this long ago :-). I use lots of
listboxes
and dictionaries so smooth string to key conversions are really
important to
me.
Then always, always, always use the same types for keys (or at least
the same encodings if they are strings)
As you well know a dictionary has no trouble doing
dim d as new dictionary
d.value(123) = 123
d.value("123") = 123
d.value(123.0) = 123
in fact I have places in code I've written for other projects that
relies on this kind of behavior
Each gets a different hash and if they didn't I suspect it would cause
as much havoc in other ways
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|