A dilemma with handles

[Stanley Friesen]

In article <markd.654876849 at sunchat> markd at iti.org (Mark Delany) writes:
>
>Now my question relates to the definition of "handle".  Within the
>library this is simply a pointer to a structure that holds all the
>goodies necessary to achieve the results.
>...
>In other words, because the real definitions of "handle" is full of
>system dependencies, I want to define a *dummy* "handle" for the
>purposes of the user's view of the library - especially considering
>prototypes. 
>...
>Is the idea of defining a dummy definition acceptable or should I burden
>the user with the full definition?
>
>If a dummy definition *is* acceptable, then presumably I should define
>it as "void *".  Yes, no?

I think a dummy handle is probably a good idea (it will discourage users
from trying to depend on the implementation).   How to declare it is
difficult, since ANSI compliance is probably wanted.


What I did was something like this:

In the public header file:

	typedef struct str_tag_name handle_t;

	handle_t *xxopen();


That is I wnnet ahead and gave the users the *name* of the structure,
and, since pointers to structures can be declared given only the name,
the user does not actually need the full definition of the struct.

In the private header file (used by the package implementation):

	#include <public.h>

	struct str_tag_name {
		int	str_member;
		/* And so on, defining the struct	*/
	};

This gives the implementation the info it needs to do its work.  
The advantage is that no type punning is involved - everything is declared
properly according to its real type, but the implementation is still hidden.



-----------------------
uunet!tdatirv!sarima				(Stanley Friesen)