Thread: Do calling method inside printf saves memory?

  1. #1
    Registered User
    Join Date
    Jan 2014
    Posts
    6

    Question Do calling method inside printf saves memory?

    My question is simple..
    so will this code save an integer memory ?

    Code:
    printf("%d",abcd());
    
    
    //compare to-
    
    int a = abcd();
    printf("%d",a);
    where abcd is a user defined function and returns an integer.
    and how do you know it ?
    I mean how to understand these fundamentals ?
    I have read "Let Us C"

  2. #2
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    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.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  3. #3
    Registered User
    Join Date
    Jan 2014
    Posts
    6
    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.

  4. #4
    Registered User
    Join Date
    Jan 2014
    Posts
    6
    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 View Post
    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.

  5. #5
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  6. #6
    Registered User
    Join Date
    Jan 2014
    Posts
    6
    Quote Originally Posted by iMalc View Post
    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.....

  7. #7
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Quote Originally Posted by mannu1200 View Post
    Yes I know that but still i was trying to understand the fundamentals.....
    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.

    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.
    Last edited by grumpy; 01-10-2014 at 01:51 AM. Reason: Fix typo
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  8. #8
    Registered User
    Join Date
    Nov 2012
    Posts
    1,393
    Quote Originally Posted by mannu1200 View Post
    My question is simple..
    so will this code save an integer memory ?

    Code:
    printf("%d",abcd());
    
    
    //compare to-
    
    int a = abcd();
    printf("%d",a);
    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.

  9. #9
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    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.

  10. #10
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    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.

    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:
    Code:
     foo(bar(baz(quz(arg, barg, harbl, carbl))));
    How many different ways can that go really?

    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.
    Last edited by whiteflags; 01-10-2014 at 03:38 PM.

  11. #11
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Quote Originally Posted by whiteflags View Post
    I don't think this is an optimization.
    I agree. It could be categorised as a premature optimisation though.

    Quote Originally Posted by whiteflags View Post
    Still, it probably means resisting the temptation to vomit in your editor:
    Code:
     foo(bar(baz(quz(arg, barg, harbl, carbl))));
    How many different ways can that go really?
    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 ....

    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).

    Quote Originally Posted by whiteflags View Post
    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.
    "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.

    There is, unfortunately, no upper bound on the unnecessary complexity that a programmer can introduce into code.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. calling a method from another file
    By Beowolf in forum C++ Programming
    Replies: 4
    Last Post: 12-02-2007, 10:40 PM
  2. Replies: 6
    Last Post: 08-29-2007, 08:52 PM
  3. Calling a Method from Another Class...
    By Dan17 in forum C++ Programming
    Replies: 2
    Last Post: 02-02-2006, 06:31 PM
  4. printf+gets inside of code
    By tomas.ra in forum C Programming
    Replies: 7
    Last Post: 11-01-2005, 10:58 PM
  5. class method inside cout fails
    By atapi103 in forum C++ Programming
    Replies: 2
    Last Post: 08-24-2003, 11:35 PM

Tags for this Thread