struct inside struct

[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 ==================

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

 

[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>

 

[Fonz]

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

 

[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.

 

[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.

 

[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.