Quote:Original post by jollyjeffers
Agreed, but given a particular design it might not be possible to reduce the number of includes without changing the design. That was my point - changing the design to suit reduced compile time (etc..).
Well, I always try to keep the number of non allocated objects in classes as low as I can. It doesn't change the design, but it sometimes requires an allocation in the constructor. Pointer types don't need to be declared at all as long as the object is not exposed to it's functionality. And using this design keeps the visibility of other types as low as possible.
Quote:My point still stands - take a step back; do they really, and I mean REALLY, need access to implementation specifics? I can think of a number of ways I'd expose my API to a scripting language without revealing the internal/implementation details.
Well, no, they don't need absolute access in the script startup file. But doing so allows access outside of code to change Direct3D settings to values that aren't even available now. It's also very helpful if something doesn't work well with certain hardware. They can tweak values to anything, including values that I wouldn't even consider being needed. R7G9B8A8? Who knows. Way beside the point, though.
Quote:Quote:Original post by Kest
I had the format declared as an int, but then thought it might be a bit more safe to use the enum type.
This is the same as what I said regarding casting from a DWORD, but you responded with:Quote:I would rather forward the enum and use the actual underscored names.
So I'm confused [smile]
I'm saying that my original setup worked exactly like you're suggesting. But I'm pretty fond of enum types. I love types being declared with enum names, because it reduces the number of 'unknown' bland int types. You might even say I look at int or DWORD like a void pointer and enum named types like real type pointers.
void *myrug; // what does this point to?
rug *myrug; // Ahh, this is a rug object
int myrug; // huh?
RugType myrug; // ahh. Very obvious what this is. And the compiler will slap you around if you try to send an int in it's place. But if you cast ints to these, you've completely destroyed the point.
I've even declared enums for situatuons like this:
enum Val_RaceID { NOTHING_HERE; }
class Race
{
Val_RaceID FindRace(const char *name);
const char* GetRaceName(Val_RaceID id);
};
The only casting from int to RaceID takes place inside of the race class.
I've thought about other ways to accomplish this.
typedef int RaceID; won't work. It'll still let you send an int to the variable.
struct Val_RaceID { int RealID; }; is really messy.
Quote:As I hinted at before, I'd recommend grabbing a copy of Exceptional C++ - it's very cheap for a tech book and it covers some of the points you're raising.
It explains how to forward declare enums? That's what I need.
My character class requires suit objects, item inventories, animations, animation maps, AI control structures, input control structures, etc. I don't want to expose everything that sees my character to all of these internal object types. But what if I need to have an enum AI_CurrentTask variable declared in the character class? Or what if one of these enums types need sent to a character function? Even if it's a private function, it still needs forwarded to everything that knows my characters exist. I could declare as long or int, and then cast, but then I might as well not even name my enum.
