Printable View
My question is simple..
so will this code save an integer memory ?
where abcd is a user defined function and returns an integer.Code:printf("%d",abcd());
//compare to-
int a = abcd();
printf("%d",a);
and how do you know it ?
I mean how to understand these fundamentals ?
I have read "Let Us C"
What do you think the answer is?
The reason I ask is that you will learn more by reasoning out an answer for yourself than reading someone else's response. A statement of your understanding is also useful for people who might help you - knowing what you understand, or don't, is useful for tailoring advice to your needs.
i think it doesnt
for supporting my answer-
when we pass a string like this-
abcd("hello");
instead of-
char *str = "hello";
abcd(str);
it still get stored in the memory and the base address is passed.
okae it will stored in stack while function calling but in the 2nd case it will get stored in stack as well as in memory....
now i think it will save memory
Quote:
Originally Posted by grumpy
It likely wont make any difference. The compiler can work out that the second example can be done the same way as the first example.
You need never concern yourself with such trivial changes. Just write whichever is clearer or simpler.
Yes I know that but still i was trying to understand the fundamentals.....Quote:
Originally Posted by iMalc
What you're asking about isn't close to being fundamental. There is nothing between your two cases that prevents a compiler emitting the same code for both - in effect, changing one into the other. And, in fact, modern compilers will probably do so within even unaggressive code optimisation settings. Which one they'll pick .... that depends on the compiler, the host system (since the compiler designer often uses deep knowledge of the target system), and a bunch of other things that run-of-the-mill C programmers don't need to worry about.Quote:
Originally Posted by mannu1200
Fundamentals include being able to write code that behaves as intended without introducing unintended errors, and produces the same outout even when subjected to aggressive optimisation by compilers. That often means the "clearer and simpler" premise (which I would augment with the word "unambiguous") mentioned by iMalc.
Another way to answer this question is to try compiling both versions with your compiler. Try different optimization settings and you'll probably find one that gives exactly the same binary for both programs.Quote:
Originally Posted by mannu1200
Maybe the OP wants to be a compiler writer, guys. If he really did, this would be an important step in the process because to write the optimizations, you need to first understand them.
I don't think this is an optimization. Optimizations carried out by the compiler have to do with what kind of object code is emitted. An example would be "if (!(n%2))" becoming a bitwise and instruction in assembly language rather than a remainder one. I think in order for what exactly the OP wants to be optimized, you would have to do something about function call overhead, which means that things like inline functions matter more than the manner in which the function call was written.Quote:
Maybe the OP wants to be a compiler writer, guys. If he really did, this would be an important step in the process because to write the optimizations, you need to first understand them.
A wrinkle in the truth of the above statement is that the compiler has to be smart enough to realize that you are doing something subject to optimization, and a lot of the time this has to do with the sort of assembler emitted. I don't think you can confuse the compiler by just writing function calls the way that one wants. Still, it probably means resisting the temptation to vomit in your editor:
How many different ways can that go really?Code:foo(bar(baz(quz(arg, barg, harbl, carbl))));
For example, I hate it when some people need to write a math program. Sometimes you end up with one giant expression to solve the problem. It must have been a tricky thing to write thanks to all the operators present. It is also (probably) a tricky to optimize.
I agree. It could be categorised as a premature optimisation though. ;)Quote:
Originally Posted by whiteflags
Possibly more than you might think. It depends on what we assume the various entities are, and what the dependencies are. We would normally assume that foo(), bar(), baz(), and quz() are functions and that arg, barg, harbl, and carbl are expressions, in which case ....Quote:
Originally Posted by whiteflags
Then quz() would notionally be called first, and foo() last - a function's arguments need to be evaluated before a function can be called. The order of evaluation of arg, barg, harbl, and carbl is unspecified. They could be in any sequence. Depending on processor/system features, they could be evaluate sequentially, some of them in parallel to each other, etc.
If the compiler optimisation (or code generation, as you point out) is particularly aggressive, there could be analysis between the various functions. If interprocedural analysis determines, for example, that calling bar() has no net effect, then it might not be called. Similarly, if it is able to be determined that the expression barg is not subsequently used within the various functions, the evaluation of barg might be eliminated entirely.
Then imagine what happens if we assume even one of foo, bar, baz, quz, arg, barg, harbl, and carbl is a preprocessor macro..... The range of possibilities, is endless - including undefined behaviour (for which, by definition, there is an infinite number of possible behaviours).
"Giant" expressions can always be broken down into a set of simpler expressions that produce the intended result. Math programs are no different to any other in that respect. It is only a combination of programmer ego and energy (or sometimes laziness) that leads to large and cryptic expressions. Which brings us back to iMalcs comment about writing clearer and simpler code.Quote:
Originally Posted by whiteflags
There is, unfortunately, no upper bound on the unnecessary complexity that a programmer can introduce into code.