Re: Variable array sizes as members ?
On Sun, 19 Jul 2009 12:44:01 -0700, Robby
<Robby@discussions.microsoft.com> wrote:
Hello fellows,
I would like to thank every one of you for your help!
Sometimes its hard for me to explain what I am looking for because the
further I go the more I am getting trapped in a certain method of
programmtion. Its not the fact that I want to know how to do this or to do
that... it has now become can I do this and can I do that and fit it into the
project's coding architecture. That's why sometimes I want a certain help
from you guys but then I seem to be stuck in how to integrate the help or
the sample provided into the whole thing while following the established and
specific rules so it all works together. That being said,
If you would stop presenting code and instead describe the task to be
accomplished, you would get much more useful replies. Fixing poorly
designed or implemented code just enough so it works leaves it just as
poorly designed or implemented.
Barry and Scott have talked about making my array member a pointer so it can
point to dynamic space and store my data there. Okay, I am sure this is the
way things should be done. But I will show you a a sample program and I don't
know where I would do the malloc for this. Maybe because I haven't shown a
cleare example yet and probably this is what is confusing me.
Note that it is not standard (and likely troublesome) to use the address of a local >stack array as a struct member. Just watch out for scope trouble there.
Somewhere along the line you have picked up some truly astounding
misinformation. Did you learn to code from an airline magazine
article?
Scott can let me know how scope trouble would be present in the sample code
I will be showing later on.
Alex, your solution seems to be the most conformant to well written code. I
will have to look into that. Thanks.
David, you have precisely answered my question, the help I was seeking was
exactly what you came up with and I tried it, fit into my project and it
compiles... I haven't tested it yet, but I am pretty sure it will work.
Here is my C code.... tested in VC++ and compiles without error.
==========================================
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
typedef struct tag_list60
{
long storage[60];
}list60;
typedef struct tag_list30
{
long storage[30];
}list30;
typedef struct tag_list10
{
long storage[10];
}list10;
typedef struct tag_lb_table
{
long lb_items[5];
struct tag_list10 *x;
struct tag_list30 *y;
struct tag_list60 *z;
}lb_table;
typedef struct tag_lb
{
struct tag_lb_table *dc;
//...other members here
}lb;
// Other parameters passed in this function are not shown!
lb* create_obj(
lb *obj_lb,
What is uncommon in my experience is to have a pointer name with a
prefix that implies it is the object pointed to. At least obj_lb does
point to an object of type lb but the naming convention is still
weird. Almost every where else it would be called ptr_lb.
What is even more uncommon is to pass a value into a function that you
have no intention of using. This function would work just as well if
obj_lb were defined as a local variable.
lb_table *lb)
So now pointer lb does not point to an object of type lb. You must
really enjoy confusing us.
{
obj_lb = malloc (sizeof (struct tag_lb_table));
And as a result you have shot yourself in the foot. Apparently you
confused yourself as well. obj_lb must point to an object of type lb
which is the same type as struct tag_lb. But you did not allocate
space for an object of type struct tag_lb. You allocated space for an
object of type struct tag_lb_table.
Fix one: Change all your calls to malloc to match the form
obj_lb = malloc(sizeof *obj_lb);
Fix two: If you go to the trouble of defining a typedef, use it
instead of the long-winded struct syntax.
Fix three - a matter of style: Drop the useless tag_ prefix. Structure
tags are in a separate namespace so there is never any danger of
conflict with object and function names or even typedef names. I
would also drop the useless obj_ prefixes (unless you start using
others like ptr_ and arr_ which I also don't care for).
obj_lb->dc = lb;
//...Other setups here not shown
return obj_lb;
}
store_to_eeprom(lb *objLb, int eeprom_bank)
Did you really mean for this function to return an int. If so,
specify it. If not, don't let the compiler assume it.
{
// funtion which stores storage
// informations to eeprom
}
int main()
{
lb MyRef3;
lb *objLb1 = &MyRef3;
If you have the correct type, initialization works fine.
list10 storage10[10]; // Up to 10 MAX
list30 storage30[30]; // Up to 30 MAX
list60 storage60[60]; // Up to 60 MAX
It is very strange that a structure that can old n longs should need
an array of exactly n elements. You are aware that no matter what
number you place in the brackets, each element of storage10 can hold
exactly ten longs. Similarly for the other two.
lb_table lb_arr[] = {
{ 185, 184, 183, 0, 0, storage10, NULL, NULL},
{ 111, 211, 0, 0, 0, NULL, storage30, NULL,},
{ 185, 200, 43, 22, 150, NULL, NULL, storage60},
{ 185, 22, 243, 0, 0, NULL, NULL, NULL},
{ 10, 20, 0, 0, 0, NULL, storage30, NULL,},
{ 1, 222, 200, 0, 0, NULL, NULL, NULL},
{ 85, 4, 204, 11, 28, NULL, NULL, NULL},
{ 1, 0, 0, 0, 0, NULL, NULL, NULL},
{ 15, 27, 43, 99, 0, NULL, NULL, NULL},
};
objLb1 = create_obj(objLb1, lb_arr);
objLb1 used to point to MyRef3. Since you did not make use of that,
one has to wonder why you bothered. As noted above, it is unnecessary
to pass values to a function that the function can never use.
// So I can do stuff like this!
// For 10 MAX
objLb1->dc[0].x->storage[0] = 201;
objLb1->dc[0].x->storage[1] = 501;
//...
objLb1->dc[0].x->storage[9] = 21;
store_to_eeprom(objLb1, 0);
// For 30 MAX
objLb1->dc[1].y->storage[0] = 64;
objLb1->dc[1].y->storage[1] = 78;
//...
objLb1->dc[1].y->storage[29] = 521;
store_to_eeprom(objLb1, 1);
// For 60 MAX
objLb1->dc[2].z->storage[0] = 203;
objLb1->dc[2].z->storage[1] = 506;
//...
objLb1->dc[2].z->storage[59] = 28;
store_to_eeprom(objLb1, 2);
// For 30 MAX
objLb1->dc[4].y->storage[0] = 4;
objLb1->dc[4].y->storage[1] = 7;
//...
objLb1->dc[4].y->storage[29] = 52;
store_to_eeprom(objLb1, 4);
free(objLb1);
return 0;
}
==========================================
I like to pick and choose the array according to the required size when I
fill out my
lb_table table. Then the program knows to store the informations in the
right array.
*** It would be nice to do the above by simply having one:
typedef struct tag_list_x
{
long *storage;
}listx;
structure where I can store a pointer to a malloc space in memory. The
problem is, how can I do this at the time I am filling out the lb_table
table? I know how malloc works, but I am just drawing a blank here on how I
You can initialize an automatic pointer with the address returned from
malloc. It doesn't do you any good in this case because at the time
you are initializing you don't know how much memory to allocate.
But why you dead set on initialization. The call to malloc is much
more time consuming that the act of assigning the returned value to a
pointer. For a particular listx, you should assign a value to storage
when it makes sense to do so as your program executes.
could accomplish the same convinience of the above sample but with a dynamic
array for every record as I fill out my table!
I don't know if I am explaining this right!
But the idea here is to fill out the table "lb_table" for 5 items and when
the odd time comes where I need more than 5 items, I select a storage array
space to accomodate eeprom data for 6 to 10 items, 11 to 30 items or 31 to 60
items as required for that specific record.
In that case, your definition could look like
listx x[] = {
{malloc(5 * sizeof(long))},
... as many as you want
{malloc(5 * sizeof(long))}
};
When it comes time to use more
long *temp;
temp = x[i].storage;
x[i].storage = realloc(temp, 10 * sizeof *x[i].storage);
PS I would be happy with the above code, but if there is a little
modification or insight as to weather I can replace the 3 storage structures
by one, that would be great.
--
Remove del for email