[crossfire] Crossfire server code cleanup/janitorial

[Kevin Zheng]

On 04/21/2014 01:23, Mark Wedel wrote:
>  Going back to to the original thread - certainly win32 is used, and I
> also do sun/solaris.

Solaris support seems like a good idea to keep.

>  I think some of that might be sound code for the client - though even
> on linux, it seems that the sound 'standard' changes every 5 years or so.

Sound support is now handled by SDL_Mixer, which works well with OSS,
ALSA, PulseAudio, and the myriad of sound systems there are. Most, if
not all of the platform-dependent code there has been removed.

> Changing C standard is certainly something worth discussing - C99 would
> be reasonable (in my mind) - C11 may be a bit too recent - while it may
> be widely supported, it might also mean that certain users would be
> forced to upgrade their compilers (and perhaps other parts of their
> system) faster than they really want.  But it also really comes down to
> features - What C11 (or even C99) features are out there that would be
> of benefit to crossfire?  I'm not familiar enough with the different
> standards to make any assessment on that.

C99 has many new shiny features that I would really like to use.

- Intermingled declarations with better locality of reference
- Exact-width integer types (we try to hack around this right now)
- New boolean data type (hacked around with our TRUE/FALSE macros)
- Variable length arrays (may be useful in future)
- Inline functions, to replace some macros in use
- New style comments (trivial, but useful)
- New library functions like 'snprintf' (used for quite some time)

Of course, right now the blocking issue is compiler support,
specifically from Microsoft. Both GCC and Clang support C99, except for
a few floating point operations, and so do a number of popular compilers
(Intel, maybe more).

> C++ has been touched on some.  I'd add that there are going to be more C
> programmers than C++ programmers, just on the basis that to know C++,
> you need to know C.  So by switching to C++, you may very lose some
> number of current or future potential developers.

Personally, I prefer C simply because I don't know C++ (yet). Aside from
greedy selfishness, I don't think a (partial) rewrite in C++ will be
useful. C++ has nice features, but our aging code has done fine without
so far.

>  So echoing some previous comments, I think gameplay should drive more
> new features.  I also think it would be helpful to express what the
> benefits of the changes are.

Right now there's no pressing feature that requires C++ in order to
implement. As far as I can see (which isn't very far) C is fine for the
job. Of course, I don't know what job this is, which means...

> In terms of roadmap, I think there were some out on the wiki.  But like
> most volunteer based projects, trying to stick to any such roadmap gets
> difficult - people tend to work on what they want to work on, and it may
> or may not match something on the roadmap.

It would be nice to sit down and come up with a roadmap. I've been doing
so much 'cleanup' work lately because I didn't have anything specific in
mind to work on.

Thanks,
Kevin Zheng