[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

struct inside struct

arnuld

7/23/2011 9:31:00 AM

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]$




--
www.lispmachine.wordpress.com
find my email-ID @above blog
6 Answers

Kleuskes & Moos

7/23/2011 11:33:00 AM

0

On Jul 23, 11:30 am, arnuld <sunr...@invalid.address> wrote:
> 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

7/23/2011 12:02:00 PM

0

Kleuskes & Moos wrote:

>> void print_parent_struct(struct parent s);
>> void print_parent_struct_p(struct parent* ps);
>
> 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

pete

7/24/2011 12:05:00 AM

0

Fonz wrote:
>
> Kleuskes & Moos wrote:
>
> >> void print_parent_struct(struct parent s);
> >> void print_parent_struct_p(struct parent* ps);
> >
> > 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...

My preference is to write code in such a way
so that it is easy to modify.

I like function prototypes.

--
pete

Kleuskes & Moos

7/24/2011 8:20:00 AM

0

On Jul 24, 2:05 am, pete <pfil...@mindspring.com> wrote:
> Fonz wrote:
>
> > Kleuskes & Moos wrote:
>
> > >> void print_parent_struct(struct parent s);
> > >> void print_parent_struct_p(struct parent* ps);
>
> > > 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.

In that case, they are necessary (or at least yield an advantage) and
should not be omitted.

> > Function prototypes exist for a reason...
>
> 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

7/24/2011 10:28:00 AM

0

On 2011-07-23, Kleuskes & Moos <kleuske@xs4all.nl> wrote:
> On Jul 23, 11:30?am, arnuld <sunr...@invalid.address> wrote:
>> 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.

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

7/24/2011 10:34:00 AM

0

On Jul 24, 12:27 pm, Ike Naar <i...@iceland.freeshell.org> wrote:
> On 2011-07-23, Kleuskes & Moos <kleu...@xs4all.nl> wrote:
>
> > On Jul 23, 11:30?am, arnuld <sunr...@invalid.address> wrote:
> >> 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.
>
> 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.