Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tdatirv!sarima From: sarima@tdatirv.UUCP (Stanley Friesen) Newsgroups: comp.lang.c Subject: Re: A dilemma with handles Message-ID: <4@tdatirv.UUCP> Date: 4 Oct 90 00:40:34 GMT References: Reply-To: sarima@tdatirv.UUCP (Stanley Friesen) Distribution: comp Organization: Teradata Corp., Irvine Lines: 52 In article markd@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 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)