the number of points is just a computation.
since you started at 1, its not a hard one:
xm/numpoints. eg, if you had xm = 1000 and you want a point every 40 ticks, you need 25 points. or if you know the # of points, just use it. When making the # of points, if you compute it, you have to decide if you are +1 or not (if the computation is 40.012 do you use 40 points or 41 points?) ... this is a choice depends on what you are doing.
vectors can resize but for things like this set it up front:
vector<int> x(25);//25 points -- unlike arrays, this can be a variable
for(int i = 0; i < x.size(); i++)
x[i] = something;
this is not a grid though. It sounds like an interpolation table.
a grid is 2-d usually, what are you asking really?
I said that :) vector<int> x(25);//25 points -- unlike arrays, this can be a variable
vector<int> x;
this is very, very similar to {int*x; }
vector<int> x(100);
this is very, very similar to {int*x = new int[100];}
one of those will blow up if you try to use x[index] = value and the other will let you use index from 0-99 .... its the same idea. vectors are a wrapper for 'dynamic arrays' (and a stack class, as an intentional side effect). They have a safe out of bounds call (.at()) but its slow. Better to just be aware of what is going on and carefully use [] notation.
you could also pushback() every value. I dislike this approach, but its more or less the same if you reserve() your 100 first, and risks a memory reallocation/ data copy if you don't. You will see this a lot in other people's code. Its most handy if you truly do not know what you are going to get and cannot even over-guess, like reading a file or user input.