A couple other things of note:
The difference between 'declare' and 'define':
declaring a variable is telling the compiler "I have a variable named
foo, and it's an int. Anywhere I use 'foo', treat it (and check it) as
an int. I swear that foo is somewhere in the C files I'll link to make
the executable."
defining a variable is telling the compiler "Make an int. I'll refer it
it as foo."
The definition is what actually stores the value, the declaration simply
tells the compiler how to handle itself when it comes across a variable
named "foo" that hasn't been defined yet, rather than throwing an
"unknown variable 'foo'" error.
Spot on with your explanation. Good job. :)
The other point of gsn.h (at least with OLC2.0).
<History Warning!> The gsns used to be stored in merc.h back in the day
as a big long list of extern ints, and then defined in db.c. With the
introduction of a dynamic skill/spell table (complete with editor), the
gsn.h file was born so you add an entry to it in the form of
GSN(gsn_backstab)
and it could be used to populate a gsn table:
#define GSN(x) { #x, &x },
const struct gsn_type gsn_table [] =
{
#include "gsn.h"
{ NULL, NULL }
};
I would suggest reading up on what the #define pre-processor directive
does if you don't understand the above lines of code. Suffice it to say,
it populates the gsn_table with "gsn_backstab", &gsn_backstab combos for
every GSN() in gsn.h
Of course, the downside is db.cc still uses the old sh_int gsn_backstab;
etc list, which could probably be replaced by:
#define GSN(x) sh_int x;
#include "gsn.h"
(Disclaimer: I just barely thought of this idea, so don't blame me if it
doesn't work exactly this way since I haven't tested it yet...)
Then if you add a new gsn, all you need to do is add it to gsn.h and you
can merrily use it in your code and all the behind-the-scenes stuff is
taken care of for you by the pre-processor.
Ammaross Danan
Realms of the Forgotten
www.rotf.net 4998
Tony Kuiper wrote:
Sandi,
The reason they're defined as extern in merc.h is so that other
functions can use these variables. If you put the declarations (not
the extern) into merc.h, then the gsns would be declared in every file
that includes merc.h - kinda like declaring "int foo;" in *all* your
source files. They will compile perfectly individually, but when
linked together you'll get lots of errors about repeated declarations
of, you guessed it, "int foo." Anything that is declared more than
once - variables, functions, etc. will cause linking errors. That's
why we declare the gsns as extern in merc.h: everybody will be able
to see them and use them, but only db.c will create the gsn variables
themselves. (i.e. it's like having a set of business cards made with
your name, address, phone number, etc... - you can give them out to
anybody in the world that needs to find you or talk to you, but there
should only ever be one of you... that is, unless it's crunch time and
the boss finally perfected that cloning machine in his basement...) :-)
So if you can remove the extern keywords from merc.h and have your
code compile, link, and run without a problem... then I need to get a
copy of your compiler! :-)
Tony
----- Original Message ----- From: "Sandi Fallon" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, February 13, 2007 5:04 PM
Subject: Re: [ROM] gsn definitions
Thanks for the replies, guys.
In response to your responses, I guess you can guess what I did.
And, it seems to be working fine. :)
So, is putting the defines (I'm hoping I get this right - the only
language I know is English.) in db.c an old compiler/slow machine
thing, or is there a real advantage to not just defining those things
only in merc.h? Obviously, it's advantageous to us humans not to have
to write new gsns in two places.
In other words, having commented out the defines in db.c and putting
them in merc.h without the 'extern', am I gonna crash, bloat, or
otherwise regret it?
Thanks,
Sandi
--
ROM mailing list
[email protected]
Unsubscribe here ->>> http://www.rom.org/cgi-bin/mailman/listinfo/rom
--
ROM mailing list
[email protected]
Unsubscribe here ->>> http://www.rom.org/cgi-bin/mailman/listinfo/rom
