Re: [GD-General] Compile times

[brian h. <bri...@py...>]

> I believe this has more to do with your experience in both languages 
> than anything else. You've huge experience writing C code, but (from 
> what I can infer) little experience working with large C++ codebases. 

That's not actually the case, I have significantly more time using C++ 
than C actually -- I started coding in C++ in 1989 and didn't actually 
switch "back" to ANSI C until 1995, then I switched back to C++ in 1999.

The problem is that I've used and "survived" C++ through several 
different shifts in conventional idiomatic usage.  When I first started 
using C++, inheritance was all the rage and templates didn't exist.  
You were supposed to use private inheritance to inherit an 
implementation and public inheritance to inherit an interface and/or 
implementation.  Then sometime in the late 90s, inheritance was moving 
away from popularity and it was time to switch to using generics (and 
you were now expected to use exceptions and RTTI was becoming 
formalized).  Except that no compiler had competent template 
implementations, and even today, MSVC 7 doesn't have partial template 
specialization.

So if anything, my problem is that I've used C++ too much because the 
language and its "proper" usage has shifted massively over the past 
decade+.

> What's worse, C++ can be badly used in more varied and obscure ways 
> than C or other simpler languages, and some design philosophies even 
> encourage these uses.

This is quite true, and if I had to list one single reason why C++ code 
across the board is a disaster, it would be this: there are no 
generally accepted idiomatic usage patterns for even the most basic 
things.  Every aspect of the language may or may not be used by a 
programmer, and you can have one person do it "right" and another 
person do it "right" and both of them completely and utterly not 
understand what the other is doing.

There are valid reasons to use multiple inheritance, templates, 
exception handling, operator overloading, STL, private inheritance, 
default arguments, non-virtual functions, factory methods with 
protected constructors/destructors, etc.  But there are also many valid 
reasons not to, and a lot of it boils down to philosophy.  Because C++ 
tried so hard to be philosophically agnostic, there is no right/wrong 
way.

Contrast this to a language like Eiffel, Objective-C or SmallTalk, 
where idioms WERE established, and those languages have a very clean 
feel to them compared to C++.  You understand what one person's Obj-C 
is supposed to be doing, whereas decoding another person's Obj-C is 
completely hit/miss depending on the amount of time you have and how 
much effort they spent into cleaning up their code.

Two pretty good books on these subjects: Objects Unencapsulated 
(written by a guy that likes Eiffel, but it's still a damn good take on 
modern OO languages) and Introduction to Object Oriented Programming by 
Timothy Budd.  The latter feels extremely unbiased and is also a good 
overview.

I don't actually have very deep hierarchies.  In fact, I think the 
deepest I have anywhere is three, but I'm not even sure I have one that 
deep.  The dependencies are due to aggregation and actual usage -- for 
example, my HPuzzleGame class probably uses about 20-30 different 
classes.  And some classes are implemented on assumptions about how 
other classes operate (yes, this breaks all manner of OOP, but 
unfortunately in the real world you don't know what you're abstracting 
until you're done writing code -- that's why going back and refactoring 
is so important).

Brian