From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: Register group proposal Date: Thu, 22 Feb 2001 11:02:00 -0000 Message-id: <1010222190206.ZM31735@ocotillo.lan> References: <3A95369F.98027202@cygnus.com> <200102221645.f1MGjUu03076@rtl.cygnus.com> <3A9547ED.E7CFE51C@cygnus.com> X-SW-Source: 2001-02/msg00306.html On Feb 22, 12:10pm, Andrew Cagney wrote: > > I've noticed, and I've spent time scratching my head over why structs are > > used in various places. > > A struct is a poor persons opaque object. But there are other ways to implement opaque objects and using typedef gives you the freedom to later change your mind about the implementation details without (also) having to change all of your declarations. E.g, regarding the pid/tid/lwp problem, the patch on the table uses struct ptid * as the opaque object. As we've discussed in the past, this has the problem of leaving dangling references in various places if you attempt to wipe out the current set of ptids. This problem may be solved via several different means. The object in question could be implemented via a struct instead of a pointer to a struct. Unfortunately, opaqueness is lost when you use this approach. (But this does have the advantage of simplicity.) Another approach to the problem (which does maintain opacity) is to represent the ptid as an int which which is an index or key into some other set of data structures that are maintained behind the scenes. This representation avoids the dangling reference problem because the accessors may validate the ptid (which, remember is a key) and do something appropriate (e.g, generate an internal error or simply return a canonical value) when the key is no longer valid. Anyway, the advantage of using typedef is that we can change the implementation at will. For example, we could start off with struct ptid; typedef struct ptid *ptid; And later on we could change our minds and do the following: typedef int ptid; /* ptid is an opaque handle which represents the various identifiers which may be used to represent an execution context. */ I agree that the use of typedef does cause you to have to be more careful with your includes, but I think we're giving up a very powerful facility by banning typedef.