>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.
the only thing i'm saying is not ideal about your style is that you actually
fill in the body of A_THANG with Byte dummy. i'm saying if you simply do
this:
struct A_THANG;
you get the opacity you want, but you also get fully compiler enforcement of
it. for instance, you'll get a compile-time error if you trying to use
sizeof(). or if you try to declare a variable of that type.
you yourself complained that you have to do a bunch of hacks and tricks to
get the compiler to accept your style. by making this very small change,
you simply improve your style. by the way, this is an extremely common
thing to do. it's basically the standard way to make a structure opaque,
and it has full compiler support, with no additional tricks or anything.
what i've found from hard experience is that when you add new hires to a
group, anything that cannot be enforced by the compiler gets violated by the
new hires. sometimes the product gets shipped with subtle bugs from stuff
like that. i guess my point of view comes from working on a large product
with over 60 other developers.
