Re: Register group proposal

[Kevin Buettner <kevinb@cygnus.com>]

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.