Bob Ebert wrote:
> I started to create typedefs like ConstRectanglePtr [...]
> but I'm starting to think this is a huge waste of time, and what we
> should actally be doing is [...] explicitly using
> "const RectangleType *" in the headers.
I vote for (const FooType*) and not (ConstFooPtr) -- the latter doesn't
add clarity, it just throws more names in the global namespace.
I sort-of agree with the others who prefer (FooType*) over FooPtr in all
cases. Coming from Windows, the FooPtr style seemed horrible but I've
found those old Windows habits are finally dying off. Definitely if you
go with (const FooType*) then for consistency you should also use
(FooType*) for non-const values.
> we can't make the Win... routines take a "WindowType *" paramater
> without exposing WindowType.
This has been covered elsewhere in the thread -- in fact you >can< omit
the FooType definition and just forward-declare it without a body, and
then declare APIs using (FooType*).
Coming from Windows I was utterly shocked that >any< of these internal
structures were exposed (FormType, WindowType, etc) -- but now it's
actually handy to be able to view their internals in the debugger even
if you don't actually manipulate the internals with code.
> 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.
Please don't do anything that would reduce clarity and safety in
application code. I'd suggest only these minor tweaks or nothing.
-slj-
