Re: Register group proposal

[Jim Kleck <jim.kleck@NetergyNet.COM>]

A consistent interface is *one* reason to have a particular interface.
However, it is not the only thing to consider, nor have the "style
advantages and disadvantages" been fully explored... at least not
in this forum.

I would note that "struct blah *" is NOT fully opaque. Its very use implies
a control structure of some sort, and it is quite different from the standard
types provided by the language. Thus it is not using the full "extensability"
of the language.

An alternative I have not seen discussed is to have "typedef void * blah"
as the public interface (then the implementation would need to cast
the object to the internal representation before operating on it).

Finally, in the "LONGEST" example, why replace "a = b + c;" with
"a = add(b, c);". My inclination would be to overload the "+" so that
no change to the users of the type are necessary.

JimK


Andrew Cagney wrote:

> Nick Duffek wrote:
> > But prohibiting typedefs ....
>
> When implementing an ``object'', I'm asking that it be done in a way
> that is consistent with other recent additions to gdb - that is
> blah.[hc] defines an opaque ``struct blah *''.  (As a style its
> advantages and disadvantages have probably now been beaten to death :-)
>
> While it does implicitly put a restriction on the use of typedefs in
> certain header files, it is not a prohibition of typedef.
>
> If someone feels that they have concerns when defining a specific
> interface then I would assume that that person will also put those
> concerns forward.  In doing this they may well demonstrate a possible
> need to implement their interface in a way that is different to the
> above.
>
> To give an example, consider LONGEST.  One day that type will need to be
> extended beyond 64 bits (long long).  When that happens, it might be
> done with something like:
>         defs.h:
>           struct longest {
>             something_goes here;
>           };
>           typedef struct longest LONGEST;
> Among the rationale would be the observation that LONGEST is a self
> contained lightweight.  You could try to implement it as a ``struct
> longest *'' but it would make memory management a nightmare while
> showing very few advantages.  Being able to perform the mechanical
> replacement:
>         a = b + c;
>   with  a = add (b, c);
> would be of much greater benefit.  (See sim/common/sim-fpu.[hc].)
>
>         Andrew