Skip to main content
gamedev.net
🔒 Locked

vectorvectorint ::iterator to std::vectorT conversion

Started by Mad_Coder Jan 1, 2009 at 8:33 PM 5 replies 800+ views
Original Post
Mad_Coder
Mad_Coder
I want to be able to store a vector object using an iterator for a vector of a vector ( vector >::iterator, is this possible In other words, I want to use the operator=() method of a vector >::iterator to assign it to a vector object ... NOTE: I IF THIS IS THE VECTOR >::ITERATOR ELEMENTS... { 0 ,1 ,2 ,3 ,4 ,5 ,6 ,7 ,8 } { 10,11,12,13,14,15,16,17,18 } { 19,20,21,22,23,24,25,26,27 } { ..,..,..,..,..,..,..,..,.. } { ..,..,..,..,..,..,..,..,.. } { 72,73,74,75,76,77,78,79,80 } I want the iterator to store the vector of a vector like how you could with a sudoku puzzle, by subsquare ( elements 0,1,2,10,11,12,19,20,21 are in subsquare one and 3,4,5,13,14,15,22,23,24 are subsquare 2) and by row and column which are self explainatory [CODE="C++"] typedef unsigned int UINT; using namespace std; vector array; // push back 81 elements with the element index as it's value for(UINT i = 0; i < 81; i++) { aray.push_back(UINT); } vector >::iterator iArray; [Edited by - Mad_Coder on January 1, 2009 9:15:39 PM]
SiCrane
SiCrane
If I understand what you're asking, (though I'm not entirely sure that I do) you can dereference the vector > iterator to get a reference to the vector sub element and use that to assign to a vector.
  std::vector<int> target;  std::vector<std::vector<int> > vector_of_vectors;  // populate vector_of_vectors somehow  target = *vector_of_vectors.begin();
Mad_Coder
Mad_Coder
Thanks, that's what I was asking about but i need to use a little algorithm to figure what subsquare the squares index would be in not by iterating linearly from the begin to the end of the row and column
Zahlman
Zahlman
Don't use a vector of vectors to represent a rectangular grid. For Sudoku, you already know the size, so you can just use an array[9][9], possibly wrapped in a struct of some sort (such as boost::array); otherwise, you could use boost::multi_array.

operator= of an iterator is for assigning from one variable of that iterator type to another variable of the same iterator type. Dereferencing an iterator gives you a reference (confusing, hmm?) to the element the iterator pointed at (iterated to?).

With a bit of work, you could make an iterator over the grid that iterates in "subsquare order", but it's realistically not worth the effort.
Mad_Coder
Mad_Coder
Quote:
With a bit of work, you could make an iterator over the grid that iterates in "subsquare order", but it's realistically not worth the effort.



Well I am writing a sudoku solver and I need to store the squares in many ways using iterators such as how close the square is to being a single canidate ( has one possible canidate) and then have another dimention of the canidates in ascending order; this is in all the means of efficiency... To do processes like this, I need to check the squares row column and subsquare so I cand find canidates as well as check rows colummns and subsquares for single positions
_the_phantom_
_the_phantom_
You'll want to abstract more, so that while your storage might well be a boost::array or a std::vector this is inside another class (such as a 'board' class) which does all the logic of calculating colums, rows and sub-squares for you via functions.

Your calling program then uses these functions to ask the board about it's state and cares not what the underlaying storage system is.
Zahlman
Zahlman
Quote:
Original post by Mad_Coder
Quote:
With a bit of work, you could make an iterator over the grid that iterates in "subsquare order", but it's realistically not worth the effort.



Well I am writing a sudoku solver and I need to store the squares in many ways using iterators such as how close the square is to being a single canidate ( has one possible canidate) and then have another dimention of the canidates in ascending order; this is in all the means of efficiency


No you don't; just make sorted containers of references to squares, and/or iterate manually to cover subsquares/rows/columns. Adding complexity a priori is a bad idea unless you can prove it makes big-O improvements to run time; otherwise, follow the usual rules of optimization.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.