-3
int i=0;
a[i] =3;
i++;

Vs

int i=0;
a[i++]=3;

Is it just a fancy way of writing code and saving lines or you really do improve the performance here?

Sivaramakrishna Shriraam
  • 119
  • 2
  • 13
  • 8
    Do not think in this way. It has no meaning. Compiler optimise both – Jacek Cz May 31 '18 at 12:44
  • both have the same performance. – JAMSHAID May 31 '18 at 12:45
  • Thanks, Could you elaborate more and write as an answer so that I might be able to accept and close it? – Sivaramakrishna Shriraam May 31 '18 at 12:46
  • 4
    *saving lines* A worse than totally useless goal. At best, it does **nothing**. At worst, it makes your code harder to understand. – Andrew Henle May 31 '18 at 12:48
  • I agree with you but seems like a lot of them in the competitive programming are using it to be fast at coding and nothing else I assume. Moreover the MISRA seemed more relevant to me as I belong to the Automotive industry. – Sivaramakrishna Shriraam May 31 '18 at 12:58
  • @AndrewHenle keyboards are expensive :). As less key presses as better. – 0___________ May 31 '18 at 14:37
  • @PeterJ_01 Compare the cost of a keyboard to the cost of merely a single hour of debugging time. Keyboards are **dirt cheap**. – Andrew Henle May 31 '18 at 14:44
  • @AndrewHenle do you know the word "irony". If not: http://www.dictionary.com/browse/irony – 0___________ May 31 '18 at 14:46
  • @PeterJ_01 Irony doesn't come across well in a single line. ;-) And there are way too many readers and posters here who do seem to adhere to the belief that overstuffed and impenetrable code appropriate for the IOCCC is "better". Having spent way too many hours over the years fixing that kind of garbage, I'm not shy about pointing out how horrible and misguided the goal of "saving lines of code" is. – Andrew Henle May 31 '18 at 14:50
  • @AndrewHenle the :) is there for a reason – 0___________ May 31 '18 at 14:51

4 Answers4

4

Using https://godbolt.org/, GCC with optimisations enabled generates the same code for both cases.

main:
  sub rsp, 8
  mov esi, 3
  mov edi, OFFSET FLAT:std::cout
  call std::basic_ostream<char, std::char_traits<char> >::operator<<(int)
  xor eax, eax
  add rsp, 8
  ret
_GLOBAL__sub_I_main:
  sub rsp, 8
  mov edi, OFFSET FLAT:std::__ioinit
  call std::ios_base::Init::Init()
  mov edx, OFFSET FLAT:__dso_handle
  mov esi, OFFSET FLAT:std::__ioinit
  mov edi, OFFSET FLAT:std::ios_base::Init::~Init()
  add rsp, 8
  jmp __cxa_atexit

Note: gcc has optimised std::cout << a[0] to std::cout<<3

Alan Birtles
  • 32,622
  • 4
  • 31
  • 60
1

There's no difference other than a[i++]=3; being more dangerous, since mixing the ++ operators with other operators in the same expression is not a good idea.

See Why are these constructs (using ++) undefined behavior in C? for examples of when this could be dangerous.

Sources: MISRA-C:2012 rule 13.3 et al, see this. The wording in the latest MISRA is that ++ should not be used in an expression with other side effects.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • Could you tell me how will it be a dangerous idea, a scenario where it is dangerous and inefficient? – Sivaramakrishna Shriraam May 31 '18 at 12:47
  • @SivaramakrishnaShriraam `a[i++] = i;` for example. See [Why are these constructs (using ++) undefined behavior in C?](https://stackoverflow.com/questions/949433/why-are-these-constructs-using-undefined-behavior-in-c). – Lundin May 31 '18 at 12:48
  • 1
    This is btw not an opinion-based answer since coding standards like MISRA say the very same thing. – Lundin May 31 '18 at 12:49
  • A downvote without a comment? Given that the [human mind is limited in how much it can track at any one time](https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two), I fail to see how needlessly stuffing as many operations as possible into a single line of code is even defensible. – Andrew Henle May 31 '18 at 12:51
  • Thanks, so many negative votes. Was that a dumb question to ask? – Sivaramakrishna Shriraam May 31 '18 at 12:52
  • While I'm not normally a fan of MISRA they are right on this. It's not inefficient it's just harder to read and maintain as it's not as clear what's happening when. – Mgetz May 31 '18 at 12:52
  • @Lundin Tbf, there are a lot of coding standards that say a lot of things, many of which a debatable. Not that I disagree in this case. – Baum mit Augen May 31 '18 at 12:53
  • @SivaramakrishnaShriraam Not dumb in particular, the people here are just allergic to these kind of micro optimization questions. – Hatted Rooster May 31 '18 at 12:53
  • @SivaramakrishnaShriraam next time I'd suggest [godbolt](https://godbolt.org)ing first – Mgetz May 31 '18 at 12:53
  • @Lundin A coding standard is also an opinion, so just because a standard says x doesn't mean your question is no longer opinion-based. – Hatted Rooster May 31 '18 at 12:54
  • It's worth noting that things like `*ptr++` are quite idiomatic in C, and (to a lesser degree) in C++ as well. It's even an idiom that's explicitly mentioned by the standard (in the requirements of InputIterator and OutputIterator). – Sneftel May 31 '18 at 12:54
  • @ Mgetz could you edit this answer and add the links that you have mentioned along with the link that Lundin has shared "Why are these constructs undefined behavior in c?". I can accept this answer – Sivaramakrishna Shriraam May 31 '18 at 12:55
  • @SivaramakrishnaShriraam it's not my answer I think that would be best left to Lundin – Mgetz May 31 '18 at 12:59
  • 1
    @SombreroChicken A well-known coding standards like MISRA or CERT is an authoritative source, since they are industry de facto (and I believe in CERT:s case also IEC standard). Had I been pointing at the Linux kernel coding standard or similar "garage-hacker" document, then sure, that's not authoritative. – Lundin May 31 '18 at 13:03
  • @SivaramakrishnaShriraam Updated with the link and some sources. – Lundin May 31 '18 at 13:07
1

Both segments of code, on their own, would have negligible differences in performance. In practice, both formats would probably be optimized out to the same performance level by the compiler. Placing both inside a loop where i goes from 0 to a million, the difference in runtime was a few ms that averaged out to be negligible.

Amanda
  • 314
  • 3
  • 12
-2

In theory (taking the code at face value with a very naive compiler) the second snippet is faster because of multiple reads to i in the first one..

BUT having said that, in practice it's always 100% the same as the compiler will always optimise both out.

Side note: Stop thinking about these micro optimisations and let the compiler figure it out.

Hatted Rooster
  • 35,759
  • 6
  • 62
  • 122