Members in a struct

[arnuld]

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) ?

 

[Giacomo Degli Esposti]

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

 

[Barry Schwarz]

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]

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").

 

[Eric Sosman]

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.

 

[Giacomo Degli Esposti]

On May 18, 3:31 am, Giacomo Degli Esposti

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

 

[CBFalconer]

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

 

[squeamz]

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.

 

[Guest]

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.

 

[BartC]

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

 

[JosephKK]

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?

 

[Eric Sosman]

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.

 

[JosephKK]

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.

 

[Antriksh Pany]

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').