Re: Array comparison

From: Jamie (jamie_5_not_valid_after_5_Please_at_charter.net)
Date: 10/09/04 

Date: Sat, 09 Oct 2004 12:40:25 -0700

the problem with arrays is this.
  you can perform a memory compare scan how ever, you
must be aware that things like Class Objects and
pointers are only going to compare their object pointers
and memory pointers, not the actual content of what the
pointer is referring too.
   and of course the arrays must hold the same type of
members to start with.
   for example
  doing an array of string is miss leading in 2 ways.
  1. if they are ansi and not short strings you are only comparing the
pointers and not the contents of the strings.
  2. for short strings it would work how ever, you may have left over
garbage that is not being referenced in the short strings that do not
  match and thus the compare would fail even though the strings that
have the valid info matches.
   in this case one should always do a Fillchar on a string or Record
that holds Short strings to insure that left over garbage is not in there .
  etc.,.
   if you were doing things that did not involve these such types then
you would have no problem doing a complete memory compare.
  things like array of Char, bytes, words, dword, int64's etc..
  and yes. the dynamic arrays can be memory compared also.

Nicolai Hansen wrote:
> *snip*
>
>
>>I think I understand. You're saying that if arrays and records are
>>comparable, then objects should also be comparable -- more than just by
>>reference -- right?
>
>
> Yes :) There should be no difference if you has an array type, or
> encapsulate that array type in an object. [if I want to make my
> strings type TStr=object length: byte; str: array of char; end; I
> should be able to compare these two...]
>
>
>>But if objects are going to be compared deeply, then they should be
>>assigned deeply, and that will break everything. Everything.
>
>
> Yes. In Pascal it would :) Because Pascal got the major weakness that
> objects are ALWAYS references - and what I am trying to say is that
> this might be the whole reason array types are not comparable.

Relevant Pages

  • Re: K&R2 Secition 5.9 - major blunders
    ... Would changing 'point to a' to 'point into a' twenty element array be ... > arrays of pointers is to store character strings of diverse ... comparison between what was really happening (arrays of pointers to ... pointer to a string(this probably would confuse beginners)" and ...
    (comp.lang.c)
  • Re: Test if pointer points to allocated memory
    ... >> or one past the same object or array. ... When two pointers are compared, the result depends on the relative ... pointers to structure members declared later compare ... > The typical implementation of automatic storage is on the program stack. ...
    (comp.lang.c)
  • Re: reading strings from file
    ... > it opens the file correctly but then the sscanf returns 0, ... those pointers need to point to something. ... strings to random locations in memory. ... in itself an array of char, so to allocate an array of strings, you need ...
    (comp.lang.c)
  • Re: Questions regarding specialized malloc()/free() replacements
    ... that range *must* compare not-equal. ... Equal, not equal, sure, but the others require that the pointers be ... | or both point one past the last element of the same array object, ... | and pointers to array elements with larger subscript values compare ...
    (comp.lang.c)
  • Re: initializing table of strings
    ... >sense to set strings in decleration. ... The fact that it is an array of pointers to const char does not matter ...
    (alt.comp.lang.learn.c-cpp)