Ok, I've completed the actual "merge" part for the trunk, but I'm afraid it didn't go very well. For whatever reason, the merge wanted to go back a long way. don't think I did a very good job, as a whole, with this merge. I think that what I should have done was to just run svn merge --record-only and used kdiff3 to merge each file myself. The result appears that I have accidentally introduced changes that were later reverted, and I'm sorry. I'm going to try to make sure that I get all of these corrected, but just keep an eye out for anything like this as you work with the code. Either way, I'm cleaning it up now an I always learn from my mistakes (especially the painful ones!).
And speaking of pain, because I wanted to get this out of the way, I have moved
glest_map_editor and
glest_game to
map_editor and
game, respectively. As soon as I get it building again, I'll commit and post to this thread again.
And now I want to note a few things, some changes that I've reverted because I disagree with them. You guys have done some amazing work while I was absent! At the same time, some stuff went to "hell in a hand basket" as it were, with regard to conventions (we've discussed a lot of this before). This is largely my fault, not just for not being able to be there for a long time, but for not having thoroughly documented project conventions before. I have to say that having spent a *lot* of time last year trying to get the code formatted to a certain standard added to my frustration to find a lot of it changed to something else.
Enough of my griping though, these are the issues.
As always, if somebody disagrees with the technical accuracy or efficacy of any of these points, PLEASE speak your mind! I am certainly not perfect and have learned much from working with you guys already!!
I realize that I am fairly OCD about code formatting, and that's probably mostly just because I spent so much time trying to re-format it before.
(But I don't actually have OCD. I do have CDO, though. It's a lot like OCD, but just with the letters in alphabetical order, as they aught to be.)
- Never inline constructors that seem simple (e.g., GameSettings default ctor) when it has a lot of data members. The reason for this is even though the source code is very brief, the generate code has to have constructors for each data member. If these constructors are in turn inlined (like std::string) then the size continues to grow, making these very bad candidates for inline. Remember also that with compilers, like gcc, that do not yet have support for cross-object optimizations (a.k.a., "whole program optimizations") that if the compiler refused to inline something (which it can) it will create a static copy of that function in each object file where it refuses to inline it, thus continuing to bloat the app even further.
- In general, try to keep in mind the lack of cross-object optimizations on gcc. I saw one function that silnarm outlined that I don't blame you for (it was kinda big and if it isn't really high-use, then sure, out-line it), but others that would lead to slower code on gcc.
- I noticed that the tinyxml sources were included in the tree. Please never add sources to an external project that's supposed to be a dependency, unless we decide that we *really* want to do that, and the only reason I can think of is because we want to alter their code. The proper way to do this is to modify the Jamfile, configure.ac, etc. so that any needed include directories are included (-Ixxx CPPFLAGS) and the libraries are linked in (-Lxxx and -lxxx added to LDFLAGS). I'm not highly skilled with the m4 language and I tend to wait for others to do this part, but hard-coding these values (as they work on your system) into Jamrules is better than including their sources in our tree.
I'll be adding to the above list as I go. =)
