Help with arrays/multiple header files

[GTM]

I received a bunch of generated files labeled item001.h-item050.h. In each header file, there is a variable (let's say an int) named numberForItem001-050 (one for each header file), and each on has a different value in it. I want to change it so I can index into these variables. What I want is in item001.h, to declare an array numberForItem[50]. Then in item001.h make an assignment numberForItem[0] = 1, in item001.h make an assignment numberForItem[1] = 5; etc. Is there a way of doing this without moving everything to 1 header file (ie. initializing all 50 ints in item001.h). if not, any other ideas?

[RoadieRich]

I received a bunch of generated files labeled item001.h-item050.h. In each header file, there is a variable (let's say an int) named numberForItem001-050 (one for each header file), and each on has a different value in it. I want to change it so I can index into these variables. What I want is in item001.h, to declare an array numberForItem[50]. Then in item001.h make an assignment numberForItem[0] = 1, in item001.h make an assignment numberForItem[1] = 5; etc. Is there a way of doing this without moving everything to 1 header file (ie. initializing all 50 ints in item001.h). if not, any other ideas?

You should be able to do it exactly like that. Have you tried it? The only thing you need to make sure is that item001.h is always included first.

You may have problems with access, if that's the case, just create the array on the heap, using either new or malloc, depending on which variety of c you're in.

Headers can be considered nothing more than cut and pasting code. If you could do it in a single file, you could do it in multiple headers - as long as you #include them in the right order.

OTOH, the "correct" way to do it would be to write a (maybe) five line script in $preferred_scripting_language to combine them for you - having similarly named files doing very different jobs is (imho) very bad practice (item001.h declares an array, item002.h and so on only modify an existing array).

[GTM]

Looks like I left out some info, oops.

The problem is that they are not in functions, the are just declared as global variables at the beginning of the header file.

Originally, I had a bunch of:

item001.h:
int numberForItem001 = 1;
item002.h:
int numberForItem002 = 2;

etc

now I want
item001.h:
int numberForItem[50];
numberForItem[0] = 1;

item002.h:
numberForItem[1] = 1;

but you can't assign values if they are not in functions (except during initialization)

[phlip]

You could, however, have something like:

Code: Select all

/* item001.h */
numberForItem[0] = 1;
/* item002.h */
numberForItem[1] = 2;
/* etc */

/* items.c */
int numberForItem[50];

void initItems(void)
{
#   include "item001.h"
#   include "item002.h"
    // etc
}

Another option could be to have:

Code: Select all

/* item001.h */
1
/* item002.h */
2
/* etc */

/* items.c */
int numberForItem[] = {
#   include "item001.h"
    ,
#   include "item002.h"
    ,
    // etc
};

Note that with the first option you could do anything you can do in code, while in the second option you can do anything you can do in an initialiser - so for instance if you wanted to have a struct for each item instead of an int, the second one would let you initialise it directly, while the first one would require you to assign to each field separately. The first one also has the downside that you need to call initItems() at some point.

Still, this is all trying to work around the requirement that each one be in separate header files... is that an absolute requirement? Can they be in separate files that are then pre-processed into a single header and/or source file, before compilation? Because that would be a much cleaner way to do it...

[GTM]

First one looks like an interesting solution that may work for me. 2nd one requires too many changes I'd think.

No, it's not necessary, but it was preferred. Thanks for your help!

[TNorthover]

I can't help feeling something's gone horribly wrong here.

[Yakk]

Yep. Question asked, question that was asked answered.

Actual point is "no, that is a bad way to do it" passes over asker's head.

[scarecrovv]

It looks to me as though he wants to compete in the IOCCC. If that's so, he's doing it right.

[AndyG314]

Looks like I left out some info, oops.

The problem is that they are not in functions, the are just declared as global variables at the beginning of the header file.

Originally, I had a bunch of:

item001.h:
int numberForItem001 = 1;
item002.h:
int numberForItem002 = 2;

etc

now I want
item001.h:
int numberForItem[50];
numberForItem[0] = 1;

item002.h:
numberForItem[1] = 1;

but you can't assign values if they are not in functions (except during initialization)

Generated files can be a pain in the butt, however your patacular problem could be solved by creating an array of pointers, each of which points to one of the ints from the file like so:

Code: Select all

#include "item001.h"
...
#include "itemN.h"

int *itemPntrArray[] = {
  &numberForItem001,
  &numberForItem002,
  ...
  &numberForItemN,
};


you could now access the elemetns in the array via their pointer, for example if you wanted to set numberForItem001 to 10 you could use:

Code: Select all

*itemPntrArray[0] = 10;


if you wanted numberForItem001 to be in itemPntrArray[1] you could just set itemPntrArray[0] to NULL.

If your using C++ you could do this with references, my C++ isn't great, but I think the following code would do the trick.

Code: Select all

#include "item001.h"
...
#include "itemN.h"

int &itemPntrArray[] = {
  numberForItem001,
  numberForItem002,
  ...
  numberForItemN,
};


you could then directly access numberForItem001 via itemPntrArray[0].

[Sc4Freak]

I'm fairly certain you can't have an array of references. Arrays require default-constructible objects, and references can't be default constructed (since they can't be "reseated").

[EvanED]

I'm fairly certain you can't have an array of references. Arrays require default-constructible objects, and references can't be default constructed (since they can't be "reseated").

I wouldn't have really expected that (but nor am I particularly surprised given how... consistent C++ is), but you seem to be correct:

Code: Select all

Comeau C/C++ 4.3.10.1 (Oct  6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
Copyright 1988-2008 Comeau Computing.  All rights reserved.
MODE:strict errors C++ C++0x_extensions

"ComeauTest.c", line 3: error: array of reference is not allowed
  int& arr[] = {x , y, z};
       ^

[jareds]

I'm fairly certain you can't have an array of references. Arrays require default-constructible objects, and references can't be default constructed (since they can't be "reseated").

While you indeed can't have arrays of references, arrays only require default constructors if one or more elements are not specified by an initalizer. For example:

Code: Select all

struct A { A(int); };
A x[2] = { 0, 1 }; // ok
A y[3] = { 0, 1 }; // error

As EvanED alludes, the prohibition on arrays of references is a specific rule with no clear rationale, not a particular case of a general rule.

[Great Justice]

the prohibition on arrays of references is a specific rule with no clear rationale, not a particular case of a general rule.

Well, since you can't have a pointer to a reference, and arrays are equivalent to const pointers to their first element, it is indeed consistent.

[EvanED]

the prohibition on arrays of references is a specific rule with no clear rationale, not a particular case of a general rule.

Well, since you can't have a pointer to a reference, and arrays are equivalent to const pointers to their first element, it is indeed consistent.

The second thing is false, and it's not consistent, and I'll edit this post with more later.

Edit: see below. Great Justice is actually largely right.

[Yakk]

sizeof(array)/sizeof(array[0]) seems like a reasonable reason to avoid arrays of references. Not an unboundedly strong reason, but a non-trivial one.

[letterX]

Well, in general, it seems that references really aren't first class objects in C++. They unfortunately make the programmer think that they're secretly a pointer, but the compiler is allowed to do pretty much anything with them (they have completely undefined values, and may not even exist as a value in the first place). Really, they're better off being treated as semantic sugar for compiler-voodoo than anything else.

[arbyd]

I may be missing the point about an array of references, but this compiles and runs on my mac with xcode.

Code: Select all

// item001.h
int numberForItem001 = 1;

// item002.h
int numberForItem002 = 2;

//itemarray.h
int *nums[] = {
        &numberForItem001,
        &numberForItem002
}

//main.c
#include <stdio.h>
#include "item001.h"
#include "item002.h"
#include "itemarray.h"

int main(int argc, char *argv[])
{
        int i, n;
        for (i=0; i < sizeof(nums)/sizeof(int *); i++) {
                n = *nums[i];
                printf("numberForItem%03d = %d\n", i, n);
        }
        return(0);
}


However, it's still a bad idea.

[Yakk]

You aren't using references in your code snippit. You are using pointers.

[EvanED]

The second thing is false, and it's not consistent, and I'll edit this post with more later.

Since there is more discussion I'll just post here. I have rethinked my position though and think that you're mostly right, I just don't think you phrased it very well.

...arrays are equivalent to const pointers to their first element, it is indeed consistent.

That arrays and pointers to their first elements are the same is a somewhat dangerous misconception which I wish would go away completely. Given an array int arr[10], it's really no more correct to say that arr is equivalent to &arr[0] then it is to say that the integer 1 is equivalent to 1.0. In both cases they have different types, and in both cases the former is implicitly converted to the latter in some situations. That it happens more often with arrays is true (from some reasonable perspective it happens with almost everything you can do to an array), but fundamentally there's no difference between the two cases.

Now, if we ignore the particulars of your comment and the way you phrased it and look at your broader argument, I actually will believe that's the reason. If r is a reference, then &r actually evaluates to the address of r's referent. So if arr is an array of references, then &arr[0] is the address of the referent of the first element of the array. But then what's &arr[0]+1? Well... that's a bit harder. Under any reasonable evaluation rules, it would be the address of the referent of arr[0] plus the size of that referent. But that's not necessarily &arr[1]. In other words, arrays of references break the identity that &arr[0]+k == &arr[k]. That's pretty bad.

So good thinking.

sizeof(array)/sizeof(array[0]) seems like a reasonable reason to avoid arrays of references. Not an unboundedly strong reason, but a non-trivial one.

I don't see why that's any more of a problem than sizeof(some_reference_variable). They could define the size of the array as the size of each element times the length. It might not agree with the actual storage space used, but that problem already exists with references.

Well, in general, it seems that references really aren't first class objects in C++. They unfortunately make the programmer think that they're secretly a pointer, but the compiler is allowed to do pretty much anything with them (they have completely undefined values, and may not even exist as a value in the first place). Really, they're better off being treated as semantic sugar for compiler-voodoo than anything else.

Thinking of references as syntactic sugar for const pointers is perfectly fine. The compiler is often allowed to do anything it wants with, including optimize away, pointer variables too. The only real difference is that a reference's lvalue is the pointer's target, not the reference itself; in other words, you can't get the address of a reference itself. (This means that the one thing which you can do to absolutely guarantee that the compiler can't optimize away a pointer (i.e. take its address and do something observable with it) you can't do to a reference.)