Chris Antos wrote:
>
> >That is, the .H file contains something like this:
> >
> >typedef struct {
> > Byte dummy;
> > } A_THANG;
> >
> >
> >And the .C file does this:
> >
> >typedef struct {
> > int real_stuff;
> > long more_stuff;
> > Byte etc;
> > } A_THANG;
>
> yikes. for simple stuff, sure that may work. but having multiple
> definitions of the object does more than simply make its contents opaque.
> or, perhaps more accurately, it makes it so opaque as to be dangerous. for
> instance, sizeof simply does not work anymore. as i said, for simple
> straightforward stuff that's probably ok, as long as you are extremely
> rigorous. (if i can't make the compiler enforce something, i've learned the
> hard way to just not go there. i have no idea how you can enforce that
> noone calls sizeof on your A_THANG!!! so i would never do this except maybe
> in a very tiny project. but if it's so tiny, why bother with opacity?).
> i'm pretty sure there are real-life examples where this approach is not
> sound. if it works for you, more power to you. i'm a purist, though.
> (some people may say "but this is pure!". my response would be that it may
> be conceptually pure, but you cannot make the compiler enforce the
> conceptual purity at compile time, therefore it is not fully pure). hope
> that made sense.
>
By the way, first thing, you define two functions that operate on
A_THANG's: new...() and delete...(). And, of course, to:
1) declare an A_THANG (not a pointer, an actual A_THANG),
2) pass a pointer to it to a routine that operates on A_THANG's,
is a gross bug, and very, very hard to mistakenly do. So sizeof() gets
you the size of the pointer. But, in fact, you don't know or care what
the size is. That's an example of the whole point. You have a .H file
with a list of routines. That's all you know and care about. You don't
even recompile your code when the contents of an A_THANG is changed.
Yes, it's easy to imagine instances where this doesn't work in practice.
(Sometimes you just gotta know how big something is. And sub-classing is
only done through putting a pointer to A_THANG into the sub-class
structure. Etc. Etc.) But in practice, what I've found is that the code
is extremely disciplined about what logic controls what data. This
eliminates extra thinking that I like to see gone. In practice, by a
factor of a 1000 (or something), the biggest drawback is that the scheme
confuses debuggers.
Chris, it has taken a long time (10 years since realizing that all of my
code didn't need to run on Z-80's and starting vague steps toward this
style) for me to have "settled" on this style, so I sure know that it's
not something that is a, "Yeah, sure. That's great!" The hard, slow way,
feet dragging, I've just found it to be pretty spiffy.
But, as they say, YMMV. :)
Alex Robinson
[EMAIL PROTECTED]
-eom-
