Few general notes on this:
My idea if using new functions provided by libraries (if they exist) and include
local copies if they don't is that often times vendor provided functions may be
much better optimized that locally included ones.
Also, for some functions (like strlcpy), it may be a trivial exercise to
include a local copy of equivalent functionality. But for others, like
snprintf, it might be hard, but a simple replacement of non equivalent
functionality is easy, like:
sprintf(buf, ...)
if strlen(buf) > buflen { oops, we have a buffer overrun }
which isn't great, but could still be better than an alternative of just using
an unprotected sprintf.
I do tend to agree with the comment that given crossfire is C code, using a C
compiler would seem to be the best tool to use to compile it. That said, if it
happens to compile with a C++ compiler, or changes are trivial to let it do so,
great. But I'd just put the responsibility of making sure it compile with C++
belongs to those who want to compile with C++, not all developers.
I will also note that crossfire actually does a fair amount of floating point
- all the speed and speed_left is floating point, the just simple
addition/subtraction.
The plugin logic has pluses and minuses - the ability to right plugins that
register themselves is good, but the entire dynamic loading adds a bit of code
complexity and another place for errors. But also, at one time, the python
plugin was optional, so you could run the server without necessarily having
python & its development libraries installed. But IIRC, at some point, it was
decided that enough scripts and other stuff require python it should become
standard - since it is known it will always exist, whether having it be a
dynamically library that is loaded makes sense is debatable.
_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
