C/C++ inc/decrement operator style

1    09 Jun 2018 23:08 by u/skruf

Sitting here writing some code on a parser, so while writing a counter I needed to write something like

if ... {
    ...
    some_list.clear();
    counter++;
    continue;
}

But, do you think writing it this sort of way is nicer,

    ...
    ++ counter; // With a space after operator
    continue;
}

The thought was, maybe if you have some code around this, it'll stand out more... I don't know. What do you think?

Suppose I should also get some design practises book along with the other two books I am getting next week.

25 comments

0

https://softwareengineering.stackexchange.com/questions/223313/style-guide-for-c

However, it's more important to be consistent. Whatever you go with, be consistent.

0

Consistency is irrelevant when you're talking about two different operators with different semantics though. Use the one you actually need.

0

As long as you're not screwing with the way C performs the action, I don't see why not. In other words: x++ and ++x are two completely different functions.

So, doing x *= ++i will perform:

x = x * (i + 1)

But, doing x *= i++ will act like:

x = (x * i) + 1

Beyond that, style is up to you. Most C-coders (and style guides) won't want whitespace around the variable, or between a variable and increment operator. But, if it's code just for you, who cares?

0

No it won't. The second is equivalent to:

x = x * i;
i = i + 1;

a++ is "read then increment" whereas ++a is "increment then read".

0

Dumbest argument of all time. Both operations are in O(K) time. Who gives a fuck?

0

I prefer to always use the postfix operator. To me it is more important to have easy to read code than succinct code, and I also think the prefix one is uglier, so there's that.

0

But they're different operators, with different semantics......

0

Yes, and?

0

So preference (bikeshedding) has nothing to do with it.

0

I will, given the option, write around using the post-fix operator, as well as use it in trivial examples such as OPs. Preference has everything to do with it, that's entirely what a style guide is based on.

0

Style guides should be based on substantive differences, not trivialities and bikeshedding.

0

Practicality, readability, and - most importantly - consistency are what style guides are based around. What they "should" be based on, in your proposition, is entirely your opinion.

0

I prefer x += 1 for an incrementation statement, as the intent is, IMO clearer. But I'm sure plenty would disagree with me.
I didn't compare the compiler's output for all three syntax, though.

0

This is one of the things I think makes programming interesting, the different styles there is. The most interesting example I think of is Fox-Toolkit's style, the author has an, I may say, interesting style...

0

Just in case you didn't already know, there is actually a difference between counter++ and ++counter, as the first increments after reading the value and the second before reading the value, e.g.:

```js int counter = 0;

printf("%d\n", counter++); // 0 printf("%d\n", ++counter); // 2 ```

Most people use counter++ because of this behavior being closer to the logical alternative of counter += 1.

0

i often see in a for loop (;;++i) or (;;i++) someone suggesting that ++i was better for some reason, any ideas why?

0

Even though modern compilers optimize for either of these uses, I'm sure, the idea was that when post-incrementing (i++), 'i' here will return the value and then increment it, which apparently takes more time than pre-increment (++i) where you would increment and get the new value.

0

Whoever suggested that was a moron. It makes zero difference which of the two you use as the third expression in a for loop. Whenever you see someone prescribing rules without explaining their reasoning, it's a good idea to disregard everything they say.

0

the both are perfect. once they are well utilized properly. normally on hackrypton.com there are so many tutorials that will help in securing things like that easily

0

They both suck because of unspecified behavior in some situations. And usually when you want it least. Like for loops using pointers. Trust me, just say "counter += 1" and you will never have to know the pain

0

The operators have nothing to do with the unspecified behaviour you're talking about though -- they're just a succinct way to trigger it. What's actually undefined is the order of evaluation of function arguments -- which is something you should be aware of even if you never use increment operators.

Not using increment operators is a typical example of "scarring on the first cut". If you're going to write software in C, lazy rules-of-thumb will only get you so far. At some point, you have to read and understand the specification in depth.

0

I take more of a "when in doubt, do it in python" approach because life is just too short to spend on specifications :) But I'm sure you're right

0

Who cares. CoffeeScript took "nice" syntax to it's logical conclusions and ended up with the ugliest and most unreadable language ever created.

0

I suggest you think which the output is going to be and then compile it and run it to see by yourself. Hope i helped a bit


masterseo

0

The post ++ is better than the pre ++. Because if it weren't Stroustrup would have called it ++C and not C++, kappa.