struct inside struct


A

arnuld

AIM: To learn how to put a struct inside a struct
WHAT I GOT: Success :)

WHY I PUT IT HERE: to get some suggestions, if there is anything that
can be improved.



#include <stdio.h>
#include <stdlib.h>
#include <string.h>


struct inside
{
char arr[10];
int num;
};

struct parent
{
struct inside member1;
struct inside* member2;
};


void print_parent_struct(struct parent s);
void print_parent_struct_p(struct parent* ps);

int main(void)
{
struct inside d, *pd;
struct parent p, *pp;

strcpy(d.arr, "struct");
d.num = -1;

p.member1 = d;
print_parent_struct(p);

pd = malloc(1 * sizeof *pd);
pp = malloc(1 * sizeof *pp);
if(NULL == pd || NULL == pp)
{
fprintf(stderr, "IN: %s @%d: Out of Memory\n", __FILE__, __LINE__);
exit(EXIT_FAILURE);
}

strcpy(pd->arr, "pointer");
pd->num = 100;

pp->member2 = pd;
print_parent_struct_p(pp);

free(pd);
free(pp);

return 0;
}



void print_parent_struct(struct parent s)
{
printf("arr = %s, num = %d\n", s.member1.arr, s.member1.num);
}

void print_parent_struct_p(struct parent* ps)
{
printf("arr = %s, num = %d\n", ps->member2->arr, ps->member2->num);
}

================== OUTPUT ==================

[[email protected] C]$ gcc -ansi -pedantic -Wall -Wextra struct-inside-struct.c
[[email protected] C]$ ./a.out
arr = struct, num = -1
arr = pointer, num = 100
[[email protected] C]$
 
Ad

Advertisements

K

Kleuskes & Moos

AIM: To learn how to put a struct inside a struct
WHAT I GOT: Success :)

WHY I PUT IT HERE:  to get some suggestions, if there is anything that
can be improved.
<snip>

Only a _very_ minor nitpick.
void print_parent_struct(struct parent s);
void print_parent_struct_p(struct parent* ps);

Put the implementation here and loose the forward declarations. They
aren't really neccessary and thus introduce a dependency for no good
reason. In small programs such as this, it's trivial, but if your
programs become larger, this does become a point.

<snip>
 
F

Fonz

Kleuskes said:
Put the implementation here and loose the forward declarations.

Until some of the functions start calling each other and therefore
suddenly need to be defined in a particular order.

Function prototypes exist for a reason...

Fonz
 
K

Kleuskes & Moos

In that case, they are necessary (or at least yield an advantage) and
should not be omitted.
My preference is to write code in such a way
so that it is easy to modify.

In that case, it's best to avoid unnecessary dependencies, so you'll
have to change only _one_ thing, instead of _two_.
I like function prototypes.

Me, too. The bulk of functions i write do have prototypes and all but
those for static functions reside in the header.

I don't like unnecessary code, though, however much it pleases its
author. Introducing dependencies between various parts of the code
without any reason does not qualify as a "Good Thing" in my book.

Fortunately, it was only a _very_ minor nitpick.
 
I

Ike Naar

Put the implementation here and loose the forward declarations. They
aren't really neccessary and thus introduce a dependency for no good
reason. In small programs such as this, it's trivial, but if your
programs become larger, this does become a point.

The dependency is already there: it's the fact that a caller calls
a callee. If one tries to avoid forward declacations, the consequence
is that the definition of callee must precede the definition of caller.
If the program evolves and new "caller calls callee" dependencies arise,
it may be necessary to rearrange the function definitions.

If one uses forward declarations, the order of definition of caller and
callee is not restricted, but of course there is now duplication of the
function headers.

Looks like here's an example of the law of preservation of misery.
 
Ad

Advertisements

K

Kleuskes & Moos

The dependency is already there: it's the fact that a caller calls
a callee. If one tries to avoid forward declacations, the consequence
is that the definition of callee must precede the definition of caller.

That's one. I meant the other.
If the program evolves and new "caller calls callee" dependencies arise,
it may be necessary to rearrange the function definitions.

Yes. But I wasn't commenting the code that might evolve, i
commentented the code that was actually presented.
If one uses forward declarations, the order of definition of caller and
callee is not restricted, but of course there is now duplication of the
function headers.
Looks like here's an example of the law of preservation of misery.

:). Indeed.
 
Ad

Advertisements


Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Top