Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #8625 > unrolled thread

struct inside struct

Back to article view | Back to comp.lang.c

Contents

  struct inside struct arnuld <sunrise@invalid.address> - 2011-07-23 09:30 +0000
    Re: struct inside struct "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-23 04:32 -0700
      Re: struct inside struct Fonz <fonz@bogus.from.address.nl> - 2011-07-23 12:02 +0000
        Re: struct inside struct pete <pfiland@mindspring.com> - 2011-07-23 20:05 -0400
          Re: struct inside struct "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-24 01:20 -0700
      Re: struct inside struct Ike Naar <ike@iceland.freeshell.org> - 2011-07-24 10:27 +0000
        Re: struct inside struct "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-24 03:34 -0700

#8625 — struct inside struct

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

[toc] | [next] | [standalone]

#8628

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>

[toc] | [prev] | [next] | [standalone]

#8631

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

[toc] | [prev] | [next] | [standalone]

#8646

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

[toc] | [prev] | [next] | [standalone]

#8654

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.

[toc] | [prev] | [next] | [standalone]

#8655

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.

[toc] | [prev] | [next] | [standalone]

#8657

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web