Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ SMAUG ➜ SMAUG coding ➜ CREATE() overloading

CREATE() overloading

It is now over 60 days since the last post. This thread is closed.     Refresh page


Posted by Greven   Canada  (835 posts)  Bio
Date Sat 11 Dec 2004 04:20 AM (UTC)
Message
Function overloading in C++ seems to me to be a great feature, and as I am reading up on the difference between C and C++, I've just come across this. Now, I understand that overloading for functions that are not similiar is in bad style, my question I guess is what are peoples opinions on using the CREATE macro, since its litered everywhere, to call a create function that is overloaded for all the different types of structures used. To me this seems like a fairly good way to ensure that initialization is done properly every time something is created, and provides the functionality of one function to use. The same could also be applied to freeing as well. Is this a preferable way to do things, or is another options, such as class constructors and destructors a better choice?

Nobody ever expects the spanish inquisition!

darkwarriors.net:4848
http://darkwarriors.net
Top

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #1 on Sat 11 Dec 2004 08:16 AM (UTC)
Message
If you're trying to ensure initialization at memory allocation, then the way to do it is with constructors.

Note that in C++ a struct is a class-in-disguise (where everything is public and public only), so you can have constructors/destructors on structs as well as classes.

If you're using C++, I would just throw away the silly create macro and only make calls to 'new'. Of course, this means that you have to throw away calls to 'free' (destroy) and replace them with calls to 'delete'.

In any case, if you do function overloading for the create function, you're basically reimplementing a lot of what 'new' does to begin with; it's somewhat of a waste of time.

One thing to think about is what belongs in the constructor, and what belons in other initialization functions. Perhaps you don't need to worry too much about this for the basic SMAUG model - most of the structs have "constructors" anyhow (such as create_mobile, create_object etc.)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Samson   USA  (683 posts)  Bio
Date Reply #2 on Sat 11 Dec 2004 05:08 PM (UTC)
Message
I agree on the point of ditching CREATE if you're going to be using C++ classes with constructors. As far as what to initialize and what not to, pass the code through Valgrind and it will happily tell you in the form of warnings about dependency on or use of uninitialized values.
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #3 on Sat 11 Dec 2004 09:52 PM (UTC)
Message
The problem with CREATE is it does a malloc (calloc anyway) which will *not* work if you start using classes inside your structures.

If you are going to use C++ you may as well enjoy the considerable benefits of STL, like strings, lists, maps etc.

It is *so* much easier to do linked lists, maps, queues, strings in STL that I could never go back to the old way.

Here is an example of the sort of thing you could change:


struct  cmd_type
{
    CMDTYPE *           next;
    char *              name;
    DO_FUN *            do_fun;
    int                 flags;  /* Added for Checking interpret stuff -Shaddai*/
    sh_int              position;
    sh_int              level;
    sh_int              log;
    struct              timerset        userec;
    int                 lag_count;      /* count lag flags for this cmd - FB */
};


Now the first thing you could do is make the name a string, rather than having to malloc the memory for it, eg.


struct  cmd_type
{
    CMDTYPE *           next;
    string              name;
    DO_FUN *            do_fun;
    int                 flags;  /* Added for Checking interpret stuff -Shaddai*/
    sh_int              position;
    sh_int              level;
    sh_int              log;
    struct              timerset        userec;
    int                 lag_count;      /* count lag flags for this cmd - FB */
};


However this *will* crash if you use CREATE, because the malloc/calloc does not call the string's constructor. You need to use new to create each command.

Then you can get rid of the linked list anyway, and use a map, eg.


struct  cmd_type
{
    DO_FUN *            do_fun;
    int                 flags;  /* Added for Checking interpret stuff -Shaddai*/
    sh_int              position;
    sh_int              level;
    sh_int              log;
    struct              timerset        userec;
    int                 lag_count;      /* count lag flags for this cmd - FB */
};

map<string, cmd_type> commands_map;


Now you can just add a command like this:


cmd_type look_command;
// fill out structure here 
commands_map ["look"] = look_command;


and find it:


cmd_type look_command = commands_map ["look"];


I'm not testing this as I type, so forgive me if this doesn't all compile perfectly. ;)

You can override the comparison routine for maps, so you could make the lookup case-insensitive. Or if you want to do stuff like the prefix checks, you can use a list instead:

list<cmd_type> commands_list;

Iterating over a list is very simple still.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


11,424 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.