[Courses] C Programming For Absolute Beginners, Lesson 5A: All About Functions, Part 2

[Carla Schroder]

Hi Christopher,

On Sunday, April 01, 2012 11:47:51 PM Christopher Howard wrote:
> Hi. If I may, I will pick on one or two small points, in the interest of
> accuracy:
> 
> On 04/01/2012 09:06 PM, Carla Schroder wrote:
> > The return type is whatever C data type you want to use. Every function
> > in a program must have a unique name. If there is no return value you
> > can use "void" for your return type. If there are no arguments then you
> > should enter "void", because as we learned in Part 1 the empty
> > parentheses means an unknown number of arguments. It is always best to
> > be explicit, so we want to use "void" to indicate that there are zero
> > arguments.
> 
> If I'm not mistaken, it is more accurate to say that every function with
> external linkage must have a unique name. The Holy Gnu programming
> manual states:
> 
> quote
> --------
> You can define a function to be static if you want it to be callable
> only within the source file where it is defined:
> 
>   static int
>   foo (int x)
>   {
>     return x + 42;
>   }
> 
> This is useful if you are building a reusable library of functions and
> need to include some subroutines that should not be callable by the end
> user.
> --------
[snip]


I don't see how this makes a case against creating unique function names. 
Sure, you can do it.  Regardless of any circumstances where duplicate function 
names would not cause a program to run incorrectly, why would you want the 
confusion?



> --------
> 
> > C functions can be written five different ways:
> > 
> > 1--No arguments or return values
> > 2--Arguments and no return values
> > 3--Arguments and return values
> > 4--No arguments and return values
> > 5--Return multiple values
> 
> Item 5 should be excluded from the list. Speaking technically, all
> functions in C return one value and one value only. This might be a
> struct containing other data objects, yet even in such a case it is only
> one value that is returned by the function (the memory address of the
> struct). I suppose one could argue semantic nuances here, but even on
> the highest level we recognize that a "return" statements returns only
> one evaluated result.

Nah, it stays on the list :). Whatever the semantic nuances, which are good to 
understand clearly, it's still operating with multiple returned values.

> 
> I'm not sure whether it is, technically speaking, proper to refer to a
> function returning "void" as returning zero or one arguments. My c99
> draft copy states:
> 
> quote:
> --------
> The (nonexistent) value of a void expression (an expression that has
> type void) shall not be used in any way, and implicit or explicit
> conversions (except to void) shall not be applied to such an expression.
> If an expression of any other type is evaluated as a void expression,
> its value or designator is discarded. (A void expression is evaluated
> for its side effects.)
> --------

Good, this ties in nicely with Jacinta's comment on side effects.

[snip]
> --------
> 
> > HOMEWORK
> > 
> > Take any of these examples and modify them to accept user input, just
> > like we did in our previous lessons. Put as much functionality as
> > possible into separate functions and then call them from main.
> > 
> > If there are any gurus wishing for a bit of a challenge, give us some
> > examples of using functions efficiently and correctly.
> 
> Actually, speaking purely in terms of performance optimization (making
> your code run faster) functions can be a very dangerous thing. Making a
> function call often requires the processor to make a large jump in
> memory, which means (depending on where or how far you jump) that the
> processor may have to waste precious cache space or pull code from
> slower memory. Furthermore, when you make a function call, of course the
> process has to go to the trouble not only of moving arguments into the
> proper registers, but it may also need to push additional data out of
> the registers onto the stack, so that this data is preserved across the
> function call.
> 
> The "inline" keyword, if I am not mistaken, actually suggests to the
> compiler that it should directly replace the function call with the
> actual function code:
> 
> code:
> --------
[snip]


Fish fiddle dee dee, functions are not dangerous!  Functions are your program. 
Modern compilers perform all manner of optimizations, including deciding which 
functions to inline. Manually inlining a function is compiler-dependent, and 
useful in limited circumstances, which we will cover in this course. 

Would you explain your inline object code example? What performance difference 
does this show? 

best,
Carla


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Carla Schroder
ace Linux nerd
author of Linux Cookbook,
Linux Networking Cookbook,
Book of Audacity
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~