Bob Ebert wrote:
> 
> At 6:49 PM -0800 4/1/99, Alex Robinson wrote:
> >GCC doesn't like "const RectanglePtr" (or the equivalent, "RecanglePtr
> >const") to be used in parameters that actually are given real, const
> >data.
> 
> Right, that's because "const RectanglePtr" is actualy the same as
> "RectangleType * const" -- that is, the pointer is being declared constant,
> NOT the thing it points to.
> 
> I started to create typedefs like ConstRectanglePtr that expand to
> "RectangleType const *" or "const RectangleType *" (they are equivalent),
> but I'm starting to think this is a huge waste of time, and what we should
> actally be doing is getting rid of RectanglePtr entirely and explicitly
> using "const RectangleType *" in the headers.
> 
> The only problem with _that_ is many of our types are intended to be
> opaque.  That is, you should not know the structure of a WindowType, and we
> can't make the Win... routines take a "WindowType *" paramater without
> exposing WindowType.
> 
> We _could_ make the Win... routines take a "void *" or "const void *"
> paramater, but then you lose a lot of type checking and will probably have
> to do funny casts.  ...I suppose we could typedef WindowType to void for
> this...
> 
> But anyway, that puts us back to having a public "WindowPtr" type that's
> passed around as a cookie outside of the OS, and _that_ means we have to
> create a "ConstWindowPtr" type for the cases where it's constant.   <sigh>
> 
>                                 --Bob

Over that last few years I've changed my own code to "opaque" pointers.
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;


I love the style. In a way, it's better than C++. There is just no
question about what code can access the data inside the structure. But
compilers typically don't like the syntax above and you have to do all
sorts of bogus tricks to make a single piece of such code compile
cleanly under a wide variety of compilers. Too bad.

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!

Oh well.

Thanks,

Alex Robinson
[EMAIL PROTECTED]

-eom-

Reply via email to