Iterator issues continue

I have bug checked this code considerably now and made sure I am outputting the 'correct' things to outline the problem. The iterator never points at the list at all, but another bunch of addresses which happily contain the correct data.

I have two questions:

1 = given the form of the couts, am I outputting the correct items to investigate why this loop is not exiting ;

2 = if(1) then what is going on to produce this output and do you have any advice to further my pointer knowledge (I have used this for loop format many times before and this as never happened ;

/questions

code :

#include "neutronFileReader.h"

using namespace std ;

neutronFileReader::neutronFileReader()
{
}

list<vector<float> > neutronFileReader::spectrum(char* filename)
{
ofstream addresses ;
addresses.open("adresses.txt") ;
ifstream fin(filename) ;
string binhi, binlo ;
list<vector<float> > neutronSpectrum ;
list<vector<float> >::iterator nS ;
vector<float> EnergyProbability ;

while(!fin.eof())
{
    EnergyProbability.clear() ;
    getline(fin, binlo, ' ') ;      //get the binlo string
    getline(fin, binhi, ' ') ;      //get the binhi string

    EnergyProbability.push_back(atof(binhi.c_str())+(atof(binhi.c_str()) -  atof(binlo.c_str()))/2) ; //store middle of bin as emission Energy

    getline(fin, binlo) ;       //try not to waste memory space

    EnergyProbability.push_back(atof(binlo.c_str())) ; //store emnission probability
    neutronSpectrum.push_back(EnergyProbability) ; //put the vector in the list
 }

 for(nS = neutronSpectrum.begin() ; nS != neutronSpectrum.end() ; nS++)  //go through the neutron spectrum
 {
     EnergyProbability = (*nS) ;
     addresses << &neutronSpectrum.begin() << " : " << &(*nS) << " : " << &neutronSpectrum.end() << endl ;    // print energy & prob to screen
     cout << &neutro开发者_Python百科nSpectrum.begin() << " : " << &(*nS) << " : " << &neutronSpectrum.end() << endl ;
 }

 return neutronSpectrum ;
 }

and here is the output:

0x28fbc4 : 0x510c38 : 0x28fbc0
0x28fbc4 : 0x510c58 : 0x28fbc0
0x28fbc4 : 0x510c78 : 0x28fbc0
0x28fbc4 : 0x510c98 : 0x28fbc0
0x28fbc4 : 0x510cb8 : 0x28fbc0
0x28fbc4 : 0x510cd8 : 0x28fbc0
0x28fbc4 : 0x510cf8 : 0x28fbc0
0x28fbc4 : 0x510d18 : 0x28fbc0
0x28fbc4 : 0x510d38 : 0x28fbc0
0x28fbc4 : 0x510d58 : 0x28fbc0
0x28fbc4 : 0x510d78 : 0x28fbc0
0x28fbc4 : 0x510d98 : 0x28fbc0
0x28fbc4 : 0x510db8 : 0x28fbc0
0x28fbc4 : 0x510dd8 : 0x28fbc0
0x28fbc4 : 0x510df8 : 0x28fbc0
0x28fbc4 : 0x510e18 : 0x28fbc0
0x28fbc4 : 0x510e38 : 0x28fbc0
0x28fbc4 : 0x510e58 : 0x28fbc0
0x28fbc4 : 0x510e78 : 0x28fbc0
0x28fbc4 : 0x510e98 : 0x28fbc0
0x28fbc4 : 0x510eb8 : 0x28fbc0

thanks much.

Correct me if I'm wrong but don't the 1st and 3rd column represent the pointers to the iterator instances returned by begin() and end() rather than the pointers to the objects (of the list) themselves?

Ok it seems to be working ok then (according to the last example).

It reaches the last element and then stops (the ones with the while never reach the last element because they fail the condition on the last element).

The key here is that .end() and .back() point to different things so that difference of addresses is to be expected.

.back() references the last element of the list. .end() references a past-last-element that serves to stop the cycle ONLY after the last element was handled (as opposed to what happens with the:

while(&(*nS) != lastListElement) {
/*...*
}

that results in the cycle stopping BEFORE analyzing the last element.

From what I could gather your only problem was with the output of the addresses right? Or is the cycle not exiting where it is supposed to?

Just discovered this myself but it seems that the iterator returned by list.end() doesn't point to a valid element. It points to the past-the-end element.

So that we can correctly understand what is going on you should output list.back() which does indeed point to the last element on the list. Note that list.back() doesn't return an iterator but a direct reference to the last item (so you should simply print what is returned without dereferencing).