>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.
>If you are taking votes, though, I vote for getting rid of the ...Ptr
>things (in new types, not in the existing ones). Putting Ptr at the end
>of a word is too Hungarianesque and, heck, it's not like typing
>"Rectangle *" is harder than "RectanglePtr". And it could be argued that
>the former is easier on the eyes!
Hungarian style notations can be extremely useful if they are used
correctly. not everyone likes it, but personally i find it invaluable.
