Too too confusing~
#include<stdio.h>
void main()
{
int i=10,j=5,k=3;
k=j++ + j++ + j++;
printf("\n%d\n%d",k,j);
j=5;
i=j++ + --j + --j;
printf("%d\n%d\n",i,j);
}
Result is
15
8
9
4
Please help me with its results!! And please explain how!! how is that the value of "i" became 9???
void main()
{
int i=10,j=5,k=3;
k=j++ + j++ + j++;
printf("\n%d\n%d",k,j);
j=5;
i=j++ + --j + --j;
printf("%d\n%d\n",i,j);
}
Result is
15
8
9
4
Please help me with its results!! And please explain how!! how is that the value of "i" became 9???
Last edited on
First of all.
void main() must be replaced with int main() !!!!!
This entire line is ridiculous. It should be removed and things should be done sensibly.
Same story for this line.
void main() must be replaced with int main() !!!!!
|
|
This entire line is ridiculous. It should be removed and things should be done sensibly.
|
|
Same story for this line.
closed account (S6k9GNh0)
You should look into C++ sequence points. Those assignments are undefined because of C++ sequence points.
http://en.wikipedia.org/wiki/Sequence_point
http://en.wikipedia.org/wiki/Sequence_point
Last edited on
What is the point of this program?
One of programming rules, which is really good, is KISS: Keep It Simple Stupid.
Even if it gave you some optimization, think about the headache someone would have after reading this code. If you can make it simpler, make it simpler. This code is just bad.
Cheers!
One of programming rules, which is really good, is KISS: Keep It Simple Stupid.
Even if it gave you some optimization, think about the headache someone would have after reading this code. If you can make it simpler, make it simpler. This code is just bad.
Cheers!
closed account (S6k9GNh0)
Last edited on
computerquip, you didn't understand the KISS rule.
It's obvious that sometimes, you can do many great optimizations that will be fast as hell, but complicated or not clear at the first sight.
And KISS says, these shouldn't be used too much.
It doesn't say, that if you follow KISS you will write the fastest code. But often you don't need to. If you write really slow code, it's bad. But if you try to optimize everything, it's even worse.
Many beginners focus too much on optimizing, because they hear everywhere that code must be fast, optimized, etc. We live in XXI century, we have fast PCs. As Donald Knuth said:
If you can write two lines, either:
or
Write the latter. Your intentions are clear, and you are less likely to make a mistake.
If you are writing some simple game, where you need to sort equipement, don't think too much about all the sorting algorithms - use quicksort. If it is too slow, you will have to change one function, and quicksort is well known, so nobody will have to think about how it sorts.
Sometimes it's better to write a little bit slower code, that is easier to maintain and read.
It's obvious that sometimes, you can do many great optimizations that will be fast as hell, but complicated or not clear at the first sight.
And KISS says, these shouldn't be used too much.
It doesn't say, that if you follow KISS you will write the fastest code. But often you don't need to. If you write really slow code, it's bad. But if you try to optimize everything, it's even worse.
Many beginners focus too much on optimizing, because they hear everywhere that code must be fast, optimized, etc. We live in XXI century, we have fast PCs. As Donald Knuth said:
| Premature optimization is the root of all evil |
If you can write two lines, either:
|
|
or
|
|
Write the latter. Your intentions are clear, and you are less likely to make a mistake.
If you are writing some simple game, where you need to sort equipement, don't think too much about all the sorting algorithms - use quicksort. If it is too slow, you will have to change one function, and quicksort is well known, so nobody will have to think about how it sorts.
Sometimes it's better to write a little bit slower code, that is easier to maintain and read.
Last edited on
closed account (S6k9GNh0)
Those do not do the same thing.
and
The idea of KISS is that usability should be simple, not necessarily implementation. For instance, people who complain about systemd breaking KISS don't understand the whole reason for KISS in correspondence to programming.
Take for example my previous example: sorting algorithms. Regardless of how fast the algorithm is or not, if you want to implement a certain algorithm, it's going to be complicated before we even put text into text editor.
What if 20 years from now, a very complicated algorithm I have trouble grasping now, is child's play then? Is it then okay to declare that KISS and use it more often? There are issues with putting a single philosophy into stone on everything.
and
The idea of KISS is that usability should be simple, not necessarily implementation. For instance, people who complain about systemd breaking KISS don't understand the whole reason for KISS in correspondence to programming.
Take for example my previous example: sorting algorithms. Regardless of how fast the algorithm is or not, if you want to implement a certain algorithm, it's going to be complicated before we even put text into text editor.
What if 20 years from now, a very complicated algorithm I have trouble grasping now, is child's play then? Is it then okay to declare that KISS and use it more often? There are issues with putting a single philosophy into stone on everything.
Last edited on
Got yu ppl..this was a question from an online test i went thru for an exam practice..! I was so confused!!
The above results are not the same in c++
http://ideone.com/hHbBMo
neither are they the same in c
http://ideone.com/NibFXs
http://ideone.com/hHbBMo
neither are they the same in c
http://ideone.com/NibFXs
| Those do not do the same thing. |
But that's what I guess user wanted to achieve. It's obvious that they do not do the same thing, it's not obvious what was his intention, and that's why KISS is used.
As for
What if 20 years from now, a very complicated algorithm I have trouble grasping now, is child's play then? Is it then okay to declare that KISS and use it more often? There are issues with putting a single philosophy into stone on everything. |
Again, you do not understand KISS. KISS does not mean "the easiest algorithms are the fastest" or "use only easy algorithms". KISS means "don't complicate things where they aren't necessary", which is perfectly shown in this example. Look how little this optimization(using operator++ and operator--) mean - it's almost nonexistent. And look how much discussion it caused - he asked on forum about it, nobody knows what was intention of this program. This is where KISS would be recommended.
But if you are participating in space ship program, then you should probably write the fastest algorithms - because you need to have the best performance possible. As for games - because others work with you, you should respect them and their time, and find golden ratio between optimizing and keeping code simple.
All I mean is, don't optimize things where you don't need to. Fast algorithms are sweet, optimized code is great; do it, but remember about readability. Sometimes it's just not worth it. If you just started learning how to create games, don't spend weeks optimizing it, or writing best menu/collision detection/whatever. Simply do your stuff and move on, because in few months/years you will see that you could have done something way more easily or faster. If you are writing "Hello, world!" program, don't think about which is better - std::cout or printf(). Or maybe fetching some assembly code to make it faster. It really does not matter. Programmer should know when to optimize.
And now a bunch of quotes, to fill my response, and hopefully(if you still don't know what I mean), get to you:
| "The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet." |
| "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified" |
Cheers!
Last edited on
closed account (S6k9GNh0)
That's not what I'm even saying. I said regardless of speed. Algorithms by nature are hard to understand and implement. You also seem to be under the impression that one algorithm is the same as another just because it wields the same result.
I'd like you to write an encryption algorithm close to something of RSA and have it be readable just by code.
I'd like you to write an encryption algorithm close to something of RSA and have it be readable just by code.
Last edited on
The thing I said about choosing quicksort over other algorithms comes from premature optimization thing - if you are beginner, and are writing some simple RPG game(because you are learning), you don't need to spend weeks choosing the best working algorithm. If you work at NASA, it's more likely to happen.
However, I do not mean that you should avoid making really fast algorithms - I said that it's great when you do so! Yet, if you are learning how to program, and instead of going on and expanding your knowledge, you try to find the best algorithm - you are doing it wrong. If you are writing code that you can optimize, but it will greatly decrease readability - consider not optimizing it, if it's not worth it.
Of course, you shouldn't use algorithms that are O(n^2) (in)efficient, but you shouldn't make your code a nightmare to read only because you just saved 5 processor instructions.
Algorithms, as you said, are complicated by their very nature; however, I do not mean algorithms; I mean code - and the one in this topic is the best example.
You can't say what was intention of programmer - neither can I - we can only say what output will be. And we don't know if that is demanded output. It would be much simpler, if the guy just used operators + and - and modified 'j' variable later. And that's where KISS should be used.
However, I do not mean that you should avoid making really fast algorithms - I said that it's great when you do so! Yet, if you are learning how to program, and instead of going on and expanding your knowledge, you try to find the best algorithm - you are doing it wrong. If you are writing code that you can optimize, but it will greatly decrease readability - consider not optimizing it, if it's not worth it.
Of course, you shouldn't use algorithms that are O(n^2) (in)efficient, but you shouldn't make your code a nightmare to read only because you just saved 5 processor instructions.
Algorithms, as you said, are complicated by their very nature; however, I do not mean algorithms; I mean code - and the one in this topic is the best example.
You can't say what was intention of programmer - neither can I - we can only say what output will be. And we don't know if that is demanded output. It would be much simpler, if the guy just used operators + and - and modified 'j' variable later. And that's where KISS should be used.
Topic archived. No new replies allowed.