M
Mike Cain
I have an odd situation I'm trying to understand..... I'm using MS VS 7.0
C++ with the MFC CBuffer class.
If I do this:
#define NUM_ELEMENTS 2
CBuffer<char, 512> x[NUM_ELEMENTS-1];
CBuffer<char, 512> y[NUM_ELEMENTS-1];
So as you can see I have two variables which will hold strings, each of
which has two elements. One at position [0] and the other at [1].
However with the above definition x[1] and y[0] point at the same exact
address and overwrite one another! Why is this??
If I define those vars as NUM_ELEMENTS, instead of NUM_ELEMENTS-1, then
things work great. It would think that [1] would do the trick since I have
[0] for the first element and [1] for the second. So why is it then
necessary to have these defined as [2]? And yes I am certain when I am
writing to these vars I'm using [0] to address the first element and [1] to
address the second.
Defining it as [NUM_ELEMENTS] seems to do the trick to resolve this issue,
but I wanted to better understand why I am seeing that behavior to make sure
that this apparent fix is not an illusion with a subtle bug waiting to bite
me!
Thanks!!
C++ with the MFC CBuffer class.
If I do this:
#define NUM_ELEMENTS 2
CBuffer<char, 512> x[NUM_ELEMENTS-1];
CBuffer<char, 512> y[NUM_ELEMENTS-1];
So as you can see I have two variables which will hold strings, each of
which has two elements. One at position [0] and the other at [1].
However with the above definition x[1] and y[0] point at the same exact
address and overwrite one another! Why is this??
If I define those vars as NUM_ELEMENTS, instead of NUM_ELEMENTS-1, then
things work great. It would think that [1] would do the trick since I have
[0] for the first element and [1] for the second. So why is it then
necessary to have these defined as [2]? And yes I am certain when I am
writing to these vars I'm using [0] to address the first element and [1] to
address the second.
Defining it as [NUM_ELEMENTS] seems to do the trick to resolve this issue,
but I wanted to better understand why I am seeing that behavior to make sure
that this apparent fix is not an illusion with a subtle bug waiting to bite
me!
Thanks!!