Creative input on indexing from 0 to 99 or 1 to 100

[GMM50]

I've got a project that has 100 settings. In C I've defined these
settings in an array:

#define SETTING_MAX 100
int Setting[SETTING_MAX];

The user refers to them as setting[1] through setting[100].
Internally I refer to them as setting[0] through setting[99].

Initially I was hidiing the conversion from the user; that is, taking
the user input and subtracting one from it. But this is driving me
nutty.
There are a dozen places where I apply this through out the project not
just one array.

For size constraints I can not use an array from 0 to 100.

Has anyone come up with a good solution to this issue.

Thanks in advance
George

[David Resnick]

GMM50 wrote:

I've got a project that has 100 settings. In C I've defined these
settings in an array:

#define SETTING_MAX 100
int Setting[SETTING_MAX];

The user refers to them as setting[1] through setting[100].
Internally I refer to them as setting[0] through setting[99].

Initially I was hidiing the conversion from the user; that is, taking
the user input and subtracting one from it. But this is driving me
nutty.
There are a dozen places where I apply this through out the project not
just one array.

For size constraints I can not use an array from 0 to 100.

Has anyone come up with a good solution to this issue.

Thanks in advance
George

You could use function macros (or inline functions if your system
supports). Or real functions if the overhead is not excessive,
though one int making a differences suggests your resources are really
tight. One virtue of macros here is that you say it applies to
multiple arrays and that works even if the arrays are of different
types...

Example to get one based array value

#define GET_OB_ARRAY_VALUE(array,index) ((array)[(index)-1])

You could even do (to enforce lower boundry)

#define GET_OB_ARRAY_VALUE(array,index)
(assert((index)>0),((array)[(index)-1)]))

-David

[SSM]

If you prefer the solution below which overcomes complexity at the loss of 1
byte per array,
then you can do the following:

#define SETTING_MAX 101
Then you can use array index as input by the user which is 1 to 100.
But this comes with a loss of 1 byte per array which is Setting[0].

"GMM50" <ge***********@att.net> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

I've got a project that has 100 settings. In C I've defined these
settings in an array:

#define SETTING_MAX 100
int Setting[SETTING_MAX];

The user refers to them as setting[1] through setting[100].
Internally I refer to them as setting[0] through setting[99].

Initially I was hidiing the conversion from the user; that is, taking
the user input and subtracting one from it. But this is driving me
nutty.
There are a dozen places where I apply this through out the project not
just one array.

For size constraints I can not use an array from 0 to 100.

Has anyone come up with a good solution to this issue.

Thanks in advance
George

[Cong Wang]

GMM50 wrote:

I've got a project that has 100 settings. In C I've defined these
settings in an array:

#define SETTING_MAX 100
int Setting[SETTING_MAX];

The user refers to them as setting[1] through setting[100].
Internally I refer to them as setting[0] through setting[99].

Initially I was hidiing the conversion from the user; that is, taking
the user input and subtracting one from it. But this is driving me
nutty.
There are a dozen places where I apply this through out the project not
just one array.

For size constraints I can not use an array from 0 to 100.

Has anyone come up with a good solution to this issue.

Thanks in advance
George

Using macros is a good way.But I think you can apply 101 items instead
of 100 items.

#define SETTING_MAX 101
int Setting[SETTING_MAX];

And discard the first item.It is really hard to determine whether
arrays begin with 1 or 0.In my own opinion,0 is better. :P

[GMM50]

You're correct 101 should not break the bank.
gm

[Kenny McCormack]

In article <11**********************@g49g2000cwa.googlegroups .com>,
GMM50 <ge***********@att.net> wrote:

You're correct 101 should not break the bank.
gm

That seemed to be one of the conditions of contest, though.
I.e., he stated that making the array length 101 was not an option.

Which of course makes it sound like homework.

[CBFalconer]

*** Rude topposting corrected ***
SSM wrote:

"GMM50" <ge***********@att.net> wrote in message

I've got a project that has 100 settings. In C I've defined
these settings in an array:

#define SETTING_MAX 100
int Setting[SETTING_MAX];

The user refers to them as setting[1] through setting[100].
Internally I refer to them as setting[0] through setting[99].

Initially I was hidiing the conversion from the user; that is,
taking the user input and subtracting one from it. But this is
driving me nutty. There are a dozen places where I apply this
through out the project not just one array.

For size constraints I can not use an array from 0 to 100.

Has anyone come up with a good solution to this issue.

If you prefer the solution below which overcomes complexity at the
loss of 1 byte per array, then you can do the following:

#define SETTING_MAX 101
Then you can use array index as input by the user which is 1 to 100.
But this comes with a loss of 1 byte per array which is Setting[0].

If you had refrained from top-posting you would have seen that the
OP specifically excluded this solution.

For user interaction, the OP could have a single pair of routines:

int getindex(FILE *f) { }
int putindex(int ix, FILE *f) { }

which can encapsulate all of text/binary conversion, range
checking, and add/subtract 1. Internal to get/putindex the value 0
could mean "not entered", while outside that would be represented
by -1. If you prevent getindex from ever returning out of range,
much will be simplified.

Another possible version of getindex could supply an optional
prompt, and assume the use of stdin/stdout pair. This may be
easier for input error reporting:

int getindex(char *prompt) { }
int putindex(int ix) {} /* Assumed to stdout */

Now the program internals can universally assume C usage. Another
possibility is to switch to Pascal or Ada, where such nuisances do
not arise.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!