From: Casper H.S. Dik on
John Gordon <gordon(a)panix.com> writes:

>To demonstrate, imagine that you intended to type this:

> if (x == 7)

>But you mistakenly typed this:

> if (x = 7)

>This is legal code but will not behave in the way you intended.

>But if you had typed it this way:

> if (7 = x)

>The compiler will throw an error.

But leaves you with unreadable code.

You are using the wrong tools; proper tools will detect this.

lint:

(4) warning: assignment operator "=" found where "==" was expected

and gcc:

foo.c:4: warning: suggest parentheses around assignment used as truth value


Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: ImpalerCore on
On Mar 4, 10:52 am, John Gordon <gor...(a)panix.com> wrote:
> In <oct467-nu6....(a)news.eternal-september.org> Richard <rgrd...(a)gmail.com> writes:
>
> > When discussing vars in computing it is normal to discuss the variables
> > b name.
> > You dont say "if pi is larger than p".You say "if p is larger than
> > pi". You're style is nothing more than fancy for fancy's sake IMO.
>
> No, it does actually do something: it will throw a compile error if you
> mistype == as =.
>
> To demonstrate, imagine that you intended to type this:
>
>   if (x == 7)
>
> But you mistakenly typed this:
>
>   if (x = 7)
>
> This is legal code but will not behave in the way you intended.
>
> But if you had typed it this way:
>
>   if (7 = x)
>
> The compiler will throw an error.

I prefer readability over a marginal technique to reduce bugs.
English is meant to be read left to right, and is how I prefer to read
code, not the Yoda style '7 == x'. If the potential bug really causes
you grief, maybe pass a flag that makes the compiler flag 'x = 7' as
warnings?

> --
> John Gordon                   A is for Amy, who fell down the stairs
> gor...(a)panix.com              B is for Basil, assaulted by bears
>                                 -- Edward Gorey, "The Gashlycrumb Tinies"

From: Keith Thompson on
Vladimir Jovic <vladaspams(a)gmail.com> writes:
> Keith Thompson wrote:
>> Vladimir Jovic <vladaspams(a)gmail.com> writes:
>>> Scott Lurndal wrote:
>>>> I personally place the condition operator at the front, as
>>>> William does, but nested.
>>>>
>>>> if ((pointer1 != NULL)
>>>> && (pointer1->field7 == 0x152)) {
>>>> return;
>>>> }
>>> if ( ( pointer1 =! NULL )
>>> && ( pointer1->field7 = 0x152 ) ) {
>>> return;
>>> }
>>>
>>> ops && ops
>>
>> if ( pointer1 != NULL &&
>> pointer1->field7 == 0x152 )
>> {
>> return;
>> }
>>
[...]
>
> Yes, you missed the point. I prefer this way :
>
> if ( NULL != pointer1 &&
> 0x152 == pointer1->field7 )
> {
> return;
> }
>
> Can save you some debugging time :)

Oh, I see. I noticed the use of "=!" for "!=" and "=" for "==", but
assumed there were unintentional typos.

``pointer1 =! NULL'', of course, parses as ``pointer1 = !NULL''.
``!NULL'' evaluates to 1, and assigning an int value (other than a
null pointer constant) to a pointer object requires a diagnostic.

But yes, I'm familiar with the convention of putting the constant
expression on the left hand side of a comparison operator, and with
all the arguments in favor of it. Personally, I find it ugly.
No offense.

--
Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Casper H.S. Dik on
Keith Thompson <kst-u(a)mib.org> writes:

>``pointer1 =! NULL'', of course, parses as ``pointer1 = !NULL''.
>``!NULL'' evaluates to 1, and assigning an int value (other than a
>null pointer constant) to a pointer object requires a diagnostic.

And for other types the compiler or lint will also create a
diagnostic.

(4) warning: assignment operator "=" found where "==" was expected
(4) warning: constant operand to op: "!"

>But yes, I'm familiar with the convention of putting the constant
>expression on the left hand side of a comparison operator, and with
>all the arguments in favor of it. Personally, I find it ugly.
>No offense.

Same here.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: Rainer Weikusat on
John Gordon <gordon(a)panix.com> writes:
> In <oct467-nu6.ln1(a)news.eternal-september.org> Richard <rgrdev_(a)gmail.com> writes:
>> When discussing vars in computing it is normal to discuss the variables
>> b name.
>
>> You dont say "if pi is larger than p".You say "if p is larger than
>> pi". You're style is nothing more than fancy for fancy's sake IMO.
>
> No, it does actually do something: it will throw a compile error if you
> mistype == as =.
>
> To demonstrate, imagine that you intended to type this:
>
> if (x == 7)
>
> But you mistakenly typed this:
>
> if (x = 7)
>
> This is legal code but will not behave in the way you intended.

It is a bad idea to try to solve social problems with technical
means. The problem behind this is that = in C is a so-called 'false
cognate' for people who are intimately familiar with mathematics, that
is, a term in a foreign language which 'looks' very similar to a
loosely related term in one's mother tongue, but with a (subtly)
different meaning. This means that such people will likely confuse =
and == in C intuitively and have a hard time spotting such an error
since the text 'looks right' according to the set of conventions they
are so used to that they no longer actively think about them.

But this really only means that average people well-versed in
mathematics shouldn't attempt to code in C because they will likely
make basic errors other people wouldn't.
First  |  Prev  |  Next  |  Last
Pages: 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
Prev: integer
Next: shared memory question