cl.exe and link.exe are both in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin on my laptop.
Opps, I missed that one. Exe and dll needs to be compiled with the same version of the compiler or
interesting stuff might happen with memory allocations. Allocated memory needs to be released using the same version of the compiler. If you mix and the dll releases memory allocated by the exe, then the game will develop really weird bugs. I highly recommend not even trying to do something like that.
This is why we all use a compiler from 2003. It's not because we love that compiler. We don't. It would be awesome to get the optimization from a modern compiler, but without dealing with tracking who allocates what, mixing compilers just isn't an option.
One thing that struck me as I looked at this was that on those lines, spaces rather than tabbing appears to be used at the start of the lines in question. If its anything like python, this would cause a problem.
There are programmers, who are bad at indenting. This isn't even that bad. I have seen much worse. The people developing python decided to use indenting for programming scopes in order to force programmers to indent correctly in order to write more readable code. Python is the odd language in that sense and other languages generally don't care. It's still bad not to indent correctly because it makes reading the code harder and hard to read code is more likely to hide bugs.
Changing the for loop as follows –
for (int iI = 0; iI < GC.getNumDamageTypeInfos(); iI++)
This one confuses me. It looks like the source code was developed without declaring int in the second loop, but it's not supposed to be able to compile if that happens. Maybe it used a compiler flag, which makes the compiler assume int if nothing is declared, but that sounds dangerous to me as it can hide bugs originating from typos. As annoying as it can be with a strict compiler, the main reason for making a compiler strict and not fix obvious mistakes is to avoid bugs. If you want bugfree code, you want a stupid compiler, which never assumes anything.
Vanilla has a tendency to declare int iI at the start of the functions, but it would be more correct to do it at the start of each loop. Declaring int in each loop means you tell the compiler you aren't interested in saving the value between the loops, which in turn in edge cases can make the compiler use the available registers more efficiently. However this kind of optimization is way too minor to bother fixing.
If you want to optimize where it makes a difference, cache output of GC.getDefineINT, like in CvCityAI::AI_buildingProductionValue
PHP:
int YieldValue=GC.getDefineINT("AI_BUILDINGVALUE_PRODUCTION");
Replace it with
PHP:
static const int YieldValue=GC.getDefineINT("AI_BUILDINGVALUE_PRODUCTION");
Making it static means it will only call the slow getDefineINT the first time and then it will reuse the value each time. Making it const protects against changing the value later. From a coding difficulty point of view, this seems to be the best way to optimize in a way, which actually makes a noticeable difference. In general getDefineINT is evil towards performance and should always be cached.
However optimization is a luxury problem and shouldn't be considered before you can compile reliably.