which is faster: i=i+2 or i+=2? [closed] - c

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Consider the below code snippet:
for(i=0;i<10;i+=2) // 1
for(i=0;i<2;i=i+2) // 2
Which one will be better to use?
Does it make any difference in the performance?

The following took 0.0260015 seconds
for (i = 0 ; i < 10000000 ; i += 2)
And this took 0.0170010
for (i = 0 ; i < 10000000 ; i = i + 2)
#MasterID is right though when I enabled 'optimize code' both reported 0.0150009 seconds

There is no definite answer to your question. It depends on how smart your compiler is among other things (optimization level, ...) and on the target platform. This is not a C language question. The language is not more or less performant by itself. It just depends on what the compiler builds out of it. So test it for your use case if performance matters at all...
Otherwise my advice, just write it in the way you feel it more readable.

The first option is as fast as the second, at least.
Although any compilation optimization would generate the same assembly code.

Both express the exact same semantics, i.e. the exact same effect in the abstract machine of the C language. If one is slower than the other, it's a quality-of-implementation flaw in your compiler.

Related

Why is the "FILE" data type in C not simply written as "file"? [duplicate]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
This just seems odd to me, most other things are lower case.
Is there some historical reason?
It's a macro. Macros have historically had all caps in C. Unfortunately recent trends appear to have broken that fact.
Small history lesson: Also, FILE was an io buffer abstraction in UNIX v7 libc stdio. A FILE doesn't necessarily represent a physical file, just something that can do block IO. Source:
http://www.bsdlover.cn/study/UnixTree/V7/usr/include/stdio.h.html
"file" was already defined by the kernel as well:
http://www.bsdlover.cn/study/UnixTree/V7/usr/include/sys/file.h.html
As someone else said here it's probably a typedef now, but I don't think C had typedefs back in '79 as it only just had structs. Then again I wasn't born then so... :)
It's all caps almost certainly because at least originally it was a macro. Nowadays, chances are pretty good that it's a typedef instead, but nobody changed the name to boot (and doing so would be a pretty lousy idea).

If statement and sequential execution [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have a very short (and pretty much noob) question. I have a function that includes:
void function(int x)
{
x = 3;
if (x == 4)
printf("HI!");
x = 4;
}
Will the word HI! be printed? In other words, is a C program read sequentially or not?
Thanks a lot!
No, the code compiles to a sequence of instructions which happen sequentially one after the other. The comparison to 4 will always before the assignment x = 4. So it will be false.
This type of order is guaranteed when you are dealing with a single thread. When you have multiple threads you can get strange results and race-conditions unless you are careful.
It will not be printed. The line above is what matters of course.

C if else condition [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In C if i have only one line in the if condition then can i combine it into one line to reduce the size of code. The size of code is long so I intend to take this step to reduce size of code. Should I should I not? Is it a good programming practice?
It makes no sense to be concerned about the size of the sources at the point of sacrificing readability, especially since sources are extremely small compared to almost any kind of other data that our computers usually process/store (e.g. the bzipped sourced of the Whole Firefox are 85 MB - smaller than any medium-length video). Also, omitting a newline won't change the compilation times of a millisecond.
So, if you prefer one-line ifs for your own stylistic reasons it's fine (although it's often frowned upon), but for saving a few bytes it makes no sense at all.
Actually if the code is long then it's not good programming practice as that code will not be as readable.
so it's better to use if else syntax to make your code readable

Why is FILE all-caps as in FILE*? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
This just seems odd to me, most other things are lower case.
Is there some historical reason?
It's a macro. Macros have historically had all caps in C. Unfortunately recent trends appear to have broken that fact.
Small history lesson: Also, FILE was an io buffer abstraction in UNIX v7 libc stdio. A FILE doesn't necessarily represent a physical file, just something that can do block IO. Source:
http://www.bsdlover.cn/study/UnixTree/V7/usr/include/stdio.h.html
"file" was already defined by the kernel as well:
http://www.bsdlover.cn/study/UnixTree/V7/usr/include/sys/file.h.html
As someone else said here it's probably a typedef now, but I don't think C had typedefs back in '79 as it only just had structs. Then again I wasn't born then so... :)
It's all caps almost certainly because at least originally it was a macro. Nowadays, chances are pretty good that it's a typedef instead, but nobody changed the name to boot (and doing so would be a pretty lousy idea).

How do you prefer between &cycle->read_events[i] and cycle->read_events+i [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
&cycle->read_events[i]
cycle->read_events+i
They are the same,how do you prefer one to the other?
Assuming cycle->read_events is a pointer or array, they are identical within the language and will compile identically.
However, I prefer &cycle->read_events[i], because someday you might decide to port to C++ and use a vector or other container class. Such classes are more likely to have a [] operator than to implement + as "pointer arithmetic". So this way makes it easier to change the data type without needing a recompile.
(Personally, I also find &a[x] to be more expressive of intent than a+x, but that is purely a matter of taste.)
According to The Elements of C Programming Style,
14.1 Use a[b] instead of *(a+b)
14.2 In general, use *a instead of a[0]
14.3 In general, use a+b instead of &a[b]
The rationales for each of these rules are roughly the same: it's shorter and usually clearer.

Resources