Re: Array comparison

From: Rob Kennedy (me3_at_privacy.net)
Date: 10/06/04 

Date: Wed, 06 Oct 2004 01:08:24 -0500

Nicolai Hansen wrote:
>> Truely a 'problem/challenge' in Delphi ;)
>>
>> I wish arrays could be compared like that =D
>>
>> I see no reason why that should not be allowed ?
>>
>> Anybody see any reason ? =D
>
> Yes.
> How is it supposed to compare two arrays?

Apply the "=" operator to each of the array's elements.

I think I have to side with Skybuck on this one, and I don't need to
tell you how much it pains me to do that.

> If it should compare the elements; what if the elements were objects?

I would expect it do the same thing it already does when comparing two
objects. Just because something is in an array instead of a standalone
variable doesn't mean it should be treated specially.

var
   a, b: TObject;

if a = b then ...

> It would then also need to give you with a method of comparing any
> kinds of records, or classes. And how do you compare two classes? What
> if they contain pointers? What if they contain _untyped_ pointers?

The only valid point in that is records. The compiler already knows how
to compare everything else, although some of the comparisons (e.g.,
objects, pointers) aren't always the most useful. But that the compiler
doesn't know how to provide an intelligible comparison of two objects
does not explain why it can't compare two like-typed arrays.

The compiler can assign one array to another by applying the ":="
operator to each element. That occurs in the System._CopyArray
procedure, which takes a PTypeInfo argument so it can know how to copy
the array's elements. The same could be done for a generic _CompareArray
procedure.

> The only way the Pascal compiler can do these comparisons is to check
> if the addresses of the two arrays are the same. If they are, it is
> guaranteed that the two arrays are the same, else it is not. If you
> would have to check them it would be a long recursive procedure,

Sort of like the long recursive procedures that already exist to copy,
initialize, and finalize arrays and records. I's be happy to provide you
with implementations, if you're interested. (It's a tad long, so I won't
post it unsolicited.) The major obstacle is getting type information for
the records and arrays. The compiler does generate type information for
those types, but it doesn't make it accessible anywhere, so I had to
generate my own.

> and not even that can count for untyped pointers.

Untyped pointers are very easy to compare. People do it all the time.

var
   a, b: Pointer;

if a = b then ...

> C++ handles this by letting the programmer define the compare method
> between two integers; this is known as operator overload (quite a
> nifty thing), but Pascal can not support this for several reasons.

Free Pascal supports operator overloading. And as I understand it, later
versions of Delphi support it for custom Variant types.

Comparing two arrays does not require operator overloading any more than
any of Delphi's other array operations. It only requires valid type
information, something the compiler already has access to.

> The only way in Pascal is to write your own procedures (you actually
> do that in C++ also), like function IsEqual(comp1, comp2: TSameType):
> boolean - you can overload this as much as you want to make it compare
> any kind of types; make an IsEqual(comp1, comp2: Pointer) or
> IsEqual(comp1, comp2: TObject) to cover for all objects where you only
> want addresses compared...

Writing generic procedures to compare static arrays and records was a
cool little exercise. Tomorrow I'll tackle how to do a deep comparison
on dynamic arrays.

Whatever the reasons for disallowing "=" on static arrays and records,
technical difficulty is not one of them -- not nowadays, anyway. I'm
more inclined to say the reason is lack of customer demand for the feature. 

-- 
Rob

Relevant Pages

  • Re: Option Compare Statement
    ... both arrays are always the same type. ... compare text,. ... Your first post regarding this in the vb.controls newsgroup was, ... strings, let's say A and B. Then I want to compare their values. ...
    (microsoft.public.vb.general.discussion)
  • Re: Similarity searching
    ... a factor of N*log, if the arrays are big you won't in general have to compare to the last element so I don't see the factor of L**2, and I don't see where that C**2 factor is coming from at all. ... There are also sorting algorithms which don't compare each item to every other item, yet still generate a sorted result. ... If electricity comes from electrons, ...
    (comp.lang.fortran)
  • Re: Hashtable Contains() - byte arrays as keys -
    ... > But that would again mean he will have to iterate and compare each entries ... Assuming I understand his problem (that he needs the byte arrays to ... entries of the arrays. ... The hashcode might be cacheable if the byte arrays are not changed once ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Similarity searching
    ... a factor of N*log, if the arrays are big you won't in general have to compare to the last element so I don't see the factor of L**2, and I don't see where that C**2 factor is coming from at all. ... There are also sorting algorithms which don't compare each item to every other item, yet still generate a sorted result. ... Similarity searching is still an active science, but there are a lot of useful algorithms out there now. ...
    (comp.lang.fortran)
  • Re: Array comparison
    ... > I see no reason why that should not be allowed? ... How is it supposed to compare two arrays? ... If it should compare the elements; what if the elements were objects? ... What if they contain _untyped_ pointers? ...
    (alt.comp.lang.borland-delphi)