void do_nothing() { }
This function accepts no input, performs no instructions, and returns no
value.
There are three parts to every properly written LPC function:
Like with variables, functions must be declared. This will allow the
driver to know 1) what type of data the function is returning as output,
and 2) how many input(s) and of what type those input(s) are. The
more common word for input is parameters.
A function declaration therefore consists of:
type name(parameter1, parameter2, ..., parameterN);
The declaration of a function called drink_water() which accepts a string as
input and an int as output would thus look like this:
int drink_water(string str);where str is the name of the input as it will be used inside the function.
The function definition is the code which describes what the function actually
does with the input sent to it.
The call is any place in other functions which invokes the execution of the
function in question. For two functions write_vals() and add(), you thus
might have the following bit of code:
/* First, function declarations. They usually appear at the beginning
of object code.
*/
void write_vals();
int add(int x, int y);
/* Next, the definition of the function write_vals(). We assume that
this function is going to be called from outside the object
*/
void write_vals() {
int x;
/*N Now we assign x the value of the output of add() through a call */
x = add(2, 2);
write(x+"\n");
}
/* Finally, the definition of add() */
int add(int x, int y) {
return (x + y);
}
Remember, it does not matter which function definition appears first in the
code. This is because functions are not executed consecutively. Instead,
functions are executed as called. The only requirement is that the
declaration of a function appear before its definition and before the
definition of any function which makes a call to it.
this_player(), write(), say(),
this_object(), etc. look a lot like functions. That is because they are
efuns. The value of efuns is that they are much faster than LPC functions,
since they already exist in the binary form the computer understands.
In the function write_vals() above, two functions calls were made. The first was to
the functions add(), which you declared and defined. The second call, however,
was to a function called write(), and efun. The driver has already declared
and defined this function for you. You needs only to make calls to it.
Efuns are created to hanldle common, every day function calls, to handle input/output to the internet sockets, and other matters difficult to be dealt with in LPC. They are written in C in the game driver and compiled along with the driver before the mud comes up, making them much faster in execution. But for your purposes, efun calls are just like calls made to your functions. Still, it is important to know two things of any efun: 1) what return type does it have, and 2) what parameters of what types does it take.
Information on efuns such as input parameters and return types is often
found in a directory called /doc/efun on your mud. I cannot
detail efuns here, because efuns vary from driver to driver. However,
you can often access this information using the commands "man" or "help"
depending on your mudlib. For instance, the command "man write" would
give you information on the write efun. But if all else fails,
"more /doc/efun/write" should work.
By looking it up, you will find write is declared as follows:
void write(string);This tells you an appropriate call to write expects no return value and passes a single parameter of type string.
write_vals() above, the instruction:
x = add(2, 2);Must come before the
write() efun call if you want to see the appropriate
value of x used in write().
With respect to values returned by function, this is done through the "return"
instruction followed by a value of the same data type as the function. In
add() above, the instruction is "return (x+y);", where the value of (x+y)
is the value returned to write_vals() and assigned to x. On a more
general level, "return" halts the execution of a function and returns
code execution to the function which called that function. In addition,
it returns to the calling function the value of any expression that follows.
To stop the execution of a function of type void out of order, use
"return"; without any value following. Once again, remember, the data
type of the value of any expression returned using "return" MUST be the
same as the data type of the function itself.
4.5 Chapter Summary
The files which define LPC objects are made of of functions. Functions, in
turn, are made up of three parts:
The function definition consists of the following in this order:
The trivial function would thus be:
void do_nothing() {}
since this function does not accept any input, perform any instructions, or
return any output.
Any function which is not of type void MUST return a value of a data type matching the function's data type.
Each driver has a set of functions already defined for you called efuns
These you need neither need to declare nor define since it has already
been done for you. Furthermore, execution of these functions is faster
than the execution of your functions since efuns are in the driver.
In addition, each mudlib has special functions like efuns in that they
are already defined and declared for you, but different in that they
are defined in the mudlib and in LPC. They are called simul_efuns, or
simulated efuns. You can find out all about each of these as they are
listed in the /doc/efun directory on most muds. In addition many
muds have a command called "man" or a "help" command which allows you
simply to call up the info files on them.
Note on style: Some drivers may not require you to declare your functions, and some may not require you to specify the return type of the function in its definition. Regardless of this fact, you should never omit this information for the following reasons:
mud@wl.mud.de