Ok I would prefer to have small pragrams (apart from the main program) to unit test with.
Should these be collected in a directory called 'test'? or something akin to that?
What I'm getting at is
make test
<much compiling>
ISO test
<various test information displaced>
ISO FS test
<more test information about reading file data and reading file sizes etc>These can return information that can cause make test to fail (which is a good idea)
Also it allows each unit section to be tested when someone changes something to be sure it works acording to spec.
This is how I discovered a bug in my ISO structure information under Linux I'm not sure if it does the same thing under windows or not.
I'm trying to comply with some sort of 'standard' we need too use throughout the coding process to test things. It may seem picky but I've attempted to wade through bugs before and it's best to test everything that needs testing in each unit so the bug is swated before a bug becomes an unfindable flaw.
The next thing is Peer Code Review of the code.
This has saved my backside.. and I think we do need it. (See i++/++i and vector class discussion).
When it comes to STL I'm weak. I predate STL (period) so I will have to learn it now I suppose (mutter)
In fact I predate Template usage in C++
That being said.. we should be careful with C++ constructors and destructors as well as inheiritance usage.
Porting to certain platforms will be made impossible if you rely on any static objects and the compilor to create them in some sane sequence.
(Palm OS is one such animal for example).
This again is why Peer review might be valuable. It's not about trust it's more about making sure the code works without later major revisions on several platforms. Obviously PC's will be the first platforms to run it, (Linux Windows et al). Even porting to winCE make require some important changes. It's best not to paint ourselves into the proverbial corner and have to tear out the floor.
Cyb