Thanks for your response!

Quote Originally Posted by amleto View Post
why cant
quint16 rgb[3]
be protected and in CORE?
Normally I would just make a class that encapsulates every possible combination and be done with it, drastically simplifying my code. The problem rests in the problem of scale—when you have an extra 60 bytes (more or less) per record floating around, and around 6,000,000 records, that's an extra 343MB that I need to drag around. I'm already pushing the available memory as it is, so my intent is to only include RGB/TIME/ALPHA when the records actually have that data.

Quote Originally Posted by amleto View Post
If you put members variables into CORE, then you need to inherit CORE virtually, to avoid the dreaded diamond.
Can you please elaborate on this? I'm not a programmer by training, so I'm unfamiliar with some of the lingo. Also, what do you mean by inheriting it virtually? I've never been clear on the functional distinction between Protected and Private. If I make the prototyped member functions of CORE protected, then my generalized manipulation functions (using CORE* pointers, though the object pointed to will be A, B, C, or D depending on the data imported) throw a compiler error.