«

Jujitsu Lizard wrote:
>
> In the general case, if s1 and s2 are structures, am I allowed to
> just use:
> s1 = s2;

Yes, provided s1 and s2 are the same struct type. What you cannot
do (because of padding, etc) is compare them for equality. i.e.:

if (s1 == s2) ...

is not legal.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

On Dec 18, 6:43*am, CBFalconer <cbfalco...@yahoo.com> wrote:

> Yes, provided s1 and s2 are the same struct type. *What you cannot
> do (because of padding, etc) is compare them for equality. *i.e.:
>
> * * if (s1 == s2) ...
>
> is not legal.



I'm very surprised at this. I tried it just there with a C compiler
and also with a C++ compiler, and both gave a compiler error. I don't
see why they couldn't have made the comparison result in a comparison
of all members, something like:

#define (a == b) (a.i == b.i && a.j == b.j && a.k == b.k)

So if you want to compare two structs for equality (I'm talking value
equality as opposed to binary equality), then you actually have to
verbosely compare member by member? That's a pain.

Tomás Ó hÉilidhe wrote:
> On Dec 18, 6:43 am, CBFalconer <cbfalco...@yahoo.com> wrote:
>
>> Yes, provided s1 and s2 are the same struct type. What you cannot
>> do (because of padding, etc) is compare them for equality. i.e.:
>>
>> if (s1 == s2) ...
>>
>> is not legal.
>
>
>
> I'm very surprised at this. I tried it just there with a C compiler
> and also with a C++ compiler, and both gave a compiler error. I don't
> see why they couldn't have made the comparison result in a comparison
> of all members, something like:
>
> #define (a == b) (a.i == b.i && a.j == b.j && a.k == b.k)
>
> So if you want to compare two structs for equality (I'm talking value
> equality as opposed to binary equality), then you actually have to
> verbosely compare member by member? That's a pain.
So write a function:
int ismystructequal(mystruct a,mystruct b){
return(a.i == b.i && a.j == b.j && a.k == b.k)
}
Or something like that.
But you might have problems if the struct contains arrays and/or
pointers.
Should the pointers be equal, or should the data pointed to, be equal?
And a host of other problems when the struct becomes more obscure.
You quickly reach a point where the compiler knows less than you do,
and therefore the compiler rightly leaves that job to the programmer.

On 18 Dec 2008 at 5:27, Tomás Ó hÉilidhe wrote:
> So if you want to compare two structs for equality (I'm talking value
> equality as opposed to binary equality), then you actually have to
> verbosely compare member by member? That's a pain.

In C++ of course, you can overload the == operator.

If you're doing object-oriented programming in C, yes, you need to be
more verbose, e.g. having mytype_isequal() functions/macros. But then
you also need to have a mytype_init() function rather than having a
constructor.

While OO programming can be done perfectly well in C, C wasn't designed
with OO in mind, so an OO approach does lead to quite verbose code. Look
at glib as the ultimate example of this!

Tomás Ó hÉilidhe wrote:

> On Dec 18, 6:43*am, CBFalconer <cbfalco...@yahoo.com> wrote:
>
>> Yes, provided s1 and s2 are the same struct type. *What you cannot
>> do (because of padding, etc) is compare them for equality. *i.e.:
>>
>> if (s1 == s2) ...
>>
>> is not legal.
>
> I'm very surprised at this. I tried it just there with a C compiler
> and also with a C++ compiler, and both gave a compiler error. I don't
> see why they couldn't have made the comparison result in a comparison
> of all members, something like:
>
> #define (a == b) (a.i == b.i && a.j == b.j && a.k == b.k)

Because that's often the wrong answer. Consider (a) structs with
`char*` members: what's the (one, single, only) right way to compare them?
Consider (b) this (illustrative) example:

struct SmallStringBuffer { char[17] content; int size; }

I have in my left hand a StringBuffer with content [`A`, 0 (16)]
(the parenthesised number is a repeat count), and size 1, and in my
right hand one with size 1 and content [`A`, `B` (16)]. Are they
equal?

If the compiler/language can't guess the right answer often enough,
perhaps it doesn't need to guess at all.

> So if you want to compare two structs for equality (I'm talking value
> equality as opposed to binary equality), then you actually have to
> verbosely compare member by member? That's a pain.

Slightly. But only slightly: that's why the gods gave us functions.

Of course, it would be nice if it was easy to use the functions without
lots of syntactic clutter. But lets not overload this response with that
discussion.

--
"We dance, and the worlds melt away." - Curved Air, /Metamorphosis/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

On Dec 18, 4:32*pm, Antoninus Twink <nos...@nospam.invalid> wrote:

> While OO programming can be done perfectly well in C,
> C wasn't designed
> with OO in mind, so an OO approach does lead to quite verbose code. Look
> at glib as the ultimate example of this!



I think it's a great exercise to take some complicated C++ code
(containing stuff like virtual functions), and rewrite it in C. I
first did this myself a few years ago and learned loads from it. C++
is taught in a "black box" way by most books and by most institutions;
they portray such things as virtual functions as "magic". They'll show
you how to use virtual functions, but never actually show how they
work in terms of machine code (or even in terms of C). I first learned
about virtual functions from reading "C++ for Dummies", and my first
reaction was "Holy **** that's amazing, how does the called function
know the type of the object being passed?!". That bugged me for a
while until I found out about VTable's... and of course then I had to
write my own VTable code in C to see if I could get it working. When I
got it working I was like "so it's not magic after all", and then I
was comfortable with my understanding of how it worked.

Yeah a lot of the OO things in C++ can be achieved in C just by using
pointers and helper functions such as "void MyClass_Construct(void)",
but if you bring templates into the picture then the C code becomes an
absolute dog's dinner. And there's definitely loads of stuff you can
do with templates in C++ which can't do /at all/ in C.

The only reason I write C code, as opposed to C++ code, is that it's
more portable. I mean if a particular platform has /any/ kind of
compiler, there's a strong likelihood of it being a C compiler. Plus
it's rare that I feel the need for OO programming (but there
definitely are cases where I opt for C++ because it has some really
elegant ways of solving particular problems).

In article <gid8v1$5u1$>,
Chris Dollin <> wrote:

>Because that's often the wrong answer. Consider (a) structs with
>`char*` members: what's the (one, single, only) right way to compare them?

Consider two char * variables: what's the one right way to compare
them?

It's hardly in the spirit of C to reject something because it's not
always what you need.

(I use that phrase because the Rationale rejects structure comparisons
on the grounds that it might involve an arbitrarily long sequence of
instructions, which is "not in the spirit of C".)

-- Richard
--
Please remember to mention me / in tapes you leave behind.

In article <> ,
Anthony Fremont <> wrote:

>> (I use that phrase because the Rationale rejects structure comparisons
>> on the grounds that it might involve an arbitrarily long sequence of
>> instructions, which is "not in the spirit of C".)

>LOL Where does that leave printf?

That's not fair: printf() is a function, not a language feature.

You could make a better case with switch, I think.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

In article <> ,
Anthony Fremont <> wrote:

>Ok, that's true. I still think a simple == or != comparison would be no
>more instruction intensive than the assignment operation is.

The comparison operations have to ignore padding, so can't generally
be compiled into something as simple as memmove().

>IMO, switch should be efficient on most hardware since the case labels
>require a constant expression. Or am I missing something?

Switch is typically compiled into a jump table when the cases have
contiguous (or nearly so) values, and a sequence of tests and
conditional jumps if they are "random", but I have seen cases where a
single switch produces a long sequence of tests, jumps, and tables.
Of course, such cases arise from switches occupying long stretches of
source code, unlike a comparison.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

Richard Tobin wrote:

> In article <gid8v1$5u1$>,
> Chris Dollin <> wrote:
>
>>Because that's often the wrong answer. Consider (a) structs with
>>`char*` members: what's the (one, single, only) right way to compare them?
>
> Consider two char * variables: what's the one right way to compare
> them?

The compiler doesn't /implicitly/ generate code for comparing
two char* values: unlike the proposed case of struct members,
where the decision has to be made automagically, you write
what you want.

> It's hardly in the spirit of C to reject something because it's not
> always what you need.

It's in the spirit of C not to pre-empt decisions that the programmer
might want to make differently.

> (I use that phrase because the Rationale rejects structure comparisons
> on the grounds that it might involve an arbitrarily long sequence of
> instructions, which is "not in the spirit of C".)

And yet it doesn't reject function calls on the grounds that they
might involve arbitrarily long sequence of instructions, nor function
bodies on the same basis. It's not, I belive, that the sequences are
/long/; it's that they're /hidden/ and long, so that `a == b` might
"unexpectedly" generate wads of code or "unexpectedly" be "inefficient".

I find the long-sequence objection far less compelling than the what-meaning
objection, but in any case am not advocating a change to the C `==`
definition, that fight having been lost or rendered irrelevant a long
time ago.

--
"It's just the beginning we've seen." - Colosseum, /Tomorrow's Blues/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England