macOS Question about functions is C

[cybrscot]

Okay, so I'm on Chapter 6 already in "Learn C on the Mac". I must say it's much easier than my other book, but it clearly doesn't teach me nearly as much as my other book. I'm way beyond "Learn C on the Mac" Ch. 6. There's only 4 more chapters in the book! I don't think it's going to cover everything that my other book covers, in which I still have 18 more chapters!!

But anyway, it's serving it's purpose, filling in some knowledge gaps and making some concepts seem easier. Good to augment the learning process.

Anyway, my question is about functions. I've just learned what functions are in C. And from what I understand one of the benefits of naming a function is so I can call that function in the future without having to rewrite all the code. Am I correct on this?

In other words, if I write a small program that alphabetizes user input. I can name this main function something. Then if I'm writing a larger program, and I need to alphabetize within the larger program, rather than re-write the code, I can just insert my "new" function? Is this true? Is it also true that I won't see the code in my larger program? But only see the function. The function will do it's work behind the scenes?

Assuming all this is correct, I haven't learned exactly how and where I save my function?? If I write a function, where do I "save" it?? If I write a completely different program and insert my function, how will the new program know where to find the code for my function?

Lastly, if a friend needed code that did something, and I had it. Can I somehow give him the function that will do what he wants it to do, without revealing the source code??

Thanks
Scott

 

[subsonix]

Your assumption is correct. Functions you create yourself is just like the functions in the standard library, ie you call printf() and printf does things behind the scenes.

You would include your functions with the #include directive just like the standard functions, so for example: #include "userinput.h", notice the "" instead of < >. The quotes is used when you provide the path to the file, normally this means the header file is in the same directory.

It is possible to have both the definition and declaration in the header file, but, normally the declaration is in the .h file and the implementation is in a corresponding .c file.

 

[balamw]

Assuming all this is correct, I haven't learned exactly how and where I save my function?? If I write a function, where do I "save" it?? If I write a completely different program and insert my function, how will the new program know where to find the code for my function?

subsonix answered this, but I'll just add that this is a big reason to learn to use the editor/compiler/linker separately to see how this all comes together when you have code in multiple files. The IDE (like Xcode) tries to hide this all from you, but it can fail and when it breaks you need to understand why.

Lastly, if a friend needed code that did something, and I had it. Can I somehow give him the function that will do what he wants it to do, without revealing the source code??

You could deliver an object file (.a) instead of the source code file (.c), though you would still generally have to give your friend a copy of the header file (.h).

B

 

[larswik]

Cybrscot - I really liked that book, Learn C on the Mac. I started to slow down on Chapter 9 when it started with Data Structures, multi dimensional arrays and linked lists.

I have to say that taking a Pascal programming class at the local city collage has helped a lot. I am now dealing with functions again for my next home work assignment.

This summer I plan on taking the next book in the series after Learn C on the Mac which is, Learn Objective-C on the Mac. He recommends it at the end of your book.

-Lars

 

[Sydde]

Anyway, my question is about functions. I've just learned what functions are in C. And from what I understand one of the benefits of naming a function is so I can call that function in the future without having to rewrite all the code. Am I correct on this?

In other words, if I write a small program that alphabetizes user input. I can name this main function something. Then if I'm writing a larger program, and I need to alphabetize within the larger program, rather than re-write the code, I can just insert my "new" function? Is this true? Is it also true that I won't see the code in my larger program? But only see the function. The function will do it's work behind the scenes?

You have the basic idea. Typically, a larger project will be composed of a whole bunch of .h/.c file pairs, organized so that each one contains a related set of functions. Each function that makes use of another function in another file must #include the .h file that defines (prototypes) that function. This is done to organize the project so that you can focus on small sections of code in a file instead of one huge file with pages and pages of code, and so that you can move important chunks of one project (usually already debugged) to another if it makes sense to.

For example, if you were writing a program to alphabetize user input, you would have your main.h file, which might #include 3 other .h files: one to handle user input, one to handle alphabetizing the input, and one to generate the output. All the heavy lifting code would be in those three files, your main function would be maybe eight or ten lines long. Or the input function could call the alphabetize function, which would call the output function, each one of those .h files including the next .h file, further reducing the code in the main function. Which technique you choose would depend on your needs.

So, you have finished this project and it is time to move on to another one. Suppose you are writing a search tool, and when you look back at the alphabetizer, you see that that input function is so excellent, you can just copy the .h and .c files right over to the new project and use it again, as is, or very nearly (here, the organizational technique can make the job easier or harder).

The file structure of a project can become very large and complex, with many files #including many others. Because the smaller each part is, the easier it is to work on, and the easier it is to modify the way a program operates or looks.

But you were about to learn all this anyway