Thread: Functions are Still Not Understood.

I need help because I cant seem to understand how functions work with arguments
and structures.

I have this function in a program,
void do_cast(struct char_data *ch, char *argument, int cmd, int subcmd)

with a lot of code I could post for you if you want to help me change it.

What I need help with is understanding how
a) the function will return the structure
b) how to return the structure when using do_cast
c) how the function will return the char *argument
d) how the function will return the int cmd
e) and how the function will return the int subcmd

Basically I need help understanding how a function returns its variables
from the computer language inside its brackets and how to use the function
and its variables in a c program.

This isn't my homework, I really have a program that has that function. I also
tried learning how to use functions from c programming.com without any
luck so i'm hoping someone can explain functions to me so that I might understand
how to use them proficiently or even well enough to make a useful program
function. If someone would help me understand these how to's then i will
understand functions. that is why i posted the question and also so that
whoever reads my questions may understand the question I am asking. I
repeat again I am not asking for homework help. I do not go to school.

If anyone has some extra time on there hands I Would like to know how to make a
useful command line argument for a telnet program. Maybe something cool that
you have on your mind or have used or a liked that feature when using a telnet
program or any program that accepts command line arguments.

Anything that hasn't got a star in the parameter list can not be modified outside of the function itself. Whether it "returns" with any of the other parameters modified or not is a matter of what the function itself does, and we can not tell that from the prototype declaration that you have posted.

--
Mats

Right, that's quite a lot of understanding to gain. I think you need to start with a slightly less complex task from what it looks like.

Trying to understand fairly complex code simply by reading the code by itself is like trying to read a foreign legal document using a dictionary - it's not going to work!

--
Mats

The law of rapid experience-gaining: "one gains experience the fastest and easiest by doing things at their own level and no higher or lower". In this case, it's like a second-grader being assigned 10th grade work - it's hard and frustrating. Tone down the difficulty a lot so that it is at your skill level. Try this. Have a function return a value 5 higher than what was fed to it. This is the easiest you can get for learning functions. Got that mastered? Okay, try having the function accept a pointer to a value and return 5 more to it. Just work your way up but keep at your own level. Take it too easy and it'll be boring and you won't get experience quickly (like a tenth-grader being assigned second-grade work). Take it too hard and it'll be frustrating and confusing halting experience (like a second-grader being assigned tenth grade work). Do it at your level, and the challenge is acceptable and the experience comes quickly. I've used this "law" to improve on my comprehension skills - from the 4th grade level (in 11th grade) to about grade 7 by the end of high school. This applies to anything, including programming (and I'm using it with programming as well).

Originally Posted by ulillillia

The law of rapid experience-gaining: "one gains experience the fastest and easiest by doing things at their own level and no higher or lower". In this case, it's like a second-grader being assigned 10th grade work - it's hard and frustrating. Tone down the difficulty a lot so that it is at your skill level. Try this. Have a function return a value 5 higher than what was fed to it. This is the easiest you can get for learning functions. Got that mastered? Okay, try having the function accept a pointer to a value and return 5 more to it. Just work your way up but keep at your own level. Take it too easy and it'll be boring and you won't get experience quickly (like a tenth-grader being assigned second-grade work). Take it too hard and it'll be frustrating and confusing halting experience (like a second-grader being assigned tenth grade work). Do it at your level, and the challenge is acceptable and the experience comes quickly. I've used this "law" to improve on my comprehension skills - from the 4th grade level (in 11th grade) to about grade 7 by the end of high school. This applies to anything, including programming (and I'm using it with programming as well).

Actually that's some really great advice there!
Do projects where you're pretty sure you know how to do about 80-90% of it, and you're pretty sure you can figure out how to do the remaining percentage.
I only once ever wrote a game where I knew how to do the whole thing from the get go. Most boring four hours of programming I ever spent. Throw me in the deep end though and I'll be constantly wishing I was somewhere else.