[ACCEPTED]-C: Return value via stack/register question-calling-convention

The way that the return value is passed 43 to the caller is part of the function calling 42 conventions as well. See here.

For example, regarding 41 cdecl:

The cdecl calling convention is used by many 40 C systems for the x86 architecture. In 39 cdecl, function parameters are pushed on the 38 stack in a right-to-left order. Function 37 return values are returned in the EAX register 36 (except for floating point values, which 35 are returned in the x87 register ST0).

[...]

There 34 are some variations in the interpretation 33 of cdecl, particularly in how to return values. As 32 a result, x86 programs compiled for different operating 31 system platforms and/or by different compilers 30 can be incompatible, even if they both 29 use the cdecl convention and do not call out 28 to the underlying environment. Some compilers 27 return simple data structures with the 26 length of 2 registers or less in EAX:EDX, and larger 25 structures and class objects requiring 24 special treatment by the exception handler 23 (e.g., a defined constructor, destructor, or assignment) are 22 returned in memory. To pass "in memory", the 21 caller allocates memory and passes a pointer 20 to it as a hidden first parameter; the 19 callee populates the memory and returns 18 the pointer, popping the hidden pointer when 17 returning.

The stack manipulations are going 16 to be much much faster than the heap manipulations 15 necessary if you allocate memory on the 14 heap, so stack is always faster. The only 13 reason (in C) you might want to return a 12 pointer to something on the heap is because 11 it won't fit on the stack.

Clarification:

In the last sentence 10 above, "the only reason you might want..." should 9 not be interpreted as "there is normally 8 no reason to return a pointer". Rather, I 7 mean "if you can do what you need without returning a pointer, the only reason to decide to 6 use a pointer anyway is...".

Of course 5 there are many valid reasons to return pointers 4 from functions as Chris states in his own 3 answer, but I 'm only talking about the 2 cases where you don't need to do so.

In other 1 words, return by value when you can; use pointers when you must.

And one more: would it be right to say that 29 objects I want to return, larger than register 28 should be stored in heap and returned by 27 pointer to prevent all than stack manipulations?

Well, maybe. Honestly, the 26 choice of "return by pointer" or "return 25 by value" is one you should probably have 24 better reasons to make than "I want the 23 return to be faster." For example, it would 22 be faster to return via pointer than via 21 stack for large objects, but this isn't 20 taking into account the greater amount of 19 time it takes to allocate an object on the 18 heap compared to the stack.

More importantly, return-by-pointer 17 allows you to have opaque pointers, variably-sized 16 objects and certain degrees of polymorphic 15 behavior that are impossible in stack objects. If 14 you want or need these kinds of behaviors, you 13 should be using return-by-pointer anyway. If 12 you don't, you can use return-by-value, or 11 you can pass a pointer to an object allocated 10 by the user (however they like) as a parameter 9 and modify that parameter in your function 8 (this is sometimes called an "out parameter" or 7 something similar).

Choose the return method 6 based on what you need and what your code 5 does, not which you think is faster. If 4 you find that you absolutely need the speed 3 (after profiling and finding that the return 2 is a bottleneck), then worry about this kind 1 of micro-optimization.