[Alephmodular-devel] 0.3 Progress update... ints done

[Br'fin <br...@ma...>]

Ok, in CVS I've managed to get nearly all shorts and longs sorted over  
to int16 and int32s so that we know they all have an explicit length.

0.3 is the target for all the simple but important changes to the  
codebase. While Chris has suggested classifying things, I don't know if  
we want to do a first pass now or within the first stages of 0.4

Things still on my plate:

LIMITING OF WARNINGS

I've loosened up a little from initial goals as some warnings (Like  
around function pointers in preferences.cpp) seem a little too  
ingrained to eradicate. But other areas should be possible. For  
instance, signed versus unsigned variable comparisons and warnings of  
junk at the end of pragma unused.

Dealing with all the existing warnings will make any new warnings that  
we cause so much more apparent.

Other things I would like some feed back on:

ENUMS

Certain Enums, such as the list of weapons in weapons.h strike me as  
candidates for being typedef'd types. Creating typedefs for enums like  
this one could enlist the compiler in making sure that reasonable  
values were past for these elements. On the flip side, I don't know  
what trouble this would cause if we wanted to have something that was  
one of these values or NONE (-1)

TYPECASTS

In general I would like to limit typecasts. Mainly because I was bitten  
by SetPort((GrafPtr)WindowPtr) during the initial carbonization. If we  
have to typecast, I'd prefer doing it C++ style casting mechanisms for  
a combination of clarity and letting the compiler catch more issues.

I'm going by advice in http://www.cs.rpi.edu/~wiseb/xrds/ovp3-1.html

For most cases we would be using static_cast. I'm not necessarily  
married to the idea, but I would like to enforce it for code changes in  
such areas.

NEW INSTEAD OF MALLOC

As part of limiting typecasts, I would prefer to use new[] over malloc  
to allow the compiler to give us pre-typed chunks of data. No  
typecasting needed. In the future, as we turn to classes instead of  
structures, we would also be able to have our constructors called.

OBSOLETE CODE REMOVAL

In the code we have, we currently have parts of coded surrounded by #if  
0, #ifdef NEW_AND_BROKEN, #ifdef OBSOLETE, #ifdef CYBERMAXX as well as  
code for Classic Mac APIS (Non-carbon) and Valkyrie video accelerators.

Chris suggested dumping all pre-carbon support. I myself am ambivalent,  
but I can't support it. I don't have the compilers for making a PPC  
MacOS 9 build, nevermind even attempting any kind of 68k build.

If you want or need MacOS 9 support, don't just ask for it, try to find  
someone to   get this project building under MacOS 9 and then ask this  
project to continue to support it. Now is the best time as I haven't  
tried to remove anything yet. So everything should still be available.

Obsolete code removal would also remove all of the mpw build files and  
the 68k assembler files.

OTHER IDEAS

Is there anything I haven't mentioned that fits the criteria for 0.3?  
Simple yet important changes which are best served by handling them now?

-Jeremy Parsons

--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------