Sigmund and his buddies were GREEN! What are you talking about?
Sigmund and his buddies were GREEN! What are you talking about?
Originally Posted by nick753
, There is no difference in the way a library function is written and the way you write your own personal functions. Header files are filled with function prototypes.
Hey man you don't have to be a dick about it. Where did I say that he was wrong, I'm curious? I never said that functions in libraries were not functions did I? I simply said that those weren't the functions I was referring to, dick, I mean Dane.
Thanks for being nice about it, I appreciate it. Though I already knew that.
What is the point of functions?
1)Repetition: functions are a way to do the same thing multiple times in a program
2)Modularization: Functions can be made to be reusable as part in multiple programs, such as with libraries. Then you don't need to rewrite the code next time you need to do the same thing.
3)Logical separation of operations: normally a program needs to do a big task with several logically separate steps. Splitting each of those steps into a function makes the larger task's code shorted and easier to read.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
What is the color of sea monsters?
a) Purple b) Blue c) Green
Correct answer, iiisss B) BLUE!
Sea monsters come from whales and whales in our minds are usually blue/gray.
Alternative: if we consider that sea monsters existed not because of whales, then most likely it was from weird shapes the waves made. Thus, again blue.
Alternative: if it comes from people that wanted to lie, saying I saw a purple monster would seem more strange, cause people would ask "how come nobody else show it?". So the liar will choose blue, to answer "the waves camouflaged it well. I am telling you it was a beast!".
What is the point of functions?
Let me show you a loop for a RPG this is the main loop
Now lets say something weird happens when the player presses a key I know to go look at the function for ScanKeys(); It helps organize your code into managable pieces helps with debugging and makes the code portable and readable.Code:while(!quit) { RedrawScreen(); ScanKeys(); UpdateMonsters(); mymap->UpdateMap(player->GetX(),player->GetY()); player->update(); }
Now a very general code to check if a mouse click is inside a box or not.
The descriptive name tells me hey your checking to see if the mouse is inside a box defined by these two points. If I wrote the code then came back say a year later I would eitherCode:bool insidebox(int x1,int y1,int x2,int y2) { if(x1 <= mouse_x && mouse_x <= x2 && y1 <= mouse_y && mouse_y <= y2)return true; return false; }
A) Have to remember what I was doing.
or
B) Hope I commented the code.
or
C) Read the code and try to figure out what it is doing.
Something to remember is bigger projects will generally have many people working on them teams of people and functions can be split between each person to code/verify then are easily implemented into a loop or another function.
Is that a joke?
This one is amazing lol
So, what is the point of making a box and put your things inside it, when you can put everything on the ground?
First of all, using functions makes your program smaller... What you say is the same as using in line code everytime, and thats just plain stupid.. If you're making a big application, then its going to be bigger...
When you make a function, you're calling the same blok of code over and over.. You can even call it using pointers(Im sure you knew)...
So, if you dont see why using functions, heres why: when you make a function, you call the same blok... When you write the same code yourself, you're making a lot of the same function and spreading it in your programm... It will be faster(because you wont be calling another blok before using it), but it will make your program bigger...
Calling a function is a little slow(you wouldnt notice) compared to write it everytime, but wont make a lot of copies of the same blok...
If you REALLY wanna write it yourself, do it... But you could consider using in line code, it would be smarter...
your question is the same as asking why you shouldnt make a new variable everytime you need to update the value of a variable and keep the old one
Last edited by Dante Wingates; 04-23-2010 at 02:37 AM.
Since the ways they can affect the program outside of themselves are limited, functions can be like black boxes for which you only need to know the inputs and outputs to use. If you know that a certain function works correctly, you can forget or ignore exactly how it does what it does and just use it.
It's like how I don't have to know the first thing about how a car engine works to use one. Strictly speaking, all I have to know is how to turn the car on and how to use the gas pedal.
Functions are just one of the features of programming languages that help you to focus on one part of a program at a time, making it easier to read, debug, and understand. Without functions, you would have to essentially read an entire program from beginning to end to understand it enough to make changes to it. That would be extremely tedious work for a program that had tens or hundreds of thousands of lines of code, as they often do in the real world.
This is one point that you mentioned
there are other reasons for this also
A program divided into many small functions is easier to maintain,update and debug.
Modern programs get very complex, and just like any other complex designs (a car for example), abstraction is the key.
They don't design airplanes thinking about every bolt, every wire, and every piece of metal. No one can manage that kind of complexity.
Instead, they build the engine first. When they are building the engine, they think about every bolt, every wire, and every piece of metal. But once they are done, they seal it up and call it an engine. The internal design of the engine is not important anymore.
Then, they build the doors. When they are building the doors, they think about every screw, every plate, every hinge. But once they are done, they call it a door, and the internal design is not important anymore. All that matters is how it reacts with the outside world (the interface).
When all the parts are done, they can finally start designing the plane, not from those bolts and tiny pieces, but in terms of engines, doors, windows, seats, etc. They only see the "big picture".
This is necessary for any kind of complex design. Abstraction is the standard way to manage complexity in any engineering discipline.
Another example.
Your CPU has billions of transistors. How do you think they are made? Someone sitting in front of a computer placing every single transistor in the right place and make the right connections? Of course not.
They first take a few transistors, wire them up to make the gates they need (AND, OR, NAND, NOR, etc). Then they seal them up and treat them as single entities.
Then, using the gates, they make an ALU, a decoder, a register, a multiplexer, etc. Note that at this point, they aren't thinking in terms of transistors any more, but in terms of "gates", each of which contain multiple transistors.
And finally, they can design the processor out of those parts, just by connecting them together, and duplicate them as appropriate.
This kind of examples are everywhere.
Functions are what provide this kind of abstraction in programming.
Once you write some code that accomplishes some specific purpose, you can put it in a function. Later on, you can make more complex designs by thinking in terms of your functions (each of which can contain many lines of code). This makes your life a lot simpler, and simplicity allows complexity. If you have to think about every single simple statement at every stage of your design, you won't get very far. Abstraction is necessary for us to see the "big picture".
Just a small note, I do agree with pretty much everything that you've said. Just note that the use of AND, NAND, and NOR gates for high performance parts (CPUs) is generally minimized. Just like functions have an overhead for creating them, discrete gates also have their overhead. A 3 input NAND gate designed at the transistor level will use less power and transistors then 2 and gates strung together.
However, hardware designers rarely worry about that sort of thing now-a-days. HDLs (and their implementers), such as verilog, abstract that sort of thing. Similar to how you don't have to go down into assembly every time you write a program (though, you could potentially get faster results if you did).
But yeah, abstraction is the breath of life for developers and hardware designers, functions make abstraction possible.
