Circular references in declerations
Martin Weitzel
martin at mwtech.UUCP
Wed Feb 28 22:46:50 AEST 1990
In article <973 at philtis.cft.philips.nl> grant at cft.philips.nl (Joe Grant) writes:
>
>
>Calling all C gurus,
>
> A colleague of mine has run into the following problem.
> He needs to use the following declarations:
>
> typedef union {
> int *a;
> float *e;
> X *x;
> } Y
>
> typedef struct {
> int *d;
> .
> .
> .
> Y *y;
> }
X <---- missing here??
I assume the missing X, otherwise your question would not make sense
to me.
This particluar piece of code should *not* compile (at least not with
an ANSI-Compiler), as type X is unknown in the typedef for Y. If you
need circular dependencies, you must write this as follows:
typedef union uy { ..... ; struct sx *x; ..... } Y;
typedef struct sx { ..... ; union uy *y; ..... } X;
In the second line, I could have used 'Y' in place of 'union uy'
(and hence ommit the union-tag 'uy' in the first typedef), but in
the first typedef the use of 'struct sx *' is essential: A C-Compiler
will accept this kind of declaration, even if it does not know,
what a 'struct sx' will be at this time. Most compilers will *not*
accept a type (and hence a pointer to a type) in this situation,
if they do not know the type allready.
By tradition (%), name spaces for struct- and union-tags (uy, sx)
are separated from the name space for typedef-s (X, Y), so you
could in fact write.
typedef union Y { ..... ; struct X *x; ..... } Y;
typedef struct X { ..... ; union Y *y; ..... } X;
and of course could change the second line to
typedef struct X { ..... ; Y *y; ..... } X;
I don't know, if I should recommend to choose the same name
as struct/union-tag *and* typedef-d name. If you fully understand
the background, it saves remembering 'which is which', but for
the 'non-gurus' it might obscure the facts.
(%): C++ breaks with this tradition: A struct- or union-tag is
*automatically* a type name.
--
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83
More information about the Comp.lang.c
mailing list