Few questions: Use form of server/types/foo.c or server/types/foo/bar.c depending on if the object type requires multiple C files to be clean.
With the fact that the SVN repository is called server, it is unclear exactly what server refers to. If we include the repository name, is it: server/server/types server/common (example of existing directory) Or server/types common/ (being the exististing directory) IMO, I'd prefer the second form - put the types directory at the top level, relative to the server directory. This is how the socket code is, doesn't have any real disadvantage, but could have some advantages (better for unit tests? Better for stand alone program that does simulations, etc?) Function pointers: It's not specifically mentioned on how the callbacks are registed. I see one of two ways: register_apply_callback(type, funcpointer); or register_callback(type, funcpointer, callback_type) Both have pros and cons. The first case has the advantage that the compiler can do actual type checking on funcpointer. The second has the advantage you don't need as many callback functions, and it makes it easier to add new callbacks (add the new callback_type #define, update the number of callback types, and recompile. One could even do things like: callbacks[ob->type][CALLBACK_TYPE](....) It's also not really mentioned on how the callbacks themselves are registered (that code has to be someplace). And rather than having a single function that registers all the callbacks for all the object types, I'd suggest that each type file has something like init_callbacks_weapons (or something). Then in some other place, you have that function that calls all the init_callbacks - having a function of MAX_TYPES lines longer is much better than one of MAX_TYPES * MAX_CALLBACK_METHODS lines long. The other advantage of this is that the individual types files themselves can then declare all the functions except the init function static, so that it can't be called by other functions. I suppose that one could use various system function calls to try and look up the function names and call them (presuming a standard naming scheme, like init_callbacks_46, where 46 is the type number for that object), but that may be overly complicating things. Other thoughts: It may be better working on getting all of this infrastructure/callback methods in place, and implementing one type of object using them instead of focusing on the specific callback method (the web page mentioned doing all the apply stuff). Why? That way, if someone does write code for a new object type, all the pieces are in place so they can use the new method. If only the apply callback is implemented, they can use that logic, but are left using old coding method for the other areas, that then needs to be converted down the road. Also, by doing all the different callback methods, it provides better coverage of the callback logic, eg, if there are issues with any of the methods, they will be found sooner vs later. Second, if we're going to be writing all new functions, we should use some other 'best practices'. In particular, for anything that would return a string value, they should be modified so that a string pointer (and length of that pointer) is passed in, instead of using static return buffers. This will assist if we ever thread the server, but it will also help prevent a few bugs (related to this, sprintf, strcat, and strcpy should never be used, but rather snprintf, strncat, and strncpy instead) _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire