Side effects in conditional expressions

[Ian Collins]

Frankly, I almost never use ++ or -- unless I'm operating on a pointer. x
+= 1; is much clearer and generates the same code as x++; if what you really
are doing is incrementing by 1.

Even for a loop index?

Saving a line of source generally doesn't make the generated code any
better/faster and can make the code less obvious.

Eh?

 

[Seebs]

My point is not so much about the syntax. I'm fine with ++ but the
"problem" in my opinion is when its value is used.

I don't think that's actually a problem. I think it's a risk, in some
cases, but if you use a value and modify it separately, that creates
other risks, such as the two operations being separated.

-s

 

[August Karlstrom]

I don't think that's actually a problem. I think it's a risk, in some
cases, but if you use a value and modify it separately, that creates
other risks, such as the two operations being separated.

Do you have any examples?


/August

 

[Seebs]

Do you have any examples?

The general category of things like
while (*s++ = *t++)
;

Or consider idioms such as:

x = stack[depth++];

If you separate that out, you lose the nice consistency that, no matter
where you are, after each statement, depth points to the next free slot.
If you change that to:
x = stack[depth];
++depth;

you now have a spot where you could insert something using depth where
depth referred to an in-use slot.

-s

 

[August Karlstrom]

The general category of things like
while (*s++ = *t++)
;

I would use or define a function that does this instead of using the
above statement in many places.

Or consider idioms such as:

x = stack[depth++];

If you separate that out, you lose the nice consistency that, no matter
where you are, after each statement, depth points to the next free slot.
If you change that to:
x = stack[depth];
++depth;

you now have a spot where you could insert something using depth where
depth referred to an in-use slot.

Same thing here. I would instead define a pop function.


/August

 

[Tom St Denis]

Note that I would never write this kind of code myself. I wouldn't even
write `x = y++;' but `x = y; y++;'. What I'm trying to find out is
whether there is some common acceptance level among seasoned C
programmers of how convoluted the code is allowed to be.

x = y++;

Is perfectly fine to write. If for example you're walking a buffer and
'y' is your "current index" and "x" is the index of the start of some
header field [for instance].

having side effects in your expressions to : is just considered bad
form as it's hard to read.

Tom

 

[Tom St Denis]

All you're going to get here is "Don't do that!"

So as a regular yourself your position of advocacy is to write
convoluted hard to read programs?

I value your opinion greatly because it seems you have a lot to offer
here [judging by your long standing in the community and prolific
postings].

Tom

 

[Seebs]

I would use or define a function that does this instead of using the
above statement in many places.

I might too -- but I'd write the function that way anyway.

Same thing here. I would instead define a pop function.

Hmm. So I have to then pass the pop function all sorts of data, some
of which it modifies... I'm not sure this is an improvement.

-s

 

[Nick Keighley]

++ always seemed perfectly clear to me. It was one of the things I
liked about C when I first looked into it. I don't see why x += 1 is
clearer.

I don't avoid ++ on non-pointers: often the brevity seems
just right, especially in a common idiom like
    for ( ; Foo; index++)
yet nevertheless I frequently write
    baz += 1
especially when the fact the addend happens to be 1 exactly
seems incidental.

If I was reveiwing your code I'd complain about the magic constant.
I'd prefer

baz += STEP_VALUE;

Wondering whether the coder knows ++x and x+=1 are the same????
Wondering is good, but you might be overdoing it.


So if you happened on an x += 1 in my code, you'll assume
I don't understand C??  

I'll wonder if the 1 could be some other value and why you didn't use
a named constant.

 

[James Dow Allen]

If I was reveiwing your code I'd complain about the magic constant.
I'd prefer
   baz += STEP_VALUE;

baz += 1 conceals a magic constant, but its abbreviation ++baz
is ok?? I'd think you were joking but I see no smiley-face
or such.

I'm just going to walk away, shaking my head ...

James

 

[Edward]

baz += 1 conceals a magic constant, but its abbreviation ++baz
is ok?? I'd think you were joking but I see no smiley-face
or such.

I'm just going to walk away, shaking my head ...

James

If it's ++ it's obviously 1 for the obvious reason (it's an index or
counter, indexing or counting something). Whereas, if it's +=, that
implies that there is something special about the added value - and that
that value might change.
In other words, ++ /is/ symbolic, in a way +=1 isn't.
-Edward

 

[August Karlstrom]

I might too -- but I'd write the function that way anyway.


Hmm. So I have to then pass the pop function all sorts of data, some
of which it modifies... I'm not sure this is an improvement.

You pass it one or two arguments depending on how you have chosen to
structure the program - pop(&x) if the stack is a (one instance)
abstract data structure and pop(stack, &x) if the stack is an abstract
data type.


/August

 

[August Karlstrom]

If it's ++ it's obviously 1 for the obvious reason (it's an index or
counter, indexing or counting something). Whereas, if it's +=, that
implies that there is something special about the added value - and that
that value might change.
In other words, ++ /is/ symbolic, in a way +=1 isn't.

Don't be silly, x++, x += 1 and x = x + 1 are all fine. In most cases
there is nothing "magic" about the integer one.


/August

 

[BartC]

Don't be silly, x++, x += 1 and x = x + 1 are all fine. In most cases
there is nothing "magic" about the integer one.

You can't tell if it's magic or not; maybe it's just '1', or maybe it's
supposed to be N which happens to be 1, and could well change, or be wrong,
or might be linked to another '1' elsewhere and both have to be the same.

 

[Seebs]

baz += 1 conceals a magic constant, but its abbreviation ++baz
is ok?? I'd think you were joking but I see no smiley-face
or such.

Incrementing to walk over an array or similar structure is pretty much
generic and idiomatic. "+= 1", being used instead of the increment
operator, suggests that there is some reason not to increment, such as
a concern that the value 1 might not always be the right choice.

-s

 

[Edward]

Vincenzo Mercuri wrote:

PS: I recall the name of a language...the C++, and never wondered
why they didn't call it C+=1.

Which of course makes arguments about whether C++ is better or worse
than C rather futile... since (C > C++) invokes UB ;-)
-Edward

 

[Willem]

Edward wrote:
) If it's ++ it's obviously 1 for the obvious reason (it's an index or
) counter, indexing or counting something). Whereas, if it's +=, that
) implies that there is something special about the added value - and that
) that value might change.

It only implies that it's special because you would use ++ where that is
not the case. If ++ did not exist, there would be nothing special about
+= 1, and the 1 would not be seen as a magic number.

In other words: you're using a circular argument.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[August Karlstrom]

Edward wrote:
) If it's ++ it's obviously 1 for the obvious reason (it's an index or
) counter, indexing or counting something). Whereas, if it's +=, that
) implies that there is something special about the added value - and that
) that value might change.

It only implies that it's special because you would use ++ where that is
not the case. If ++ did not exist, there would be nothing special about
+= 1, and the 1 would not be seen as a magic number.

Good point.


/August

 

[Keith Thompson]

Edward wrote:
) If it's ++ it's obviously 1 for the obvious reason (it's an index or
) counter, indexing or counting something). Whereas, if it's +=, that
) implies that there is something special about the added value - and that
) that value might change.

It only implies that it's special because you would use ++ where that is
not the case. If ++ did not exist, there would be nothing special about
+= 1, and the 1 would not be seen as a magic number.

Right, in a language that has "+=" but not "++", "x += 1" would be
the idiomatic way to increment x.

In other words: you're using a circular argument.

What's cirular about it? C is not such a language. In C, "++"
is the idiomatic way to increment a variable.

 

[James Dow Allen]

For some of my recent source, I just did
grep "+= 1;" */[a-z]*.c
I was surprised at how many instances there were!
A large number were of the form
csp->cu_probe += 1;
or, in a more extreme example,
Xtab[nix].xnum[strlen(Xtab[nix].xnum) - 1] += 1;

Now, in the vast majority of these cases it would
make no difference whether I use pre-increment or
post-increment. But my tendency is to use
pre-increment in those don't-care cases, partly
because the post-increment is a *special* C op,
and partly because the "++" is more visible at the
*beginning*. Yet in
++foop->next->count;
the "++" is distant from the "count" which is incremented.
Hence my preference here for
foop->next->count += 1;

I hear an objection coming. Why not just sacrifice my
tiny aversion to an unnecessary post-increment and
write
foop->next->count++;
instead of
foop->next->count += 1;

*But that rewrite presupposes that " += 1" is
confusing which, quite frankly, is an opinion
I'd never heard before.*

Redoing my grep to exclude "->" and "[]", I see
I still have numerous instances of "+= 1;" in the code
I surveyed. The first ones that caught my eye
were
argv += 1;
Those of you who process your own args probably do
argv += 2;
a lot, as well as the "+= 1" form. Doesn't it make
the code more elegant and readable to use the "+= N"
consistently, rather than applying an abbreviation
only useful in one case?

And, a question for those of you who thought my
'1's should be defined MAGIC numbers: In the common
case where " argv += 2 " is what's needed, do you
actually use a defined constant rather than 2 ??
If your answer is a sincere Yes, then that's another
style point on which we must agree to disagree.

I confess that there's still plenty of "+= 1"
instances in my code other than the examples just given.
Here's one I coded just a few months ago, for
a card-game simulation:
void giveback(int rank)
{
Deck[rank] += 1;
Sizedeck += 1;
}
Do I expect I may redefine giveback() to give two
cards back at once? Not really. Did I know the
" += 1 " would confuse otherwise-expert C programmers
or that they would prefer
#define NUMBER_OF_CARDS_GIVEN_BACK 1
Definitely not.

Let me appeal to the general audience. Sometimes I
like to present my code into the public domain.
Do I really need to get rid of these "confusing" instances
of " += 1 " ?

Incrementing to walk over an array or similar structure is pretty much
generic and idiomatic.  "+= 1", being used instead of the increment
operator, suggests that there is some reason not to increment, such as
a concern that the value 1 might not always be the right choice.

I just counted my instances of "+= 1". I didn't count "++" but am
rather sure it would be much more common. Anywhere, there are
many *many* things besides array walks where 1 is the standard
increment,
and many array walks where 1 is NOT the increment.

On the topic of understanding or debugging someone else's poorish
code, I've only limited experience but that experience has been
successful. I'm of the opinion that someone looking at an
uncommented "+= 1" and trying to psychoanalyze its hidden
meaning is asking for problems where none exist.

James Dow Allen