As I wrote in your
thread in the SDK subforum, it's amazing that a switch to a newer compiler is becoming feasible after all this time.
Doesn't surprise me that those templates don't readily compile. They seemed to stretch the boundaries of MSVC03 meta-programming; had to use some trial and error to work around apparent compiler bugs (crashes).
The enum map data structures in WtP and AdvCiv are tied to the systems for global enum types and to code for XML loading, serialization and loop constructs throughout the code. All this has diverged in both mods, and I estimate that adopting the current WtP framework would take me at least several weeks' spare time. WtP has come to rely on a Perl script for generating part of the C++ code. I did not like adding Perl to the dependencies/ tool chain for compiling the DLL and did not want to force XML modders to recompile the DLL. I also feel that the old compiler/ preprocessor alone can do the job (albeit barely) and that making all enum values available to the compiler (as WtP does through hardcoded enumerators) is not likely to acomplish great gains in performance. In BtS, that is; for Colonization, specifically WtP with it's large number of yield types, I tend to trust
@Nightinggale's assessent that his approach has significant performance benefits. Bearing in mind also WtP plans for further rewrites of Vanilla code and for novel features.
But i'am wondering about what advantages do these templates provide over c-arrays besides automatic memory management?
I have some free-form design documentation in the appendix of the
AdvCiv manual. I knew better what I was saying at the time of writing that (two years ago) than I do now, so I'll just copy the basic rationale: "
Memory optimization (for improved CPU cache performance); improved code readability, extensibility. Well, the enum map and traits code is highly reliant on templates and as such far from being easy to read; but the code that employs enum maps replaces a great volume of error-prone boilerplate dealing with naked arrays." I can of course expand on that, but I'm not sure what specific rationale you're missing – if any; perhaps "automatic memory management" already puts it neatly in a nutshell. Though the memory gets very tightly optimized to suit the characteristics of the data. (How essential that really is, is a different question.) If you want to skim through the existing documentation, it starts at the bottom of page 97 and continues to the end of page 101. Regarding the use of template parameters specifically, I think ease of use – less error-prone, more readable code – is the more important upside to me than compactness, e.g. storing the values of an enum-to-enum map in the smallest possible integer type internally.
For me at least, as the person most familiar with the AdvCiv enum-related code, modernizing the templates as much as necessary would seem like the less laborious and more desirable approach than adopting the current WtP code. That said, I'm not sure how easily I could set up the development environment, and I do have some reticence to put effort into porting AdvCiv to a modern version of C++ because a lot of things could clearly be done so much better in that environment. (Proper ranged-based loops that really make those clumsy int-enum casts and get...Info calls disappear are the first thing that comes to mind.) Feels like turning something that did its best under the circumstances into overtly cumbersome, inefficient legacy code. This is not a particularly rational stance, of course.
.
