[TEST] C++ conversion

[Frost]

I would also like feedback regarding which version of gcc or clang you are using - particularly, whether anyone other than Frost is still using gcc 4.4

Debian stable uses GCC 4.4.

Cygwin includes gcc 4.5.3, but fails to compile. Tested on 32-bit WinXP.

$ make
GNUmakefile:78: deps.make: No such file or directory
bison -d -o src/map/magic-interpreter-parser.cpp src/map/magic-interpreter-parser.ypp
flex -o src/map/magic-interpreter-lexer.cpp src/map/magic-interpreter-lexer.lpp
for F in `find src/ -name '*.cpp'`; do \
g++ -m32 -std=c++0x -MM "$F" -MT "$(sed 's/src/${BUILD_DIR}/;s/\.cpp/.o/' <<< "$F")"; \
done > deps.make
mkdir -p obj/login/
g++ -m32 -std=c++0x -pipe -g -O2 -fstack-protector -fno-strict-aliasing -c -o obj/login/login.o src/login/login.cpp
In file included from src/login/login.cpp:27:0:
src/login/../common/db.hpp: In constructor ‘db_key_t::db_key_t(numdb_key_t)’:
src/login/../common/db.hpp:26:34: warning: ‘db_key_t::ms’ is deprecated (declared at src/login/../common/db.hpp:22)
src/login/../common/db.hpp: In constructor ‘db_key_t::db_key_t(const char*)’:
src/login/../common/db.hpp:27:35: warning: ‘db_key_t::ms’ is deprecated (declared at src/login/../common/db.hpp:22)
src/login/login.cpp: In function ‘int search_account_index(char*)’:
src/login/login.cpp:430:57: error: ‘strcasecmp’ was not declared in this scope
src/login/login.cpp: In function ‘void parse_fromchar(int)’:
src/login/login.cpp:1721:62: error: ‘strcasecmp’ was not declared in this scope
src/login/login.cpp: In function ‘void parse_login(int)’:
src/login/login.cpp:3850:68: error: ‘strcasecmp’ was not declared in this scope
src/login/login.cpp: In function ‘int login_lan_config_read(const char*)’:
src/login/login.cpp:4143:42: error: ‘strcasecmp’ was not declared in this scope
src/login/login.cpp: In function ‘int login_config_read(const char*)’:
src/login/login.cpp:4262:46: error: ‘strcasecmp’ was not declared in this scope
GNUmakefile:28: recipe for target `obj/login/login.o' failed
make: *** [obj/login/login.o] Error 1

[Frost]

As there have been no reports of trouble I pushed this to master.

Waiting a week for complaints is far from a robust testing regime. This was hastily pushed.
Until this has been properly tested, I have no confidence that such extensive changes are ready for the main server.

[o11c]

Why does it need to be build with 32-bit?

Because TMWA is full of evil C code that casts between pointers and integers.

Fixing this is on my list of things worth doing, far above the requirement of a little-endian system.

[o11c]

Cygwin includes gcc 4.5.3, but fails to compile. Tested on 32-bit WinXP.

src/login/login.cpp:430:57: error: ‘strcasecmp’ was not declared in this scope

It's actually a C-related problem, easily fixed by

Code: Select all

#include <strings.h>

Since I can't reproduce this myself, can you add this to the relevant files?
I try to keep the headers sorted (though for history they're not), so after #include <string.h> (which happens to be the header that sometimes declares strcasecmp)

[Doofus]

In order to have a codebase that I can hack in, I need to get rid of the nasty C code that makes up tmwa.

I might be jumping in not knowing the full picture of the codebase but this seems to be a little on the extreme side. There is a mutually compatible clean c subset of both c and c++ and it is a lot closer to c than c++. I would imagine a "clean-up" would be a lot easier than a full conversion and also allow developers from the c camp easier access to contributing to the code. Also considering that reversing the process (converting c++ code to good c code) is even more difficult a process, the fact that it is already in c is a point in tmwa's favour w.r.t. future-proofing against how things may chage.

Because TMWA is full of evil C code that casts between pointers and integers.

As a possibility, glib provides portable functionality for storing integers as pointers and casting between them (yes the other way around definitely doesn't make for good c code). It also provides a very good relacement for the string library based functions that often can go wrong or are not portable.

[o11c]

I might be jumping in not knowing the full picture of the codebase but this seems to be a little on the extreme side. There is a mutually compatible clean c subset of both c and c++ and it is a lot closer to c than c++.

C is a nasty language because the onus of making sure the code does what you want is entirely on you. By writing in C++, much of the difficulty is shifted to the compiler.
In C++, I *never* have to worry about freeing pointers when I'm done with them, or keeping a dangling pointer after it has been freed - the standard library classes take care of that for me. (For example: as far as I can tell, over 1000 bytes of memory are leaked every time a spell is cast. Unfortunately, the magic system is tied to flex/bison which does not allow the use of safe C++ classes)
Pretty much the only thing I have to remember is to never remember the value of a pointer (or reference) function argument after the function returns - which is really easy to do.

As a possibility, glib provides portable functionality for storing integers as pointers and casting between them (yes the other way around definitely doesn't make for good c code). It also provides a very good relacement for the string library based functions that often can go wrong or are not portable.

It's not difficult to safely cast between pointers and integers in new code - just use uintptr_t. However, if you need to do it at all, it's an indicator of bad design - you should instead use a template that can accept any data type.

(If you're interested in technical details, that's not the only 64-bit compatibility issue I've found. There are also assumptions about the copying of a va_list. Fortunately, getting rid of that is fairly easy - just use variadic templates and std::function)

[o11c]

V0id reports an issue with getarraysize on string arrays.

This is now fixed. I restarted the test server.