Using an instance of a struct as a member of that struct

Discussion in 'C Programming' started by dutchgoldtony, Nov 14, 2005.

  1. Hi all,

    I was just wondering if this is possible. I'm trying to implement a
    viterbi decoder in C and am creating an array of nodes (the struct),
    and an array of pointers to nodes (the member I'm worried about)
    connecting to it like so:

    // snippet start
    typedef struct _node{
    char state[2]; // The state of each node ("00","01","10","11")
    int status ; // 1: Node is on potential path (exists), 0: not
    node* connectedNodes[2]; // Array of ptrs to nodes connected to
    this node
    int edgeCost[2]; // Cost of edges coming from nodes
    int cost; // Cost associated with node:
    } node;
    node n[4][maxDepth];
    //snippet end

    Is this line "node* connectedNodes[2];" legal?

    Thanks in advance for any help,
    Cheers, Tony
     
    dutchgoldtony, Nov 14, 2005
    #1
    1. Advertising

  2. >I was just wondering if this is possible.

    No, you cannot have an instance of a struct as a member of that
    struct. Assuming that the struct has at least one other member,
    that would require infinite memory.

    You can, however, have a *pointer* to the struct as a member of
    that struct. This is common with linked lists.

    >I'm trying to implement a
    >viterbi decoder in C and am creating an array of nodes (the struct),
    >and an array of pointers to nodes (the member I'm worried about)
    >connecting to it like so:
    >
    >// snippet start
    >typedef struct _node{
    > char state[2]; // The state of each node ("00","01","10","11")
    > int status ; // 1: Node is on potential path (exists), 0: not
    > node* connectedNodes[2]; // Array of ptrs to nodes connected to


    The above should be a struct _node *, not a node *.
    You haven't defined the typedef 'node' yet.

    >this node
    > int edgeCost[2]; // Cost of edges coming from nodes
    > int cost; // Cost associated with node:
    >} node;
    >node n[4][maxDepth];
    >//snippet end
    >
    >Is this line "node* connectedNodes[2];" legal?


    No. Not in context.

    Gordon L. Burditt
     
    Gordon Burditt, Nov 14, 2005
    #2
    1. Advertising

  3. dutchgoldtony

    Mike Wahler Guest

    "dutchgoldtony" <> wrote in message
    news:...
    > Hi all,
    >


    Re: Using an instance of a struct as a member of the struct

    > I was just wondering if this is possible.


    Of course not, and with a bit of thought, you should realize why.
    But that's not what you're trying to do in your code below.

    > I'm trying to implement a
    > viterbi decoder in C and am creating an array of nodes (the struct),
    > and an array of pointers to nodes (the member I'm worried about)
    > connecting to it like so:
    >
    > // snippet start
    > typedef struct _node{
    > char state[2]; // The state of each node ("00","01","10","11")
    > int status ; // 1: Node is on potential path (exists), 0: not
    > node* connectedNodes[2]; // Array of ptrs to nodes connected to
    > this node
    > int edgeCost[2]; // Cost of edges coming from nodes
    > int cost; // Cost associated with node:
    > } node;
    > node n[4][maxDepth];
    > //snippet end
    >
    > Is this line "node* connectedNodes[2];" legal?


    What did your compiler say? Anyway, yes it's legal.
    The member 'connectedNodes' is not an array of
    type 'struct _node' objects, but an array of type
    'struct _node *' (pointer to 'struct _node') objects.

    Reminder:
    When you populate that array with pointers, be sure
    it contains addresses of valid objects (i.e. you must
    either allocate or define those objects somewhere first,
    and if you allocate them, don't forget to free them
    when you're done with them).

    -Mike
     
    Mike Wahler, Nov 14, 2005
    #3
  4. dutchgoldtony

    Jordan Abel Guest

    On 2005-11-14, Gordon Burditt <> wrote:
    >>I was just wondering if this is possible.

    >
    > No, you cannot have an instance of a struct as a member of that
    > struct. Assuming that the struct has at least one other member,
    > that would require infinite memory.
    >
    > You can, however, have a *pointer* to the struct as a member of
    > that struct. This is common with linked lists.
    >
    >>I'm trying to implement a
    >>viterbi decoder in C and am creating an array of nodes (the struct),
    >>and an array of pointers to nodes (the member I'm worried about)
    >>connecting to it like so:
    >>
    >>// snippet start
    >>typedef struct _node{
    >> char state[2]; // The state of each node ("00","01","10","11")
    >> int status ; // 1: Node is on potential path (exists), 0: not
    >> node* connectedNodes[2]; // Array of ptrs to nodes connected to


    >
    > The above should be a struct _node *, not a node *.
    > You haven't defined the typedef 'node' yet.


    no, it shouldn't be struct _node *
    it should be struct node *.

    typedef struct node {
    ...
    struct node *connectedNodes[2];
    ...
    } node;

    > No. Not in context.
    >
    > Gordon L. Burditt
     
    Jordan Abel, Nov 14, 2005
    #4
  5. dutchgoldtony

    Default User Guest

    Jordan Abel wrote:

    > On 2005-11-14, Gordon Burditt <> wrote:



    > > The above should be a struct _node *, not a node *.
    > > You haven't defined the typedef 'node' yet.

    >
    > no, it shouldn't be struct _node *
    > it should be struct node *.


    Depends on your definition of "should". What Gordon had was perfectly
    legal. Some people object to having a tag name different from the
    resulting typedef, but others find it promotes clarity. Some dislike
    typedefs for structs, period.



    Brian
     
    Default User, Nov 14, 2005
    #5
  6. >> > The above should be a struct _node *, not a node *.
    >> > You haven't defined the typedef 'node' yet.

    >>
    >> no, it shouldn't be struct _node *
    >> it should be struct node *.

    >
    >Depends on your definition of "should".


    I believe the point being brought up here is namespace issues.

    >What Gordon had was perfectly


    I am not the original poster.

    >legal.


    No, I don't believe it was. You can't use a typedef before
    it's defined, and it's not defined until the *END* of the
    definition.

    typedef struct foo {
    ...
    foo *x;
    ...
    } foo;
    isn't going to work. If you replace "foo *x;" with "struct foo *x;",
    it will.

    >Some people object to having a tag name different from the
    >resulting typedef, but others find it promotes clarity. Some dislike
    >typedefs for structs, period.


    Gordon L. Burditt
     
    Gordon Burditt, Nov 14, 2005
    #6
  7. dutchgoldtony

    Default User Guest

    Gordon Burditt wrote:

    > >> > The above should be a struct _node *, not a node *.
    > >> > You haven't defined the typedef 'node' yet.
    > >>
    > >> no, it shouldn't be struct _node *
    > >> it should be struct node *.

    > >
    > > Depends on your definition of "should".

    >
    > I believe the point being brought up here is namespace issues.


    No, I don't think so.

    > > What Gordon had was perfectly

    >
    > I am not the original poster.


    I know, you posted the original correct which changed the interior
    declaration to struct _node *.

    > > legal.

    >
    > No, I don't believe it was. You can't use a typedef before
    > it's defined, and it's not defined until the END of the
    > definition.


    Please reread the thread, and Jordan's comments.

    > typedef struct foo {
    > ...
    > foo *x;
    > ...
    > } foo;
    > isn't going to work. If you replace "foo *x;" with "struct foo *x;",
    > it will.


    Who said it would?

    Like I said, reread the thread, you've misinterpreted my remarks
    entirely.



    Brian
     
    Default User, Nov 14, 2005
    #7
  8. dutchgoldtony

    Jordan Abel Guest

    On 2005-11-14, Default User <> wrote:
    > Jordan Abel wrote:
    >
    >> On 2005-11-14, Gordon Burditt <> wrote:

    >
    >
    >> > The above should be a struct _node *, not a node *.
    >> > You haven't defined the typedef 'node' yet.

    >>
    >> no, it shouldn't be struct _node *
    >> it should be struct node *.

    >
    > Depends on your definition of "should". What Gordon had was perfectly
    > legal. Some people object to having a tag name different from the
    > resulting typedef, but others find it promotes clarity. Some dislike
    > typedefs for structs, period.


    His use of the identifier "_node" is not legal.
     
    Jordan Abel, Nov 14, 2005
    #8
  9. dutchgoldtony

    Default User Guest

    Jordan Abel wrote:

    > On 2005-11-14, Default User <> wrote:


    > > Depends on your definition of "should". What Gordon had was
    > > perfectly legal. Some people object to having a tag name different
    > > from the resulting typedef, but others find it promotes clarity.
    > > Some dislike typedefs for structs, period.

    >
    > His use of the identifier "_node" is not legal.


    Oh, right. That's reserved in tag name space as well as file scope.



    Brian
     
    Default User, Nov 15, 2005
    #9
  10. dutchgoldtony

    Jordan Abel Guest

    On 2005-11-15, Default User <> wrote:
    > Jordan Abel wrote:
    >
    >> On 2005-11-14, Default User <> wrote:

    >
    >> > Depends on your definition of "should". What Gordon had was
    >> > perfectly legal. Some people object to having a tag name different
    >> > from the resulting typedef, but others find it promotes clarity.
    >> > Some dislike typedefs for structs, period.

    >>
    >> His use of the identifier "_node" is not legal.

    >
    > Oh, right. That's reserved in tag name space as well as file scope.


    I thought it was reserved everywhere full stop. Because even block scope
    names could collide with an internal name used in a macro expansion.
     
    Jordan Abel, Nov 15, 2005
    #10
  11. "dutchgoldtony" <> writes:
    > I was just wondering if this is possible. I'm trying to implement a
    > viterbi decoder in C and am creating an array of nodes (the struct),
    > and an array of pointers to nodes (the member I'm worried about)
    > connecting to it like so:
    >
    > // snippet start
    > typedef struct _node{
    > char state[2]; // The state of each node ("00","01","10","11")
    > int status ; // 1: Node is on potential path (exists), 0: not
    > node* connectedNodes[2]; // Array of ptrs to nodes connected to
    > this node
    > int edgeCost[2]; // Cost of edges coming from nodes
    > int cost; // Cost associated with node:
    > } node;
    > node n[4][maxDepth];
    > //snippet end
    >
    > Is this line "node* connectedNodes[2];" legal?


    There's been some confusion about who said (or meant) what, so I'll
    summarize.

    You shouldn't declare identifiers starting with "_"; many of them are
    reserved for use by the implementation. There are some rules that
    depend on what the following character is, but there's little point in
    memorizing the details (I haven't); just avoid leading underscores
    altogether, and you'll be fine.

    Using "//" comments in Usenet postings is not recommended. They're
    legal in C99 (and a common extension in pre-C99 compilers), but
    wraparound can cause the end of a comment to appear on a line by
    itself, making the code illegal. The older (and still supported)
    "/* ... */" comments don't have this problem. In your case, the lines
    haven't wrapped (at least in my news client), but they're overly long;
    please limit your text to about 72 columns.

    You can't have an instance of a struct as a member of that struct (the
    resulting struct would be infinite in size), but you can have a
    pointer to a struct as a member of the struct, which is what you're
    trying to do here.

    It's common to declare both a struct tag and a typedef for the same
    type, and it's perfectly legal to use the same identifier for both.
    But the typedef name can't be used before its declaration, which comes
    at the end of the struct declaration.

    Here's your declaration with the layout cleaned up and the identifier
    "_node" changed to "node":

    typedef struct node {
    char state[2];
    int status;
    node *connectedNodes[2]; /* illegal, "node" is undeclared */
    int edgeCost[2];
    int cost;
    } node;

    The name "node" doesn't exist yet when you try to use it. You can either
    use the struct tag:

    typedef struct node {
    char state[2];
    int status;
    struct node *connectedNodes[2];
    int edgeCost[2];
    int cost;
    } node;

    or you can declare the typedef using an incomplete type:

    typedef struct node node;

    struct node {
    char state[2];
    int status;
    node *connectedNodes[2];
    int edgeCost[2];
    int cost;
    };

    But the best solution, IMHO, is to drop the typedef altogether:

    struct node {
    char state[2];
    int status;
    struct node *connectedNodes[2];
    int edgeCost[2];
    int cost;
    };

    and use the full name "struct node" whenever you want to refer to this
    type. Hiding the full name behind a typedef does two things: it saves
    you a few keystrokes (which is *not* much of a benefit), and it hides
    the fact that the type is a structure. The latter can be useful if
    you're creating some kind of abstract data type, but that doesn't
    appear to be the case here; if the code that uses this type is going
    to refer to its members, it has to know that it's a struct anyway, and
    hiding that fact just obfuscates the code.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Nov 15, 2005
    #11
  12. dutchgoldtony

    Default User Guest

    Jordan Abel wrote:

    > On 2005-11-15, Default User <> wrote:
    > > Jordan Abel wrote:
    > >
    > >> On 2005-11-14, Default User <> wrote:

    > >
    > >> > Depends on your definition of "should". What Gordon had was
    > >> > perfectly legal. Some people object to having a tag name

    > different >> > from the resulting typedef, but others find it
    > promotes clarity. >> > Some dislike typedefs for structs, period.
    > >>
    > >> His use of the identifier "_node" is not legal.

    > >
    > > Oh, right. That's reserved in tag name space as well as file scope.

    >
    > I thought it was reserved everywhere full stop. Because even block
    > scope names could collide with an internal name used in a macro
    > expansion.


    No, double underscore or underscore followed by an uppercase letter are
    reserved in all contexts. You could use _node as a struct member name
    without causing a problem. I had to look up the rules (as usual).
    That's why it often recommended just not to use a leading underscore so
    there's error.



    Brian

    --
    Please quote enough of the previous message for context. To do so from
    Google, click "show options" and use the Reply shown in the expanded
    header.
     
    Default User, Nov 15, 2005
    #12
  13. Thanks for clearing that up, and for the posting pointers! That should
    give me a bit to go on.

    Cheers for the help,
    Tony
     
    dutchgoldtony, Nov 15, 2005
    #13

  14. > struct node {
    > char state[2];
    > int status;
    > struct node *connectedNodes[2];
    > int edgeCost[2];
    > int cost;
    > };
    >
    > and use the full name "struct node" whenever you want to refer to this
    > type. Hiding the full name behind a typedef does two things: it saves
    > you a few keystrokes (which is *not* much of a benefit), and it hides
    > the fact that the type is a structure. The latter can be useful if
    > you're creating some kind of abstract data type, but that doesn't
    > appear to be the case here; if the code that uses this type is going
    > to refer to its members, it has to know that it's a struct anyway, and
    > hiding that fact just obfuscates the code.



    If I am trying to refer to that member of the struct:
    "> struct node *connectedNodes[2];"
    where I would have previously (albeit wrongly) have said, for example:
    "n[j].connectedNodes[0] = &(n[0][j+1])"
    should I now say:
    "struct n[j].connectedNodes[0] = &(n[0][j+1])"
    Do I have to add anything extra for the fact that connected nodes is a
    struct within a struct or will this do.

    Thanks again,
    Tony
     
    dutchgoldtony, Nov 15, 2005
    #14
  15. In article <>, "Default User" <> writes:
    > Jordan Abel wrote:
    > > On 2005-11-15, Default User <> wrote:
    > > > Jordan Abel wrote:
    > > >>
    > > >> His use of the identifier "_node" is not legal.
    > > >
    > > > Oh, right. That's reserved in tag name space as well as file scope.

    > >
    > > I thought it was reserved everywhere full stop.


    Not quite. 7.1.3 in C90 or C99:

    - All identifiers that begin with an underscore and either an
    uppercase letter or another underscore are always reserved
    for any use.

    - All identifiers that begin with an underscore are always
    reserved for use as identifiers with file scope in both
    the ordinary and tag name spaces.

    So "_Node" is reserved anywhere, but "_node" isn't if it's not at
    file scope. (That includes the tag name space, which is always at
    file scope.)

    Since implementations aren't required to distinguish case among
    identifiers with external linkage (C90 6.1.2), it could be argued
    that even at block scope, an identifier with a leading underscore and
    lowercase name with external linkage is reserved, or should be.

    > > Because even block
    > > scope names could collide with an internal name used in a macro
    > > expansion.


    They could, but the standard doesn't reserve single-underscore-and-
    lowercase-letter identifiers for that. If the implementation wants
    to use reserved identifiers in the text of a macro, it should use
    identifiers beginning with two underscores, presumably.

    > No, double underscore or underscore followed by an uppercase letter are
    > reserved in all contexts. You could use _node as a struct member name
    > without causing a problem. I had to look up the rules (as usual).
    > That's why it often recommended just not to use a leading underscore so
    > there's error.


    (That's "no chance for error", presumably.) I agree, though some
    seem to like to use identifiers with a leading underscore and
    lowercase letter in macro replacement text (for user-written macros,
    not ones provided by the implementation). That's legal as long as
    the macro isn't used to generate a tag name or a file-scope
    identifier.

    --
    Michael Wojcik

    He smiled and let his gaze fall to hers, so that her cheek began to
    glow. Ecstatically she waited until his mouth slowly neared her own.
    She knew only one thing: rdoeniadtrgove niardgoverdgovnrdgog.
     
    Michael Wojcik, Nov 16, 2005
    #15
  16. dutchgoldtony

    Mike Wahler Guest

    "Michael Wojcik" <> wrote in message
    news:...

    > (That's "no chance for error", presumably.) I agree, though some
    > seem to like to use identifiers with a leading underscore and
    > lowercase letter in macro replacement text (for user-written macros,
    > not ones provided by the implementation). That's legal as long as
    > the macro isn't used to generate a tag name or a file-scope
    > identifier.


    All these 'complicated' rules and their implications just
    underscore :) the validity of the 'best practice' advice:
    "Leading underscores: Just Say No."

    -Mike
     
    Mike Wahler, Nov 16, 2005
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. DJ Dev
    Replies:
    3
    Views:
    16,244
    Gandalf
    Feb 8, 2004
  2. 0to60
    Replies:
    4
    Views:
    544
    jeffc
    Nov 21, 2003
  3. Angus Comber
    Replies:
    7
    Views:
    1,200
    Richard Heathfield
    Feb 5, 2004
  4. Chris Fogelklou
    Replies:
    36
    Views:
    1,444
    Chris Fogelklou
    Apr 20, 2004
  5. pete142
    Replies:
    5
    Views:
    466
    Ben Bacarisse
    Jan 23, 2008
Loading...

Share This Page