Members in a struct

Discussion in 'C Programming' started by arnuld, May 18, 2009.

  1. arnuld

    arnuld Guest

    I have some basic questions about a C struct. Here is a struct my friend
    has created:


    struct my_struct
    {
    char ID[20];
    char name[20];
    char message[100];

    struct a_queue* p;
    struct a_singly_linked_list* p2;
    struct a_binary_tree* p3;
    unsigned long long uc;

    int num;
    int num_max;
    int num_finished;
    int num_current;

    struct my_struct* next;
    }


    The structured he created actually had 19 members in total. It looked like
    a mess to me, So I thought grouping related members in a new struct will
    be a good idea. Hence I modified it to look like this:


    struct my_struct_modified
    {
    struct info* info;
    struct ds* ds;
    struct nums* nums;

    struct my_struct_modified* next;
    }


    struct info
    {
    char ID[20];
    char name[20];
    char message[100];
    }


    struct ds
    {
    struct a_queue* p;
    struct a_singly_linked_list* p2;
    struct a_binary_tree* p3;
    unsigned long long uc;
    }


    struct nums
    {
    int num;
    int num_max;
    int num_finished;
    int num_current;
    }



    Before I represent this to my team I want to know if its a good idea. is
    it ? Will it be messy in fetching the values of pointers in a struct
    inside a struct ?


    2nd, increasing the members in a struct (say 19 members) will make the
    program run slower as compared to say (10 members) ?



    --
    www.lispmachine.wordpress.com
    my email is @ the above blog.
     
    arnuld, May 18, 2009
    #1
    1. Advertising

  2. On 18 Mag, 12:00, arnuld <> wrote:
    > I have some basic questions about a C struct. Here is a struct my friend
    > has created:
    >
    > struct my_struct
    > {

    [...]
    > }
    >
    > The structured he created actually had 19 members in total. It looked like
    > a mess to me, So I thought grouping related members in a new struct will
    > be a good idea. Hence I modified it to look like this:
    >
    > struct my_struct_modified
    > {

    [...]
    > }
    >
    > struct info
    > {

    [...]
    > }
    >
    > struct ds
    > {

    [...]
    > }
    >
    > struct nums
    > {

    [...]
    > }
    >
    > Before I represent this to my team I want to know if its a good idea. is
    > it ? Will it be messy in fetching the values of pointers in a struct
    > inside a struct ?


    Are you planning to replace the old struct with your new version or to
    work with both together?
    In both cases, for different reasons, I don't think it's a good idea.
    If you replace the original struct, all your code must be changed to
    cope
    with the nesting structs:

    struct my_struct x;
    ....
    x.num = 10;

    must be changed to:

    struct my_struct_modified
    ...
    x.nums.num = 10;

    by the way, this will not save any space: your struct is still 19
    elements.

    If you think the struct is a mess maybe you'd better use comments to
    make clear to the other that there are three different parts:

    struct my_struct
    {
    /* general info */
    ....
    /* pointers to data structures */
    ....
    }


    > 2nd, increasing the members in a struct (say 19 members) will make the
    > program run slower as compared to say (10 members) ?


    Well... it's not a matter of how many members but how big is the
    struct,
    (a struct with 19 1-char members can be smaller than a struct with 10
    long int members) but I think I understand what you mean!

    I think it depends on your compiler. In theory it could get a little
    slower
    because if struct variables are passed and returned copying them in a
    stack then more cpu cycles will be necessary to do it.

    I don't know if a good compiler in this case will not copy the struct
    directly and use a hidden reference making no real difference between
    the two cases.

    Anyway I dont' think it's a good idea to worry about performance of
    these compiler-dependant matters, just look after your algorithms! :)

    ciao
    Giacomo
     
    Giacomo Degli Esposti, May 18, 2009
    #2
    1. Advertising

  3. On May 18, 3:31 am, Giacomo Degli Esposti
    <> wrote:
    > On 18 Mag, 12:00, arnuld <> wrote:
    >
    >
    >
    >
    >
    > > I have some basic questions about a C struct. Here is a struct my friend
    > > has created:

    >
    > > struct my_struct
    > > {

    > [...]
    > > }

    >
    > > The structured he created actually had 19 members in total. It looked like
    > > a mess to me, So I thought grouping related members in a new struct will
    > > be a good idea. Hence I modified it to look like this:

    >
    > > struct my_struct_modified
    > > {

    > [...]
    > > }

    >
    > > struct info
    > > {

    > [...]
    > > }

    >
    > > struct ds
    > > {

    > [...]
    > > }

    >
    > > struct nums
    > > {

    > [...]
    > > }

    >
    > > Before I represent this to my team I want to know if its a good idea. is
    > > it ? Will it be messy in fetching the values of pointers in a struct
    > > inside a struct ?

    >
    > Are you planning to replace the old struct with your new version or to
    > work with both together?
    > In both cases, for different reasons, I don't think it's a good idea.
    > If you replace the original struct, all your code must be changed to
    > cope
    > with the nesting structs:
    >
    > struct my_struct x;
    > ...
    >   x.num = 10;
    >
    > must be changed to:
    >
    > struct my_struct_modified
    > ..
    >   x.nums.num = 10;


    It is worse than that. In the new scheme, nums is a pointer. First
    he must insure the pointer points to a struct. Then the syntax
    becomes
    x.nums->num = 10;

    >
    > by the way, this will not save any space: your struct is still 19
    > elements.


    Actually, it consumes more space. Each of the original 19 members is
    still a member of some structure somewhere. But now he has all those
    pointers.
     
    Barry Schwarz, May 18, 2009
    #3
  4. On May 18, 3:00 am, arnuld <> wrote:
    > I have some basic questions about a C struct. Here is a struct my friend
    > has created:
    >
    > struct my_struct
    > {
    >   char ID[20];
    >   char name[20];
    >   char message[100];
    >
    >   struct a_queue* p;
    >   struct a_singly_linked_list* p2;
    >   struct a_binary_tree* p3;
    >   unsigned long long uc;
    >
    >   int num;
    >   int num_max;
    >   int num_finished;
    >   int num_current;
    >
    >   struct my_struct* next;
    >
    > }
    >
    > The structured he created actually had 19 members in total. It looked like
    > a mess to me, So I thought grouping related members in a new struct will


    19 members is not really that large a count.

    > be a good idea. Hence I modified it to look like this:
    >
    > struct my_struct_modified
    > {
    >   struct info* info;
    >   struct ds* ds;
    >   struct nums* nums;


    Why did you make these pointers? To obtain the desired grouping,
    struct info info;
    seems to work and eliminates the need to manage the pointers. Of
    course, for this to work you need to declare your innermost structures
    first. That is so by the time you delcare my_struct the compiler
    knows how big each of the member structures is.

    >
    >   struct my_struct_modified* next;
    >
    > }
    >
    > struct info
    > {
    >   char ID[20];
    >   char name[20];
    >   char message[100];
    >
    > }
    >
    > struct ds
    > {
    >   struct a_queue* p;
    >   struct a_singly_linked_list* p2;
    >   struct a_binary_tree* p3;
    >   unsigned long long uc;
    >
    > }
    >
    > struct nums
    > {
    >   int num;
    >   int num_max;
    >   int num_finished;
    >   int num_current;
    >
    > }
    >
    > Before I represent this to my team I want to know if its a good idea. is
    > it ? Will it be messy in fetching the values of pointers in a struct
    > inside a struct ?


    The compiler won't mind but it will make for some ugly code:
    x.nums->num if you use pointers
    x.nums.num if you imbed the structures directly
    All other things being equal, I would rather have a "messy" structure
    and cleaner code than the reverse.

    >
    > 2nd, increasing the members in a struct (say 19 members) will make the
    > program run slower as compared to say (10 members) ?


    I would be surprised if there was any change in time with imbedded
    structures. On the other hand, if you use pointers, every access will
    require executable code to dereference the pointer (though some of
    that code may be optimized away if you access the lowest level
    elements "efficiently").
     
    Barry Schwarz, May 18, 2009
    #4
  5. arnuld

    Eric Sosman Guest

    arnuld wrote:
    > I have some basic questions about a C struct. Here is a struct my friend
    > has created:
    >
    >
    > struct my_struct
    > {
    > char ID[20];
    > char name[20];
    > char message[100];
    >
    > struct a_queue* p;
    > struct a_singly_linked_list* p2;
    > struct a_binary_tree* p3;
    > unsigned long long uc;
    >
    > int num;
    > int num_max;
    > int num_finished;
    > int num_current;
    >
    > struct my_struct* next;
    > }
    >
    >
    > The structured he created actually had 19 members in total. It looked like
    > a mess to me, So I thought grouping related members in a new struct will
    > be a good idea. Hence I modified it to look like this:
    >
    >
    > struct my_struct_modified
    > {
    > struct info* info;
    > struct ds* ds;
    > struct nums* nums;
    >
    > struct my_struct_modified* next;
    > }
    >
    >
    > struct info
    > {
    > char ID[20];
    > char name[20];
    > char message[100];
    > }
    >
    >
    > struct ds
    > {
    > struct a_queue* p;
    > struct a_singly_linked_list* p2;
    > struct a_binary_tree* p3;
    > unsigned long long uc;
    > }
    >
    >
    > struct nums
    > {
    > int num;
    > int num_max;
    > int num_finished;
    > int num_current;
    > }
    >
    >
    >
    > Before I represent this to my team I want to know if its a good idea. is
    > it ? Will it be messy in fetching the values of pointers in a struct
    > inside a struct ?


    "Messy" is hard to quantify, but it will certainly be
    "more verbose." There's also the matter of managing memory
    to hold the information: Your friend's struct is one blob
    of memory, allocated by one definition or one malloc() call.
    Yours requires four distinct blobs of memory separately
    allocated, plus some initialization to set the pointers of
    the "master" struct appropriately.

    > 2nd, increasing the members in a struct (say 19 members) will make the
    > program run slower as compared to say (10 members) ?


    As you should have learned a long time ago, questions of
    speed are difficult to answer except by measurement, and even
    measurement is highly situational. Still, I'll go out on a
    limb and hazard a guess: On a "typical" system under "normal"
    conditions, a program that stores its data in instances of
    your modified struct and its descendants is "likely" to be
    slower than one that uses "your friend's" struct. YMMV.

    --
    Eric Sosman
    lid
     
    Eric Sosman, May 18, 2009
    #5
  6. On 18 Mag, 13:40, Barry Schwarz <> wrote:
    > On May 18, 3:31 am, Giacomo Degli Esposti
    > > struct my_struct_modified
    > > ..
    > >   x.nums.num = 10;

    >
    > It is worse than that.  In the new scheme, nums is a pointer.  First
    > he must insure the pointer points to a struct.  Then the syntax
    > becomes
    >    x.nums->num = 10;


    Ouch! You are right! I didn't read the OP message carefully enough!
    I read it like he declared some structs and not pointers to structs.
    Sorry for my error.

    ciao
    Giacomo
     
    Giacomo Degli Esposti, May 18, 2009
    #6
  7. arnuld

    CBFalconer Guest

    arnuld wrote:
    >

    .... snip ...
    >
    > The structured he created actually had 19 members in total. It
    > looked like a mess to me, So I thought grouping related members
    > in a new struct will be a good idea. Hence I modified it to look
    > like this:


    Who knows. It depends on your system. Bear this in mind: any
    malloced object requires some added space for the malloc system to
    keep track of it. That space can vary from about 4 to about 16
    octets (bytes). If you break a single structure into two, you have
    two such units of control space used. If you break it into four,
    you have four such units used. Etc.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.
     
    CBFalconer, May 19, 2009
    #7
  8. arnuld

    Guest

    On May 18, 3:00 am, arnuld <> wrote:
    > I have some basic questions about a C struct. Here is a struct my friend
    > has created:
    >
    > struct my_struct
    > {
    >   char ID[20];
    >   char name[20];
    >   char message[100];
    >
    >   struct a_queue* p;
    >   struct a_singly_linked_list* p2;
    >   struct a_binary_tree* p3;
    >   unsigned long long uc;
    >
    >   int num;
    >   int num_max;
    >   int num_finished;
    >   int num_current;
    >
    >   struct my_struct* next;
    >
    > }
    >
    > The structured he created actually had 19 members in total. It looked like
    > a mess to me, So I thought grouping related members in a new struct will
    > be a good idea. Hence I modified it to look like this:
    >
    > struct my_struct_modified
    > {
    >   struct info* info;
    >   struct ds* ds;
    >   struct nums* nums;
    >
    >   struct my_struct_modified* next;
    >
    > }
    >
    > struct info
    > {
    >   char ID[20];
    >   char name[20];
    >   char message[100];
    >
    > }
    >
    > struct ds
    > {
    >   struct a_queue* p;
    >   struct a_singly_linked_list* p2;
    >   struct a_binary_tree* p3;
    >   unsigned long long uc;
    >
    > }
    >
    > struct nums
    > {
    >   int num;
    >   int num_max;
    >   int num_finished;
    >   int num_current;
    >
    > }
    >
    > Before I represent this to my team I want to know if its a good idea. is
    > it ? Will it be messy in fetching the values of pointers in a struct
    > inside a struct ?


    This is a design question. First, there is no single correct answer
    to this type of question. Second, my opinion is that your own
    experience is the only real authority in these matters. It's very
    natural to ask these questions, but I believe you'll find every answer
    you receive--including this one--unsatisfactory. All anyone can
    really do is give you advice in very general terms. Hopefully, that
    advice will lead you in the right direction in your learning. My
    advice is to never put very much stock in someone's design advice.

    That being said, my general "zen-101" response is to look at the
    clients of this struct. Do you need to pass pointers to an instance
    of struct info, struct ds, or struct nums to any functions? Or is
    struct my_struct fully atomic? The benefit of well-designed
    structures is that it makes it easier to distribute the relevant
    information to the parts of your code that need it. If you can't
    identify any part of the code that directly benefits from dividing
    this struct into smaller parts, and cannot imagine a likely future
    requirement that would make this change beneficial, then my advice is
    to leave it alone--don't change anything.

    Of course, it's impossible to know what changes will eventually be
    necessary, so--as I said--this type of advice is worse than worthless :
    (.

    And, as others have mentioned, storing pointers to the sub-structs
    rather than containing the structs themselves, doesn't make sense to
    me given the context you provided. Perhaps it's a good idea in your
    program, but my gut feeling is that you should lose the "*"s.
     
    , May 19, 2009
    #8
  9. arnuld

    Guest

    On 18 May, 11:00, arnuld <> wrote:

    > The structured he created actually had 19 members in total. It looked like
    > a mess to me, So I thought grouping related members in a new struct will
    > be a good idea.


    there is a struct on a project I have access to that has 179 items.
    But most people agree this is WRONG.
     
    , May 19, 2009
    #9
  10. arnuld

    BartC Guest

    "arnuld" <> wrote in message
    news:p...
    >I have some basic questions about a C struct. Here is a struct my friend
    > has created:
    >
    >
    > struct my_struct
    > {
    > char ID[20];
    > char name[20];
    > char message[100];
    >
    > struct a_queue* p;
    > struct a_singly_linked_list* p2;
    > struct a_binary_tree* p3;
    > unsigned long long uc;
    >
    > int num;
    > int num_max;
    > int num_finished;
    > int num_current;
    >
    > struct my_struct* next;
    > }
    >
    >
    > The structured he created actually had 19 members in total. It looked like
    > a mess to me, So I thought grouping related members in a new struct will
    > be a good idea. Hence I modified it to look like this:


    The original struct seems fine. There's nothing wrong with having 19
    elements, and splitting into several structs makes it harder to comprehend,
    especially when it means using double field selections (a.b.c instead of
    a.b) and extra pointer dereferencing.

    If you wanted to tidy up, you could nest the new structs actually inside the
    original, and without using pointers:

    struct my_struct
    {
    struct info {
    char ID[20];
    char name[20];
    char message[100];
    } info;
    struct ds {
    struct a_queue* p;
    struct a_singly_linked_list* p2;
    struct a_binary_tree* p3;
    unsigned long long uc;
    } ds;
    struct nums {
    int num;
    int num_max;
    int num_finished;
    int num_current;
    } nums;

    struct my_struct* next;
    }

    If you like extra pointers, you can turn the fixed length strings here with
    char * flexible strings, especially message[].

    --
    Bart
     
    BartC, May 20, 2009
    #10
  11. arnuld

    JosephKK Guest

    On Mon, 18 May 2009 08:03:51 -0400, Eric Sosman
    <> wrote:

    >arnuld wrote:
    >> I have some basic questions about a C struct. Here is a struct my friend
    >> has created:
    >>
    >>
    >> struct my_struct
    >> {
    >> char ID[20];
    >> char name[20];
    >> char message[100];
    >>
    >> struct a_queue* p;
    >> struct a_singly_linked_list* p2;
    >> struct a_binary_tree* p3;
    >> unsigned long long uc;
    >>
    >> int num;
    >> int num_max;
    >> int num_finished;
    >> int num_current;
    >>
    >> struct my_struct* next;
    >> }
    >>
    >>
    >> The structured he created actually had 19 members in total. It looked like
    >> a mess to me, So I thought grouping related members in a new struct will
    >> be a good idea. Hence I modified it to look like this:
    >>
    >>
    >> struct my_struct_modified
    >> {
    >> struct info* info;
    >> struct ds* ds;
    >> struct nums* nums;
    >>
    >> struct my_struct_modified* next;
    >> }
    >>
    >>
    >> struct info
    >> {
    >> char ID[20];
    >> char name[20];
    >> char message[100];
    >> }
    >>
    >>
    >> struct ds
    >> {
    >> struct a_queue* p;
    >> struct a_singly_linked_list* p2;
    >> struct a_binary_tree* p3;
    >> unsigned long long uc;
    >> }
    >>
    >>
    >> struct nums
    >> {
    >> int num;
    >> int num_max;
    >> int num_finished;
    >> int num_current;
    >> }
    >>
    >>
    >>
    >> Before I represent this to my team I want to know if its a good idea. is
    >> it ? Will it be messy in fetching the values of pointers in a struct
    >> inside a struct ?

    >
    > "Messy" is hard to quantify, but it will certainly be
    >"more verbose." There's also the matter of managing memory
    >to hold the information: Your friend's struct is one blob
    >of memory, allocated by one definition or one malloc() call.
    >Yours requires four distinct blobs of memory separately
    >allocated, plus some initialization to set the pointers of
    >the "master" struct appropriately.
    >
    >> 2nd, increasing the members in a struct (say 19 members) will make the
    >> program run slower as compared to say (10 members) ?

    >
    > As you should have learned a long time ago, questions of
    >speed are difficult to answer except by measurement, and even
    >measurement is highly situational. Still, I'll go out on a
    >limb and hazard a guess: On a "typical" system under "normal"
    >conditions, a program that stores its data in instances of
    >your modified struct and its descendants is "likely" to be
    >slower than one that uses "your friend's" struct. YMMV.


    Gosh all this and no one yet mentioned that with pointers you will be
    using malloc() and free() all the time. Can you say performance hit
    or memory leak or both?
     
    JosephKK, May 26, 2009
    #11
  12. arnuld

    Eric Sosman Guest

    JosephKK wrote:
    > On Mon, 18 May 2009 08:03:51 -0400, Eric Sosman
    > <> wrote:
    >
    >> arnuld wrote:
    >>> I have some basic questions about a C struct. Here is a struct my friend
    >>> has created:
    >>>

    >> [...] Your friend's struct is one blob
    >> of memory, allocated by one definition or one malloc() call.
    >> Yours requires four distinct blobs of memory separately
    >> allocated, [...]
    >>
    >> [...] Still, I'll go out on a
    >> limb and hazard a guess: On a "typical" system under "normal"
    >> conditions, a program that stores its data in instances of
    >> your modified struct and its descendants is "likely" to be
    >> slower than one that uses "your friend's" struct. YMMV.

    >
    > Gosh all this and no one yet mentioned that with pointers you will be
    > using malloc() and free() all the time. Can you say performance hit
    > or memory leak or both?


    Direct your attention to the two quoted fragments.

    --
    Eric Sosman
    lid
     
    Eric Sosman, May 26, 2009
    #12
  13. arnuld

    JosephKK Guest

    On Tue, 26 May 2009 07:44:37 -0400, Eric Sosman
    <> wrote:

    >JosephKK wrote:
    >> On Mon, 18 May 2009 08:03:51 -0400, Eric Sosman
    >> <> wrote:
    >>
    >>> arnuld wrote:
    >>>> I have some basic questions about a C struct. Here is a struct my friend
    >>>> has created:
    >>>>
    >>> [...] Your friend's struct is one blob
    >>> of memory, allocated by one definition or one malloc() call.
    >>> Yours requires four distinct blobs of memory separately
    >>> allocated, [...]
    >>>
    >>> [...] Still, I'll go out on a
    >>> limb and hazard a guess: On a "typical" system under "normal"
    >>> conditions, a program that stores its data in instances of
    >>> your modified struct and its descendants is "likely" to be
    >>> slower than one that uses "your friend's" struct. YMMV.

    >>
    >> Gosh all this and no one yet mentioned that with pointers you will be
    >> using malloc() and free() all the time. Can you say performance hit
    >> or memory leak or both?

    >
    > Direct your attention to the two quoted fragments.


    Eh, OK. Close enough to not bother arguing about it.
     
    JosephKK, May 29, 2009
    #13
  14. A minor point, though not really applicable to the current example:

    If variables are grouped together to form many nested structs within a
    struct, padding due to alignment may increase, thus bloating the size
    of the struct a little. This is because, now each nested struct will
    itself be aligned on the appropriate word boundary.
    The above of course does not hold if struct alignment is not being
    done on byte boundaries (i.e., when structs are 'packed').
     
    Antriksh Pany, Jun 10, 2009
    #14
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. JFCM
    Replies:
    4
    Views:
    5,778
  2. CoolPint
    Replies:
    8
    Views:
    1,027
    Jeff Schwab
    Dec 14, 2003
  3. Dave
    Replies:
    3
    Views:
    384
    tom_usenet
    Aug 10, 2004
  4. Chris Fogelklou
    Replies:
    36
    Views:
    1,438
    Chris Fogelklou
    Apr 20, 2004
  5. John Reye
    Replies:
    28
    Views:
    1,412
    Tim Rentsch
    May 8, 2012
Loading...

Share This Page