Today 's lesson, (with some clarity and proper terminology)

[G+_Joe C. Hecht]

Today's lesson, (with some clarity and proper terminology)

 

A functions or a procedure is a block code that you can give a name to,

and then call the block of code by name. 

 

"Functions" and "Procedures" are great for when you have to use the same code many times. You write the "Function" or "Procedure" once, then call it whenever you need it. This helps make your code small, clean, error free, and promotes "code re-use".

 

"Functions" return a value.

 

"Procedures" do not return a value.

 

You can pass data to "Functions" and "Procedures".

 

Each piece of data that gets passed is called a "parameter".

 

Think about it like this:

 

If needed to commonly write the same lines of text (lets say your address and phone number) many times in your program, you could place the those lines in a procedure, then give the procedure a name like "PrintAddressAndPhone()", then simply call that procedure name from your code whenever you wanted to write those lines.

 

If you ever change your address or phone number, you only have to change it once in the program, instead of having to use search and replace. Finally, there is less chance of error, since it was entered only once.

 

Since the block of code only does something, and does not return a value, it is called a "Procedure".

 

Next, suppose you commonly need to perform the same action, and you need an answer back. This is a "Function". For example, you might need to calculate the sales tax for a value, so you write a "function" called "CalcSalesTax(float SaleAmount), that will take a "parameter" (the SaleAmount), and return the proper amount of the sales tax to

charge.

 

This is called a "Function", since it returns a value.

 

Both "Procedure" and "Functions" can take parameters, but only "Functions" return values.

 

Your "Procedures" and "Functions" can be collected and placed into "modules", that can be included and reused by your other programs. This makes for a great "bag of tricks" that your can continue to add to for years to come, and will save you a lot of time in the long run. Your modules can also be combined together into a "Library", and, if it provides enough functionality, can be sold or distributed as an "SDK (Software Developers Kit).

 

This is TJoe, Code4Sale, LLC, and while I am not a code monkey, I am for sure a codewarrior, currently authoring an SDK comprising of over 15,000 modules.

 

COPYRIGHT 2014 by CODE4SALE, LLC. All rights reserved. Posted to TWiT's "Coding 101" G+ forum with permission.

[G+_Lee Crocker]

I would clarify that the distinction between functions and procedures is a language-specific thing, and some languages allow functions to return more than one value. Also, some languages have only object methods. We'll save closures, continuations, and coroutines for a later lesson.

[G+_Joe C. Hecht]

When I posted this, I thought I would get labeled a "Pascalist", however, the distention derives from the world of mathematics and logistics, where functions produce output, and procedures perform steps.

 

When writing SDK's (and compilers), the convention is often evidenced with names like FooFn() and FooProc(), providing an indication if a return value exists (or is expected) after the given call.

 

"Methods" of "objects" ARE functions and procedures, since they are simply code pointers added to a data structure (along with a reference pointer to "self") to form an object.

 

As it turns out, adding "object orientation" to a base language is actually pretty easy to do (providing the language supports the idea of "function pointers"). You simply add a "function table" and a "pointer to yourself" to any data structure, and your language is now "plus plus'd".

 

Add a runtime type information and some data conversion functions for basic types (if needed) and, and you get, well, "com" objects.

 

So, to add a little value (or usefulness) to this long winded post,  Here goes: if you ever need to use "objects" in your program, but you code has to run in a non-object orientated version of a language, if it supports the concept of function and procedure pointers (such as straight "C"), you can just make the objects yourself by simply making a data structure and adding a "function table" that will hold the address of the procedures and functions that will manipulate the structure's data. Add a pointer to the structure that points to the structure (ie: self), and there ya go!. It is actually a lot of fun! You automatically get inheritance for descending objects, and you can add all sorts fun stuff like polymorphism, abstract methods, overrides, and so forth.

 

BTW, on the subject of COM, while you can blame me for the idea of "active X", please don't blame me for the ill-fated implementation. Had MS followed my initial proposal (instead of grabbing the concept and running off with it), the world would be a much better place today :)

 

TJoe

[G+_Lee Crocker]

Yes, methods are just functions with an implicit argument, but someone would have mentioned them if i hadn't. I've done lots of OO code in C: I generally make my objects structs with a pointer to a class object, and put the method table there; I do inheritance at compile-time by just filling the method table with superclass methods directly for speed or make methods that call superclass methods to override if needed. Doing closures is a whole different can of worms. :-)

[G+_Joe C. Hecht]

Same here! I do a lot of low level SDK development and driver code, where the base layers are always in C, yet I need OOP, lots of virtual method tables, and some really good garbage collection and thread support, so I end up having to write all that stuff from the ground up.

 

At least we know our code ends up small and fast, and we know exactly how things are going to compile.

 

I might venture to guess you estimate clock cycles as you code?