CompuServe Messages

>I'm not sure I see exactly why using named >constants in this kind of situation should be avoided I'd said in general. Though I will carry the thought along to this kind of situation too. The issue is that named constants for dimension sizes can usually be done in some other way. And better IMO. This thread has seen three suggestions on this already: 1) use something like HBOUND (or span as somebody else called it). 2) Look at really what is being said by sometype arr[] = { the init'ors }; Here we avoid the number altogether. 3) Seperately, in in combo with 2, see if a sentinal value makes sense. Zero of some sort often (but not always) does. Consider: #define ARRSIZE 5 int arr[ARRSIZE] = { 1, 2, 3, 4, 5 }; For starters, one should strive to avoid the preprocessor. Other choices might consist of a const int (in C++ only) or an enumerator. (The compiler proper knows about these, the compiler proper knows nothing about the preprocessor). Even with those changes though, a traversal might be: int i; for (i = 0; i < ARRSIZE; i++) arr[i] = -arr[i]; What's been established is a related, but disjoint, identifier ARRSIZE to deal with arr's size. Hence, I might also have an ARR2SIZE for arr2. I don't want this relationship unless absolutely necessary. What are my choices though? How about: int arr[ARRSIZE+1] = { 1, 2, 3, 4, 5, 0 }; … for (i = 0; arr[i]; i++) arr[i] = arr[i]; Or since we've no more need for ARRSIZE in at least this context, forget about ARRSIZE altogether, and forget about having to forget or remeber about the +1, or to ensure that the count is right (and don't get me wrong, sometimes the number of initializers better be right) and just do: int arr[] = { 1, 2, 3, 4, 5, /* sentinal */ 0 }; The data structure is now fully capable of driving itself w/o any baggage. That of course is not always possible. For instance all possible int's can be valid init's for arr and hence there can be no one valid sentinal. That still leaves us with int arr[] = { 1, 2, 3, 4, 5 }; and perhaps: for (i = 0; i < HBOUND(arr); i++) arr[i] = -arr[i]; Still need to utter the bound somehow, but a special "funny" name doesn't always have to exist. >would not want to set up something that should be dynamically allocated as >a bunch of static arrays Actually sometimes you do. Depends upon what you compromises, tradeoffs, and goals are. This should probably typically not be ones first course of action though. I'm unclear on the relationship you're building though. Or do you just mean that if you did do a dynamic allocation that you would have to have specified some size to the malloc (or new in C++) request? >…a further array of key buffers, also of different number & size….) this >seems like a fairly reasonable approach. Maybe I'm missing something ( as >is so often the case )….. What you ended up with as I recall was the way to do it. I was just nitpicking a frosting so to speak. The deal to me is to strive to let data structures "drive" themselves and be as closeknit implemented as possible.