double for loop with specific values

[vagelis]

i want to find the sum of all elemnts of a vector<vector<int>> States //two dimensions table

in the rows that are specified from the vector<int> a; //for example 1 3
and for rows that are specified from the vector<int> b //for example 2 3

how can i do that with a double for??

for example
for(a)
{
for(b)
{
sum=sum+States[i from a][j from b]
}
}

[Athar]

I'm not sure where your problem is.
See here for an explanation of how to use for: http://www.cplusplus.com/doc/tutorial/control/
And here for the vector reference: http://www.cplusplus.com/reference/stl/vector/ (hint: you need size() or begin()/end()).

[vagelis]

the problem is how can i use vector in the for loop..
can you give me an example to understand?

i know to give in the for llop a range 0-1000 for example
but how can i give specific values that are values of a vector??

[Athar]

By using the index operator, for example:

for (uint i=0;i<a.size();i++)cout << a[i] << ' ';

[h9uest]

/************************code start*********************/
int sum = 0;
int col_num = (int) states.size(); //%%%
for (int i=0; i<col_num; i++)
{
vector<int> * column = &(states[i]); //$$$
int row_num = (int) (*column).size(); //***
for (int j=0; j<row_num; j++)
{
sum += (*column)[j];
};
};
/****************sum contains the value you want****************/

Explain:
1. for the lines marked with *** & %%%: don't be lazy by omitting the type conversion. It can cause you big trouble in certain cases. Plus, get your self a good programming habit.

2. for the line marked with ***: don't put this in the following for loop, because that will cause multiple calls to vector::size(), which is a waste, particularly when you have a large vector.

3. for the line marked with $$$: remember that manipulation of addresses is always faster than manipulation of the data itself.


Final remark: don't think of vector< vector<?> > as a two-dimension array, instead, think of it as a nested one dimensional vector, with each element being a vector of type ?
One obvious reason is it allows different sizes for each "column", while a two-dimension array does not.

[Athar]

for the lines marked with *** & %%%: don't be lazy by omitting the type conversion. It can cause you big trouble in certain cases.

Whatever you might mean - this is not one of these cases.

Plus, get your self a good programming habit.

...and it's not exactly a good habit, not in cases such as this. Also, when you want to explicitly tell the reader that a cast is performed, you should use static_cast and not the "hamfist cast" operator.

2. for the line marked with ***: don't put this in the following for loop, because that will cause multiple calls to vector::size(), which is a waste, particularly when you have a large vector.

No. First, "call" is misleading because it implies that it's costly - however calling size() will usually translate in a single mov instruction (on x86) when being inlined and no (low level) call is actually made. And if no elements are added or removed inside the loop, it's fairly safe to assume the compiler will retrieve the size just one single time and store it in a register - at the beginning of the loop.
In short, it is a typical micro-optimization that should be left to the compiler.

3. for the line marked with $$$: remember that manipulation of addresses is always faster than manipulation of the data itself.

No. You probably meant to say something different. However
vector<int> * column = &(states[i]); is yet another micro-optimization that should be left to the compiler who can assess the situation better.

vector<int>& column = states[i];

is okay - not to improve performance, but to improve readability by being able to replace states[i] by column in the code that follows. There are exceptions, such as when using operator[] on a std::map - then "caching" the element can actually improve performance, because the compiler cannot easily optimize away the multiple calls (which could also modify the object).

[h9uest]

Whatever you might mean - this is not one of these cases....and it's not exactly a good habit, not in cases such as this. Also, when you want to explicitly tell the reader that a cast is performed, you should use static_cast and not the "hamfist cast" operator.

Don't be so short-sighted with only "this case". If "this case" is the only thing you're interested in, you don't even need the static_cast stuff and it will work to compare a variable of size_t and int. Developing good habits starts from "this case" but is never confined to "this case". However, I do agree static_cast shall be used --- only because this is a C++ forum. With a C background, I prefer c style cast and I reserve my personal preference.

it's fairly safe to assume the compiler will retrieve the size just one single time and store it in a register

No. "it's safe to assume ..." This is never going to be the last time I see this one. Loop hoisting is not a born gift with C++/C. There're numerous old versions of compilers from various vendors (particularly in 90s) that don't support loop hoisting and are still in use. However, loop hoisting is a job of RECENT compilers. Since we are not given the compiler information, don't make insecure assumptions. What's more, even for these days, operations like left/right shift are not supported in terms of loop hoisting for a wide range of compilers. So don't assume before you really know.
I know this is not so closely related, but do you know why there's so much code injection these days? Insecure assumptions! Remember, they can be dangerous.

calling size() will usually translate in a single mov instruction (on x86)

Not sure what you mean, but a single mov instruction only copies some value into a register. It alone doesn't give you the result of size(). Maybe you really want to say "one more mov instruction"? --- given your "safe to assume", yes, you're right. But if your assumption is not that "safe", then extra cost of time complexity O(n) occurs.

vector<int>& column = states[i];

This is not as good. There're a few differences between pointers and references. In one word, pointers are more powerful and more flexible than references. For example, a reference cannot be used to reference another object after initialization while pointers can; a reference cannot be null while pointers can ... I'm sure you can find a lot of text books on this topic. Although those standard makers add reference into C++, it is a controversial feature because reference syntactically obscures identifier's indirection, which syntactically confuses yourself whether you're dealing with a variable or a "pointer"(worse readability). Again, for the sake of good programming habits, avoid it if you have more powerful (and syntactically clearer) tools like pointers.

[sohguanh]

Although those standard makers add reference into C++, it is a controversial feature because reference syntactically obscures identifier's indirection, which syntactically confuses yourself whether you're dealing with a variable or a "pointer"(worse readability). Again, for the sake of good programming habits, avoid it if you have more powerful (and syntactically clearer) tools like pointers.

Hmmm... actually I hold a different view from you. The introduction of reference in C++ is actually better than the traditional pointers. Granted in terms of flexibility pointer seems to hold an edge but this flexibility has a price to pay. How often we are faced and plagued (as in countless nights debugging) with pointer related problems in our C++ programs despite us developing in C++ for many years.

I believe C++ offer us a balance, it provides BOTH pointers and references. So if you still feel pointers are more flexible than references, you can totally disregard and don't use reference in your C++ program. Likewise, if I prefer references, I would use them. However based on my own experience, I uses BOTH although I try to keep pointer to a minimum if I could.

Above is purely my own opinion so please don't flame me :)