need help..

**Martin Ambuhl** · Nov 14 '05, 08:55 PM

Re: need help..

slickn_sly wrote:
[color=blue]
> line = 1;
> while( !feof( infile ) )[/color]
^^^^^^^^^^^^^^^ ^^^^^^^^^
This is a mistake; check the FAQ, your C textbook, or any of a large
number of previous threads for details.[color=blue]
> {
> if( line = 2 )[/color]
^^^^^^^^^^^^
This, and all subsequent conditions like it, are almost certainly a
mistake. '=' is the assignment operator; '==' is the equality
comparison operatior.

**CBFalconer** · Nov 14 '05, 08:55 PM

Re: need help..

Martin Ambuhl wrote:[color=blue]
> slickn_sly wrote:
>[/color]
.... snip ...[color=blue]
>[color=green]
>> {
>> if( line = 2 )[/color]
> ^^^^^^^^^^^^
> This, and all subsequent conditions like it, are almost certainly
> a mistake. '=' is the assignment operator; '==' is the equality
> comparison operatior.[/color]

Which you can easily avoid at all times by simply cultivating the
habit of writing:

if (2 == line) ...

i.e. put the constant first.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

**Allan Bruce** · Nov 14 '05, 08:55 PM

Re: need help..

"CBFalconer " <cbfalconer@yah oo.com> wrote in message
news:424BD8A4.9 303B5B1@yahoo.c om...[color=blue]
> Martin Ambuhl wrote:[color=green]
>> slickn_sly wrote:
>>[/color]
> ... snip ...[color=green]
>>[color=darkred]
>>> {
>>> if( line = 2 )[/color]
>> ^^^^^^^^^^^^
>> This, and all subsequent conditions like it, are almost certainly
>> a mistake. '=' is the assignment operator; '==' is the equality
>> comparison operatior.[/color]
>
> Which you can easily avoid at all times by simply cultivating the
> habit of writing:
>
> if (2 == line) ...
>
> i.e. put the constant first.
>[/color]

Or since the OP is using multiple constants, a neater approach would be to
use a switch() statement.
Allan

**Christopher Benson-Manica** · Nov 14 '05, 08:55 PM

Re: need help..

dot@dot.dot spoke thus:
[color=blue]
> while( !feof( infile ) )[/color]

Question 12.2

http://www.eskimo.com/~scs/C-faq/q12.2.html

(Martin already pointed this out to OP.)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

**Peteris Krumins** · Nov 14 '05, 08:56 PM

Re: need help..

CBFalconer wrote:[color=blue]
> Martin Ambuhl wrote:[color=green]
> > slickn_sly wrote:
> >
> > if( line = 2 )
> > ^^^^^^^^^^^^[/color]
>
> Which you can easily avoid at all times by simply cultivating the
> habit of writing:
>
> if (2 == line) ...
>
> i.e. put the constant first.
>[/color]

Which you can as easily avoid at all times without any cultivation
by letting the compiler warn you.

P.Krumins

**Nils Weller** · Nov 14 '05, 08:56 PM

Re: need help..

In article <424BD8A4.9303B 5B1@yahoo.com>, CBFalconer wrote:[color=blue]
> Martin Ambuhl wrote:[color=green]
>> slickn_sly wrote:
>>[/color]
> ... snip ...[color=green]
>>[color=darkred]
>>> {
>>> if( line = 2 )[/color]
>> ^^^^^^^^^^^^
>> This, and all subsequent conditions like it, are almost certainly
>> a mistake. '=' is the assignment operator; '==' is the equality
>> comparison operatior.[/color]
>
> Which you can easily avoid at all times by simply cultivating the
> habit of writing:
>
> if (2 == line) ...
>
> i.e. put the constant first.[/color]

I don't like this habit for various reasons:

1) Though the reversed version is semantically equivalent, it is harder
to read unless you are already quite used to reversing the test. The
vast majority of programmers always puts the variable they want to test
first, i.e. they write

if (foo == 0) {

The few who write

if (0 == foo) {

.... are extremely likely to do so only because they want to avoid the
comparison vs. assignment problem. (If any of the c.l.c regulars started
to use the latter version for reasons other than the mixed up operators
thing, please stand up.)

This is evidence enough that the former version is more natural, and it
follows that the latter is harder to read and understand, regardless of
the fact that it means the same thing. The fact that writing ``0 ==
foo'' is generally considered to be a programming trick is additional
evidence that it is NOT the natural way to code this.

2) If you can remember to reverse the check every time, you also ought
to be able to remember simply to use ``=='' whenever you mean ``=='',
which would save you the trouble of making your code less readable.
The reversal also only makes any sense for C beginners; Sooner or
later you *will* get used to its equality operator, and the reversed
test only serves the purpose of decreasing code readability anymore.

3) Quality compilers warn about the ``if (foo = 0)'' construct. I know
for a fact only that gcc and HP's compilers do this (and not because the
bug ever occured to me, but because I explictly tested these compilers),
but it is very likely that the offerings of vendors such as Comeau,
Compaq, Intel, SGI, IBM, Sun and a host of others are also capable of
doing this (I don't have these compilers handy right now and will let
others fill in the blanks.)

4) It is not even a reliable way to avoid the problem because it works
well only for constants!

if (foo = bar) {

and

if (bar = foo) {

.... both silently produce (probably) incorrect results (modulo corner
cases like the operand on the left-hand side being ``const''-qualified.)

(It will probably take me a couple of days to reply to any followups -
should I consider them interesting enough to reply - because the free
access to my newsserver is being terminated and I haven't yet registered
a commercial account.)

--
My real email address is ``nils<at>gnuli nux<dot>nl''

**CBFalconer** · Nov 14 '05, 08:56 PM

Re: need help..

Nils Weller wrote:[color=blue]
> CBFalconer wrote:
>[/color]
.... snip ...[color=blue][color=green]
>>
>> Which you can easily avoid at all times by simply cultivating the
>> habit of writing:
>>
>> if (2 == line) ...
>>
>> i.e. put the constant first.[/color]
>
> I don't like this habit for various reasons:
>
> 1) Though the reversed version is semantically equivalent, it is harder
> to read unless you are already quite used to reversing the test. The
> vast majority of programmers always puts the variable they want to test
> first, i.e. they write
>
> if (foo == 0) {
>
> The few who write
>
> if (0 == foo) {
>[/color]
.... snip ...[color=blue]
>
> 3) Quality compilers warn about the ``if (foo = 0)'' construct. I know
> for a fact only that gcc and HP's compilers do this (and not because the
> bug ever occured to me, but because I explictly tested these compilers),
> but it is very likely that the offerings of vendors such as Comeau,
> Compaq, Intel, SGI, IBM, Sun and a host of others are also capable of
> doing this (I don't have these compilers handy right now and will let
> others fill in the blanks.)[/color]

And I dislike that warning. I often want to write something like:

if (!(p = malloc(sizeof *p))) getoutahere("no memory");
else if (!(p->ptr = malloc(sizeof *p->ptr))) {
free(p); getoutahere("no memory");
}
else {
/* all seems well, go for it */
}
/* Unless getoutahere does something, we always get here */

and similar things to do with opening files, getting parameters,
etc.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

**Chris Croughton** · Nov 14 '05, 08:58 PM

Re: need help..

On Thu, 31 Mar 2005 23:43:41 GMT, CBFalconer
<cbfalconer@yah oo.com> wrote:
[color=blue]
> Nils Weller wrote:[color=green]
>>
>> 3) Quality compilers warn about the ``if (foo = 0)'' construct. I know
>> for a fact only that gcc and HP's compilers do this (and not because the
>> bug ever occured to me, but because I explictly tested these compilers),
>> but it is very likely that the offerings of vendors such as Comeau,
>> Compaq, Intel, SGI, IBM, Sun and a host of others are also capable of
>> doing this (I don't have these compilers handy right now and will let
>> others fill in the blanks.)[/color]
>
> And I dislike that warning. I often want to write something like:
>
> if (!(p = malloc(sizeof *p))) getoutahere("no memory");
> else if (!(p->ptr = malloc(sizeof *p->ptr))) {
> free(p); getoutahere("no memory");
> }
> else {
> /* all seems well, go for it */
> }
> /* Unless getoutahere does something, we always get here */
>
> and similar things to do with opening files, getting parameters,
> etc.[/color]

Quality compilers (GCC derived ones, for example) note the extra
parentheses around the assignment and don't produce the warning:

if (p = q) ... /* warning */
if ((p = q)) ... /* no warning */
if (!(p = q)) ... /* no warning */

The first could be a mistake, the second and third are likely to be
intentional.

Although I prefer the clearer:

p = q;
if (p) ...

in most cases (idioms with for and while loops and inputting data are
about the only times I use the contraction, I don't do it in an if
test).

Chris C

**Keith Thompson** · Nov 14 '05, 08:59 PM

Re: need help..

dot@dot.dot writes:[color=blue]
> On 31 Mar 2005 21:59:13 GMT, Nils Weller <me@privacy.net > wrote:[/color]
[...][color=blue]
> Easy solution...
>
> #define is ==
>
> int x = 10;
>
> if (x is 10)
> puts("it worked");[/color]

That will make your code difficult to read. Do you actually do this
yourself?
[color=blue][color=green]
>>3) Quality compilers warn about the ``if (foo = 0)'' construct.[/color]
>
> It should be a syntax error.[/color]

In a different language, sure. In C, an assignment is an expression
that yields the value assigned; changing that would break too much
existing code.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

**CBFalconer** · Nov 14 '05, 08:59 PM

Re: need help..

dot@dot.dot wrote:[color=blue]
> Keith Thompson <kst-u@mib.org> wrote:
>[color=green][color=darkred]
>>>> 3) Quality compilers warn about the ``if (foo = 0)'' construct.
>>>
>>> It should be a syntax error.[/color]
>>
>> In a different language, sure. In C, an assignment is an
>> expression that yields the value assigned; changing that would
>> break too much existing code.[/color]
>
> If the compiler can detect it sufficiently to warn, it can hand
> out an error, stop compilation and force you to fix it. And how
> many perfectly good programs have come crashing down over this
> one simple error? Even worse when comparisons ( < and > ) are
> single characters... it's confusing.[/color]

Except now you are using 'not C'. The value of an assignment is
often useful, as in:

if (err = setupphase(1)) bitchabout(1, err);
else if (err = setupphase(2)) bitchabout(2, err);
else if (err = setupphase(3)) bitchabout(3, err);
else {
/* The sun is out and the birds are singing */
}
/* And we always get here, possibly with err set */

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt >
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware. com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)

**Christopher Benson-Manica** · Nov 14 '05, 08:59 PM

Re: need help..

CBFalconer <cbfalconer@yah oo.com> spoke thus:
[color=blue]
> Except now you are using 'not C'. The value of an assignment is
> often useful, as in:[/color]
[color=blue]
> if (err = setupphase(1)) bitchabout(1, err);[/color]

Yes, that's very convenient, although my implementation at least will
generate a warning. I don't know if gcc does, and I wonder whether
lint and friends will complain.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

**Keith Thompson** · Nov 14 '05, 08:59 PM

Re: need help..

dot@dot.dot writes:[color=blue]
> On Sat, 02 Apr 2005 20:00:39 GMT, Keith Thompson <kst-u@mib.org> wrote:
>[color=green][color=darkred]
>>>>3) Quality compilers warn about the ``if (foo = 0)'' construct.
>>>
>>> It should be a syntax error.[/color][/color][/color]

Please don't snip nested attributions.
[color=blue][color=green]
>>In a different language, sure. In C, an assignment is an expression
>>that yields the value assigned; changing that would break too much
>>existing code.[/color]
>
> If the compiler can detect it sufficiently to warn, it can hand out an
> error, stop compilation and force you to fix it. And how many perfectly
> good programs have come crashing down over this one simple error? Even
> worse when comparisons ( < and > ) are single characters... it's confusing.[/color]

You can't make "=" not yield a value without breaking existing
programs. Making an assignment invalid in a condition but valid
elsewhere would be an ugly wart.

I don't find the fact that '<' and '>' are single characters confusing
at all. They match mathematical notation.
[color=blue]
> Frankly, it would have made more sense to have the testing done on a single
> =, & or | marks and use the doubles for assignment along with >> and <<
> which are used for bit shifts.
>
> Think about it... 1 letter: compare, 2 letters: perform an operation. (or
> visa versa) It would be totally consistent. As it is now the rule is 1
> letter does an operation EXCEPT for bit shifts, 2 letters does a test EXCEPT
> for less and greater. It's inconsistent and when learning I found it
> confusing as all get out.[/color]

I've never assumed that the number of characters in an operator has
any significance. I just learned what each one means.
[color=blue]
> So I have a little header I use with a bunch of defines...
>
> #define is ==
> #define lt <
> #define gt >
> #define ne !=
> #define or ||
> #define and &&
> #define shiftl <<
> #define shiftr >>
> etc.
>
> Gives me syntax like this:
>
> if (x and (y lt 7))
>
> if ((x lt y) or (y is 7))
>
> No more silly mistakes.[/color]

If I were going to do something like that, I'd use "eq" rather than
"is" for equality. (Some languages distinguish between equality and
identity, and use "is" for the latter.) I'd also use the symbols in
<iso646.h> whenever possible, and try to be consistent with them
otherwise.

But I'd much rather just learn the language and use it. If I'm going
to read your code, I have to undertand the language *and* the macros
you've chosen. For this:

if (x && (y < 7))

if ((x < y) || (y == 7))

I just have to know the language.

You can use your macros if you like, but I guarantee they'll make it
more difficult for anyone else to read or maintain your code.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

**Keith Thompson** · Nov 14 '05, 08:59 PM

Re: need help..

dot@dot.dot writes:[color=blue]
> On Sat, 02 Apr 2005 22:44:02 GMT, CBFalconer <cbfalconer@yah oo.com> wrote:[color=green]
>>Except now you are using 'not C'. The value of an assignment is
>>often useful, as in:
>>
>> if (err = setupphase(1)) bitchabout(1, err);
>> else if (err = setupphase(2)) bitchabout(2, err);
>> else if (err = setupphase(3)) bitchabout(3, err);
>> else {[/color]
>
> In which case I use assignment, not tests to get the job done.
>
> So, exactly what's the problem?[/color]

The problem is that you would make the above valid code illegal. The
alternative would be significantly more verbose. I suppose you could
do this:

if (err = setupphase(1), err) bitchabout(1, err);
else if (err = setupphase(2), err) bitchabout(2, err);
else if (err = setupphase(3), err) bitchabout(3, err);
else {

but frankly I find the first form clearer.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

**Lew Pitcher** · Nov 14 '05, 08:59 PM

Re: need help..

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dot@dot.dot wrote:[color=blue]
> On Sat, 02 Apr 2005 20:00:39 GMT, Keith Thompson <kst-u@mib.org> wrote:
>
>[color=green][color=darkred]
>>>>3) Quality compilers warn about the ``if (foo = 0)'' construct.
>>>
>>>It should be a syntax error.[/color]
>>
>>In a different language, sure. In C, an assignment is an expression
>>that yields the value assigned; changing that would break too much
>>existing code.[/color]
>
>
> If the compiler can detect it sufficiently to warn, it can hand out an
> error, stop compilation and force you to fix it.[/color]

Sorry, but while it might warrant a "suspicious construct" type warning from
the compiler, that code model certainly isn't /broken/, and doesn't warrant an
error that stops compilation.

Consider this fragment...

if (c = Get_Users_Choic e()) printf("The user chose %c\n",c);

If, for instance, while developing or debugging this fragment, the programmer
decided to 'stub' the Get_Users_Choic e() function with
#define Get_Users_Choic e() 'N'
then the compilation would generate (after macro expansion)

if (c = 'N') printf("The user chose %c\n",c);

While this is not a /usefull/ code construct (from the point of view of
offering the intended variety of values to c), it is a /necessary/ and /legal/
construct.
[color=blue]
> And how many perfectly
> good programs have come crashing down over this one simple error?[/color]

Probably fewer than those that come crashing down on off-by-one errors or
subscript_out_o f_bounds errors.
[color=blue]
> Even
> worse when comparisons ( < and > ) are single characters... it's confusing.[/color]

To you, perhaps, but not to a professional (or even an experienced amateur)
programmer.
[color=blue]
> Frankly, it would have made more sense to have the testing done on a single
> =, & or | marks and use the doubles for assignment along with >> and <<
> which are used for bit shifts.[/color]

That's your opinion. You are welcome to move to that language, what ever it
is. It isn't C, though.
[color=blue]
> Think about it... 1 letter: compare, 2 letters: perform an operation. (or
> visa versa) It would be totally consistent. As it is now the rule is 1
> letter does an operation EXCEPT for bit shifts, 2 letters does a test EXCEPT
> for less and greater. It's inconsistent and when learning I found it
> confusing as all get out.[/color]

You get confused easily, I see.
[color=blue]
> So I have a little header I use with a bunch of defines...
>
> #define is ==
> #define lt <
> #define gt >
> #define ne !=
> #define or ||
> #define and &&
> #define shiftl <<
> #define shiftr >>[/color]

Reminds me of the poster a decade back or so who posted macros that made C
look "pascal-like". Macros of the sort of
#define BEGIN {
#define END }

Just as useless, too.

- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCTzVBagV FX4UWr64RApm9AK CnGeb8ZsGsPEIWs kwzmzvvY19JHQCg 6ibw
rtB1GuiKvbYFKei 8WlKQUZI=
=OYZX
-----END PGP SIGNATURE-----

need help..

need help..

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment