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

[dutchgoldtony]

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

 

[Gordon Burditt]

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

 

[Mike Wahler]

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

 

[Jordan Abel]

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;

 

[Default User]

On 2005-11-14, Gordon Burditt <[email protected]> wrote:

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

 

[Gordon Burditt]

The above should be a struct _node *, not a 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

 

[Default User]

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

No, I don't think so.

I am not the original poster.

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

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

 

[Jordan Abel]

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.

 

[Default User]

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

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



Brian

 

[Jordan Abel]

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.

 

[Keith Thompson]

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.

 

[Default User]

different >> > from the resulting typedef, but others find it
promotes clarity. >> > Some dislike typedefs for structs, period.

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

 

[dutchgoldtony]

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]

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

 

[Michael Wojcik]

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.

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 (e-mail address removed)

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.

 

[Mike Wahler]

(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