Roots

My 2D game has rather high artwork requirements due to the size of some of our sprites. A few years ago I proposed that to make this process easier, we recruit some 3D artists who can make really basic animations, take frame captures, and then send them to the 2D artists to touchup and make it look like real pixel art. Unfortunately, we couldn't find a single person with skills in making 3D art that was interested in doing this type of work (for free anyway), so we had to abandon the idea and cut down our artwork requirements by a great deal. Basically, we re-use our map sprites in battle and increase their size by 4x. In the long run, I think this was actually the better option to take for our project as having a different set of sprites for maps versus battle was just too much for a free project like ours to handle.

I haven't touched multiple inheritance in a long time. My recommendation would be to avoid using multiple inheritance if you can, as it is pretty tricky, error-prone, and I would say is usually not worth the effort involved (ie an alternative design can meet your requirements just as well and will likely be easier to implement).

Does AppChild2 contain two instances of LibBase, or just one? I would think that you just want one instance of LibBase to do multiple inheritance correctly. I can't remember how the two super classes would share one instance of that base class, unfortunately. Does ordering the construction of the base classes in the AppChild2 constructor have any effect? Remember to use the access specifier for these base classes in your constructor, because if you just rely on them instantiating themselves using their no-arg constructors in the constructor body, I think that the order is not guaranteed (again, can't recall if this is the case). In other words:

AppChild2::AppChild2() :
   LibChild(),
   AppBase()
{
    // constructor body here
}

I dislike git because I find it has a really steep learning curve and it's command interface is not intuitive. I've used it a couple times in the past, but my sour experience could be biased because the project manager I was working for last made it harder to use than it should have been. I do fully acknowledge that git is more powerful than SVN and I do love the distributed nature of the system. I just haven't warmed up to it, and being told that "oh the documentation is so complete" doesn't really encourage me, since there are literally textbooks written just to explain how to use this tool. I don't want to read a textbook or sit through 2-3 hours of tutorial videos just to use a damn source control tool. I only want to know the minimal amount that I need to know to do 95-99% of the tasks that I will have to encounter day-to-day.

I'm interested in giving Mercurial a study, as it seems to offer most of the same primary advantages of git, but is more user friendly and easier to pick up and immediately start getting things done. My project is still using SVN for now, but eventually we'll be moving to either git or Mercurial when the time is right for us.

I dislike being called the "g" word as well, but I don't really think anyone has ever called me that because I can write computer programs. It usually was uttered in response to me being a graduate student in a prominent engineering school, or the fact that I enjoy reading and learning about scientific topics in my spare time and have books about theoretical physics on my bookshelf. I really don't feel I'm a genius in any sense. I'm just above average intelligence, work hard, and have a high degree of intellectual curiosity about a number of subjects.

I understand your argument and I agree with you. Ideally, I'd like to only forward declare what is necessary. We still receive some information about what is used in files based upon what header files are included by its corresponding source file (almost every header file has an accompanying source file in our project). This would further help if you structure your class/file organization to resemble Java, where one and only one class is allowed to be defined in any file.

So I do understand and appreciate the arguments made thus far against this practice. I still enjoy this practice it because it makes it so much easier to just #include "defs.h" and then not have to worry about declaration lists any further. I guess it's caused me to become a little bit lazy.