This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unbounded Arrays and the sizeof operator

I take it using sizeof() on a array that is unbounded is a problem (I am getting sizeof returns size of type 0 warnings).

I have defined a constant array of pointers unbounded IE

#define CCHARPTR code char *
CCHARPTR numerous_strings[] =
{
"string1",
"string2",
"string3.5"
};


If I wished to know the number of entries in numerous_strings I thought I could do this

(sizeof(numerous_strings)/sizeof(CCHARPTR))


Obviously I was wrong since the compiler warns sizeof(numerous_strings) is zero. How can I get the size of this array because I would like to save time in having to write a 'magic' number for the number of numerous_strings. Sounds simple, unbounded arrays seem to be what it has issues with. Suggestions anyone?

Parents
  • That's very interesting regarding multiplication and division on constants. I can see why that might be a problem or compiler dependent at least. Interestingly enough my code uint8_t value comes out 27 (27 strings are size 81 / 3 bytes per string pointer == 27).
    C Side thought:

    Perhaps because of how varied C handles things an operator of elementsof() (IE return the number of elements) of something. This makes it sizeof(type) agnostic and implicitly does on the work. However again it won't work with unbounded arrays that are defined in a different module because the array size is unknown to anything but within that module. However

    const my_array_size = elementsof(my_array);
    

    would assign the const with the literal number of elements at least.
    I doubt that will ever happen however as it's not a common use to find out how many elements are in an array. The assumption is you should already know (this of course ignores unbounded arrays).

    The enumeration system I see suggested is actually possibly the best way to handle the problem for me ironically, it's still a bit of work (add a string you have to add to that enumeration statement then). I was attempting to avoid having to redefine a #define statement every time I added a string to the array. It's used to do a sanity check when referencing the array of strings. The enumeration method may be necessary to begin with (for clarity of what string is being used as the strings are more like a series of drawing commands than just plain text.)

    Stephen

Reply
  • That's very interesting regarding multiplication and division on constants. I can see why that might be a problem or compiler dependent at least. Interestingly enough my code uint8_t value comes out 27 (27 strings are size 81 / 3 bytes per string pointer == 27).
    C Side thought:

    Perhaps because of how varied C handles things an operator of elementsof() (IE return the number of elements) of something. This makes it sizeof(type) agnostic and implicitly does on the work. However again it won't work with unbounded arrays that are defined in a different module because the array size is unknown to anything but within that module. However

    const my_array_size = elementsof(my_array);
    

    would assign the const with the literal number of elements at least.
    I doubt that will ever happen however as it's not a common use to find out how many elements are in an array. The assumption is you should already know (this of course ignores unbounded arrays).

    The enumeration system I see suggested is actually possibly the best way to handle the problem for me ironically, it's still a bit of work (add a string you have to add to that enumeration statement then). I was attempting to avoid having to redefine a #define statement every time I added a string to the array. It's used to do a sanity check when referencing the array of strings. The enumeration method may be necessary to begin with (for clarity of what string is being used as the strings are more like a series of drawing commands than just plain text.)

    Stephen

Children