It should be ++C because with C++ the value you get from the expression is the old one.
If you're asking why people use pre-increment by default instead of post-increment, it's mostly historical. The early C compilers on resource-constrained platforms such as early DOS were not good at optimization; on those, pre-increment would be reliably translated to a simple ADD or INC, whereas code for post-increment might generate an extra copy even if it wasn't actually used.
For C++ this was even worse with iterators, because now it depended on the compiler's ability to inline its implementation of postfix ++, and then prove that all the copies produced by that implementation have no side effects to optimize it to the same degree as prefix ++ could. Depending on the type of the underlying value, this may not even be possible in general.
The other reason is that all other unary operators in C are prefix rather than postfix, and mixing unary prefix with unary postfix in a single expression produces code that is easy to misunderstand. E.g. *p++ is *(p++), not (*p)++, even though the latter feels more natural, reading it left-to-right as usual. OTOH *++p vs ++*p is unambiguous.
K&R seems to use pre-increment early on, then post-increment consistently (or a lot, anyway, I haven't done a thorough check) after chapter 3, in situations where either would do. In fact, after introducing post-increment at 2.8.
The PDP-11 that C originally targeted had address modes to support the stack. Pre-increment and post-decrement therefore did not require a separate instruction; they were free. After the PDP-11 went the way of the dodo, both forms took a machine cycle so it (mostly) became a stylistic issue. (The two operators have different semantics, but the trend to avoid side-effects in expressions means that both are most often used in a single expression statement like "++x;" or "x++;", so it comes down to your preferred style.)
memcpy etc also take the destination as their first argument, and it mirrors the usual way we write assignments. Personally I always found Intel syntax to be more straightforward, but I think it's ultimately down to whatever one was exposed to first.
I wonder sometimes why we keep insisting on the "OP ARG, ARG" format in general for assembly. Why not something like `MOV X -> Y` that would make it absolutely clear and unambiguous? For that matter, why not `COPY X -> Y`, since that's what it actually does?
I rarely use pre-increment tbh, but post-increment all the time for array indices (since typically the array should be indexed with the value before the increment happens).
If the pre- or post-increment behaviour isn't actually needed, I prefer `x += 1` though.
People seem to mostly write a typical for loop ending with ; ++i){
But I write ; i++){ and seeing it the other way round throws me off for a minute, because I think, as you put it, why would you use those very particular semantics?
In C++ the semantics can differ, in that copying an object for post-increment might require a memory allocation internally (for example in the case of a BigInt class), which may fail and throw an exception. For consistency, using pre-increment by default and unless you really need post-increment, is a good habit.
> why would you use those very particular semantics?
The difference is that i++ has to keep a copy to the original around as the return value is the pre-increment value, while with ++i that isn't needed as the resulting value is being returned.
In the for loop that shouldn't matter as a) for an integer it is essentially for free (it is just reordering when the relevant register is set) and b) that value is hopefully optimized out anyways by the compiler, however as there are cases where it matters some people prefer the ++i style, some just think it looks better.
I've seen either style, but it the argument about which is proper is pointless. Any modern compiler will optimize either equally well, unless you're doing something that actually depends on the order of the increment.
No, for fundamental datatypes pre/post-increment doesn't matter, but for classes that overload those operators, the postfix form creates a temporary object hence people write
Why use this operator? Like most C and C++ features the main reason tends to be showing off, you learned a thing (in this case that there are four extra operators here) and so you show off by using it even if it doesn't make the software easier to understand.
This is not one of those beginner -> journeyman -> expert cycles where coincidentally the way you wrote it as a beginner is identical to how an expert writes it but for a very different reason. I'd expect experts are very comfortable writing either { x = k; k += 1; } or { k += 1; x = k; } depending on which they meant and don't feel an itch to re-write these as { x = k++; } and { x = ++k; } respectively.
I'm slightly surprised none of the joke languages add equally frivolous operators. a%% to set a to the remainder after dividing a by 10, or b** to set b as two to the power b or some other silliness.
Note that in your example there appear to be three distinct meanings:
1. prefix incr/decr precedence: "stack[--sp]"
2. postfix incr/decr precedence: "s[j++]"
3. i have no particular preference for the precedence and am just using a shorthand I inherited from my ancestors whose use cases are no longer relevant to me: "i++" in your for loop
My rank speculation is that C programmers get in a habit of #3 and then forget to consider precedence in an expression where it matters.
In any case, it would be interesting to do a scan of github to see how often prefix and suffix incr/decr had to get switched up in a bugfix patch.
Kernighan spends a page whittling strcpy down to just that, with various intermediate versions. After showing you that version, he describes it like this:
Although this may seem cryptic at first sight, the notational convenience is considerable, and the idiom should be mastered, because you will see it frequently in C programs.
Anyone who calls this election fair is not impartial. The scale of the fraud is enormous and undeniable.
Tell me, how many Venezuelans abroad were able to vote? How many were kept out of the country because the borders were closed? How many were threatened or intimidated into voting for Maduro? How many votes were cast using false ID? How many were confused by the ballot which had 13 options to vote for Maduro? How many polling stations were closed at the last minute?
It certainly is, and I would imagine letting the children chained up in your sweatshop go would be bad for business too. On the bright side, their eyes won't be adjusted to the sunlight, so they won't get very far.
Yes, you can frame this as "bad for business". Contrary to what all the armchair economists online will say, you should never just do what's good for business. If we did we would be seeing crimes against humanity. And we do, just not here.
Its always a balancing act. Often what's good for business isn't good, and what's bad for business isn't bad. You need more robust reasoning than that. Because if that's all you're relying on to form your opinions, you have no substance.
My point is that "bad for business" on its own doesn't really mean much. Often people can't see the holes in their arguments or beliefs. But when you enlarge the view and take it to its logical conclusion, the holes become obvious.
And my point is that a store deciding to unionize could negatively impact the business. Calling for the death of the company, and inciting images of child slaves in chains is not an argument against that. It's an appeal to emotion.
It's not an appeal to emotions, it's a logical argument.
You're saying "well okay it could negatively impact business".
I'm replying "that doesn't mean anything, and sometimes negatively impacting business is very good".
It's not enough to just say something. You need to explain WHY. So what? Who cares? If you don't answer that, I'm sorry, you don't have an argument and anyone wise would choose to not listen to you.
It's bad for business. Okay let's assume that's true. So what? What's the big idea? What's the cost versus the benefit?
There is if your goal is to attract a wider audience. Call me old fashioned, but if you can't even be bothered to capitalize the first letter of each sentence in your publication, I'm probably not going to read it.
Not everybody is trying to attract a wider audience. Some people just want to say what's on their mind without worrying about that stuff. That's one of the beautiful things about personal websites. They're personal.
It's perfectly fine if the style puts you off. You're not wrong for having your own tastes. You're just not the audience for that particular site. Nobody can please everybody.
It's my right to greet guests to my house by singing Don't Stop Believing by Journey flat and terribly off-key. If they complain, I'll tell them it's not that I'm a bad singer, they just aren't my target audience!
This is precisely correct. There's nothing wrong with doing that, and there's nothing wrong with some people deciding they don't want to visit as a result.
> if you can't even be bothered to capitalize the first letter of each sentence in your publication
I suspect this is actually more interesting than base sloppiness.
My first experience with instant messaging was on ICQ (and IRC a year or two later once my Internet usage wasn’t being billed by the minute), and to this day I don’t capitalize or end single-sentence replies with a period in IM situations. The no-period thing is mostly universal—I believe I’ve seen an article in a linguistics journal about how a final period “feels aggressive”—, but I’ve noticed people who learned on smartphones using keyboards with automatic capitalization do, which just looks unnatural to me.
So if someone writes a blog post not as an article, but as a monologue in this kind of conversational style, I can see how they could come to not capitalize and use newlines as sentence breaks. I believe that style is (was?) somewhat popular on Tumblr? I’m honestly a bit surprised it wasn’t more popular on Twitter before the 140-character was lifted.
I’ve heard that communication over IM is actually linguistically interesting (the whole thing, of course, not the punctuation)—in most ways it works like a spoken (or signed) conversation, except it’s expressed in writing. So it’s not entirely unexpected that it can develop conventions that are unlike that of the normal written word. And despite the thousands of years people have been using writing, there isn’t really precedent for this kind of thing before computers.
(I’m also not convinced anything good comes out of trying to attract a generically wider audience.)
It is incredibly frustrating to realize that a lot of companies are within their right to deny you service as soon as you even _appear_ to pose a risk to them.
Geico recently denied my renewal of insurance because they said their underwriters received notification that I use my vehicle for business. (I don't.) I have spent hours trying to explain to them that this is a mistake, but they have zero interest in providing me with insurance. I've heard this is common for people in CA.
I'm not sure what legal recourse the people in this story have. Hopefully they have a legal right to at least download an archive of their data so they can recover old emails, attachments, photos, etc.
Well, this fixed it. I bet there is a lot of confusion for the people reporting it just works, while their phone is on silent. Seems to work on silent if you have headphones on.
Having thought about it, it makes sense for the web browser. Though I think the app should do something to bypass it, but I realize it is probably just a browser embed.
I peeked at the source code and it’s pretty wild to see this is what JavaScript can do these day.
