[Vegastrike-devel] command.cpp broken in MSVC6

[Claudio F. <kla...@gm...>]

I was merging CVS with my tree, and noticed that command.cpp is an ugly mes=
s=20
when compiling with MSVC 6.
It so happens that MSVC lacks a standard method: basic_string::clear().=20
Instead, basic_string::erase() must be used, but since command.cpp uses=20
clear() all around, it does not compile.
 But that's not all:
Lots of other errors (114 in total), mostly related to a common extension t=
o=20
the C++ language which conflicts with standard usage. Since MSVC has that=
=20
extension on by default, it doesn't compile. I found it simpler to make the=
=20
code compile with and without the extension, rather than reconfiguring MSVC=
:
 for (int i=3D1; i<10; i++) { ...do something... }
for (int i=3D1; i<20; i++) { ...do some other things... }
 Won't compile, since the declaration of i lives past the closing braces=20
(outside the controlled block). This, supposedly, is to be able to do thing=
s=20
like:
 for (int i=3D0; i<10 && buf[i] !=3D '\r'; i++) { ... }
buf[i] =3D 0;
 But, when you declare i again later, MSVC reports it as an error=20
(redefinition of i).
 There are two simple ways in which it can be fixed:
 int i;
 for (i=3D1; i<10; i++) { ...do something... }
for (i=3D1; i<20; i++) { ...do some other things... }
 However, this won't work if the two i have different types. Instead, I=20
prefer
  { for (int i=3D1; i<10; i++) { ...do something... } }
{ for (int i=3D1; i<20; i++) { ...do some other things... } }
 So simple... isn't it?
 But Wait! That's not All!
If you call in the next 10 minutes, we'll give you an additional bug!
 Somehow, moving the
#include <python/python_init.h>
(I think it was that)
to the beginning of main.cpp (on top of other includes) breaks csVector3. I=
=20
couldn't really find out why, and the only solution I could see was moving=
=20
the include back down. Strangely enough, that only happens after merging th=
e=20
changes for command.cpp and command.h. Must be a compiler bug. If the=20
include really has to be on top, please tell, and I'll try to solve it=20
somehow differently.
 I'm still fighting compiling errors, plus runtime errors.
When I get everything ticking, I'll commit the thing. There are lots of=20
optimizations that I've been adding, which, hopefully, will make asteroid=
=20
fields much more manageable.