So how do I get an ifstream to start at the top of the file again?

So how do I get an ifstream object to start at the top of the file again, if its already read some lines with getline() and/or is already at the end of the file?
I'm using the global getline() function which has a prototype of the following:

Code:

istream& getline ( istream& is, string& str );

I tried calling ios::clear() before the getline call, but it didn't work. The ifstream object is still at the end of the file after the call to ifstream_object_name.clear().
After attempting that, and it not working, I went and looked at the reference to ios::clear(), and learned it only clears the error flags. It doesn't reset the input filestream to the top of the file, unfortunately. So how do I do that?

That's what "seekg" does: seekg - C++ Reference

Alternately, close() then open() the stream - specifying the same filename as when the stream was opened the first time.

Originally Posted by EVOEx

That's what "seekg" does: seekg - C++ Reference

Thanks, but could you please explain in more detail how the function works (i.e. what to pass to the function, when you call it for the purpose of resetting the ifstream object to the beginning of the file)?

I tried to follow the example at that link, and wrote:

Code:

input_stream2.seekg(0, ios::beg);

but after the call to seekg(), input_stream2.eof() still returns true.

EDIT: Wait...duh. Obviously, I'm supposed to call both seekg() AND clear().

EDIT again: No, that didn't help anything. Its still at the end of the file apparently...

Originally Posted by grumpy

Alternately, close() then open() the stream - specifying the same filename as when the stream was opened the first time.

Yeah, I know. I thought of that. But, I decided against it due to the nature of things in my program.

Thanks anyway though.

EDIT: Wait...duh. Obviously, I'm supposed to call both seekg() AND clear().

Call them in the wrong order didya?

Code:

        fin.clear( );
        fin.seekg( 0, std::ios::beg );

tellg() would say 0, so you're at the beginning.

Originally Posted by Programmer_P

Yeah, I know. I thought of that. But, I decided against it due to the nature of things in my program.

What sort of things in your program would make closing and reopening a stream unsuitable?

Originally Posted by whiteflags

Call them in the wrong order didya?

Code:

        fin.clear( );
        fin.seekg( 0, std::ios::beg );

tellg() would say 0, so you're at the beginning.

Awesome.
Switching the order like you said did it. My program works now.

Thanks.

Originally Posted by grumpy

What sort of things in your program would make closing and reopening a stream unsuitable?

Well, I just didn't want to have to call the openFile() function more than once in my program. The openFile function open()s both filestream objects with the fileName passed to the function, then returns true if both ifstream member objects.is_open() functions returns true. The openFile(), along with findScriptTag(), findJsFunctionNames(), findHtmlElementsWithJsFunctionCall(), are all member functions of a class called C_script_operations. The ifsteam objects are also members of this class. The idea was to call findScriptTag() in int main() once for each <script> element in the input file, until the end of the file was reached through the first ifstream object. After findScriptTag() has returned, I then next call findJsFunctionNames(), passing to it the current storageStr to which findScriptTag() added the current <script> element found, from <script> to </script>. findJsFunctionNames() then searches through the storageStr to find all function names, which it then adds one at a time to a vector<string> object, which once the storageStr has been completely iterated through, is returned to the caller. Now that I have the function names in a vector<string> object, I then proceed to iterate through the vector, call findHtmlElementsWithJsFunctionCall(), passing to it the current Javascript function's name. With each call to findHtmlElementsWithJsFunctionCall(), the function has to begin with the second ifstream object pointing to the beginning of the file, because I getLine()s with it until the current line of the first ifstream object is reached. Once I reach that line with the second ifstream object, I then proceed to read every line after it until the end of the file, checking to see if the current line contains a html element which calls the current Javascript function.

That is the basic (beginning) logic of my ExtractJavascriptFromHtmlPage program. To have done what you suggested would mean I would have to close() the C_script_operations::input_stream2 (which is the second ifstream object), and then call C_script_operations:penFile() after each call to C_script_operations::findScriptTag() and then to C_script_operations::findJsFunctionNames(), and then proceed to call C_script_operations::findHtmlElementsWithJsFunctio nCall(), and I didn't want to do that, due to the nature of my loop in int main(). I would have had to change some things, I think. So rather than rewrite code I had already written, I opted to find the better solution of starting the second ifstream object (input_stream2) at the top of the file again, if input_stream2.eof() returned true at the top of the function findHtmlElementsWithJsFunctionCall().

EDIT: don't know why its formatting the function name like that (especially since the same name is fine for most of them)...
There shouldn't be a space after 'o' and before 'n' in "Function", and there isn't in the editing window, so I don't know what's up.

Originally Posted by whiteflags

Call them in the wrong order didya?

Code:

        fin.clear( );
        fin.seekg( 0, std::ios::beg );

tellg() would say 0, so you're at the beginning.

Btw, why does the order matter anyway??
It seems to me like it shouldn't...

EDIT: Unless maybe seekg() sets some flags which are reset by clear() if you put the clear() call after. Yeah, that's probably what it is...

Originally Posted by Programmer_P

Btw, why does the order matter anyway??
It seems to me like it shouldn't...

EDIT: Unless maybe seekg() sets some flags which are reset by clear() if you put the clear() call after. Yeah, that's probably what it is...

Pretty much all the functions in I/O have a blurb that includes something like "if the failbit or badbit is set for the stream, then nothing happens". You have to put the stream back into a good state before you can do anything.

Originally Posted by tabstop

Pretty much all the functions in I/O have a blurb that includes something like "if the failbit or badbit is set for the stream, then nothing happens". You have to put the stream back into a good state before you can do anything.

Ahh, ok. Thanks.
I'll make a mental note of that for future reference then, so I don't make the same mistake with I/O functions.

Originally Posted by Programmer_P

That is the basic (beginning) logic of my ExtractJavascriptFromHtmlPage program. To have done what you suggested would mean <snip>

Yeah, OK. Existing code, structured in way that is not amenable to be changed for the alternative approach I suggested.

While I certainly don't consider there is anything wrong with the clear/seek approach, having a code structure that discourages you from using a equally simple (arguably simpler) alternative approach is usually a sign that the code will be increasingly hard to change in future. At some point, you will need to bite the bullet and structure things in a manner easier to maintain.

Originally Posted by grumpy

Yeah, OK. Existing code, structured in way that is not amenable to be changed for the alternative approach I suggested.

While I certainly don't consider there is anything wrong with the clear/seek approach, having a code structure that discourages you from using a equally simple (arguably simpler) alternative approach is usually a sign that the code will be increasingly hard to change in future. At some point, you will need to bite the bullet and structure things in a manner easier to maintain.

Good point, and I'll make a hypothetical note of it for future reference.

Originally Posted by grumpy

Yeah, OK. Existing code, structured in way that is not amenable to be changed for the alternative approach I suggested.

While I certainly don't consider there is anything wrong with the clear/seek approach, having a code structure that discourages you from using a equally simple (arguably simpler) alternative approach is usually a sign that the code will be increasingly hard to change in future. At some point, you will need to bite the bullet and structure things in a manner easier to maintain.

I can't speak for all implementations Grumpy... but there is also a speed issue here. On windows, at least, seeking to file postion 0 is one heck of a lot faster than closing and re-opening the file.