macOS C Programming Functions

[cybrscot]

Theoretically speaking, an entire program that does something is a function right? At least the programs I have written so far, that are very small...

Like a program I wrote that allows a user to enter a series of numbers, then the program will display the largest number. Is a program like this basically a function?

If so, could I then use this "program" as a function and insert it into another program to accomplish this task?

If this is the case, then I could make one "larger" program by combining several of my smaller "programs" or "functions" into one?? ??

 

[Hansr]

Yes but generally you don't refer to an application as a whole as a function. The principal you describe is consistent though.

 

[lee1210]

Theoretically speaking, an entire program that does something is a function right? At least the programs I have written so far, that are very small...

Like a program I wrote that allows a user to enter a series of numbers, then the program will display the largest number. Is a program like this basically a function?

If so, could I then use this "program" as a function and insert it into another program to accomplish this task?

If this is the case, then I could make one "larger" program by combining several of my smaller "programs" or "functions" into one?? ??

Your idea is on the right track. "main" is a function. If you're not taking commandline arguments using argc and argv, you could easily copy your main function into another function and re-use it. There are other ways to "paste together" programs using the system function, etc. but that's not really what you're talking about. Functions can definitely interact with a user, but it's more traditional that some input is passed in using parameters and processed. That would probably be the biggest difference between what's in your main function now and what you'd want in a modular/reusable function in the future.

-Lee

 

[balamw]

Some languages define two different structures: functions that (may) take input and return output and subroutines that (may) take input and don't return anything.

In C they are both functions the "subroutine" uses a void return type.

When you get to objects you'll learn about "methods" which are essentially functions that can interact with the objects. Objective-C in particular pushes a model of program modularity called Model-View-Controller which I find helpful in defining my code in most environments.

In your example, I might separate out the data entry and display from the bits that actually did the processing to find the maximum. This makes the maximum finding "module" as well as the I/O module(s) easier to reuse or re-implement without having to redo the whole thing.

B

 

[Bill McEnaney]

I wonder whether C's designer's wanted a C function to be much life a mathematical function, because mathematical functions don't change the values of their arguments. Pascal distinguishes between procedures and functions. A procedure can change the values of some variables you send it, and a Pascal procedure is much, much like a void function in C. But a Pascal function returns only one value per call, even if it changes the value of any argument it gets.

 

[Sydde]

I wonder whether C's designer's wanted a C function to be much life a mathematical function, because mathematical functions don't change the values of their arguments. Pascal distinguishes between procedures and functions. A procedure can change the values of some variables you send it, and a Pascal procedure is much, much like a void function in C. But a Pascal function returns only one value per call, even if it changes the value of any argument it gets.

C simply views everything as a call. From the perspective of machine language, the return value is almost always placed in a register, so it has no affect on the stack. "void" simply means you cannot expect the return value to be meaningful (essentially the same as a "PROCEDURE" in Pascal). There are a few exceptions, like functions that return a struct (RECTs, for example).

You may have noted that in some of the example code that shows up here, functions are treated like procedures. printf() is a good example of that. If you look at the prototype, printf() returns an int, but in most of the example code, it appears to be used as a procedure call. The return value is useful in cases where the target of the printf() output is a pipe or file, so that your process can determine how much data was actually sent in order to loop through a transfer to complete it fully. Writing to the console is generally not a critical operation, so we just ignore the return value. I suspect this would not work so well in Pascal (been a while since I worked with Pascal).

 

[notjustjay]

Yes. Any time you write a chunk of code that is starting to take up more than a few dozen lines, or if you find yourself repeating yourself a lot, it is time to consider whether it should be broken down into separate functions or procedures.

Ideally each function or procedure should be focus on one little chunk of work and be as self contained as possible. It should know as little as possible about the rest of the code (otherwise it starts to get very messy). You will focus much more on this when you start looking at object-oriented programming.

For example, you've written functions to square numbers (SquareIt). The SquareIt() function should focus only on its task of squaring a number. It should not care WHY its caller is squaring a number. That way your function can be reused in many places.

 

[Flynnstone]

"C" and Unix are closely related. In Unix, a concept of making small programs and build ing from there in layers (like an onion). Small fast effiecient programs calling other small programs. This enabled cool things like accessing a hard drive, but wanting to access a hard drive on another machine. a lower level program (hard drive device driver) gets switched out for a network type device driver (NFS). Cool, now you can access a remote drive as if it was local. Microsoft generally didn't follow this paradigm.

Now a bit back to what the OP might be getting at ...
You can write a program, lets call it "ls" that gives a directory listing.
Now you write another program, lets call it "cat" that types out the text of a file.
Now lets say you want to make one program to do these 2 things becuase its easier to move 1 program around insted of 2.
You can do that. The first argument is the name used on the command line.
This is very useful for embedded Linux. Can't remeber the name of the program .. EasyBox, TinyBox ... can't remember.
This is a Unix command line concept. When I use the term "Unix" I'm also including the other *nix's as well (Linux, the BSDs, Darwin (OS X)...).

When you get to the point of more User Interface type programs, I Highly recommend reading "The Humane Interface" by the late Jef Raskin.
This is to avoid the issue of you being a great "C" programmer, but make crap programs.

 

[balamw]

Can't remeber the name of the program .. EasyBox, TinyBox ... can't remember.

BusyBox http://en.wikipedia.org/wiki/BusyBox

B

 

[Bill McEnaney]

C simply views everything as a call. From the perspective of machine language, the return value is almost always placed in a register, so it has no affect on the stack. "void" simply means you cannot expect the return value to be meaningful (essentially the same as a "PROCEDURE" in Pascal). There are a few exceptions, like functions that return a struct (RECTs, for example).

Then I sit corrected. I thought "void" meant there was no return value.

You may have noted that in some of the example code that shows up here, functions are treated like procedures.

Sure have, I usually ran splint on each C program I wrote when I still used my SparcStation. That program usually made the computer complain about ignored return values.

 

[jiminaus]

Sure have, I usually ran splint on each C program I wrote when I still used my SparcStation. That program usually made the computer complain about ignored return values.

I can tell that I program's been run through some kind of lint when I see things like this:

int main (int __attribute__((unused)) argc, const char*  __attribute__((unused)) argv[])
{
    (void)printf("%s", "I'm super pedantic about warnings!");
    return EXIT_SUCCESS;
}

 

[Bill McEnaney]

I can tell that I program's been run through some kind of lint when I see things like this:

int main (int __attribute__((unused)) argc, const char*  __attribute__((unused)) argv[])
{
    (void)printf("%s", "I'm super pedantic about warnings!");
    return EXIT_SUCCESS;
}

I'm a little anal-retentive. Should "anal-retentive" include a hyphen? So I kept trying to wipe out each warning message about my C programs. Today I just use another programming language instead.