read file from end to beginning..

[soul_rebel]

Yeah, QFile inherits one called seek()

in qt3 it doesnt...

but i could get the last position with size and move backwards with at() until i reach the 5th-last line and then simply readline...
i'll try that now...

@wysota: since your example parses the fil from the beginning, it could be rather slow in my app (the file could well be a couple of megs)

[soul_rebel]

ok this does it:

QString UpdateAvSrc::getLastLinesFromFile(QString pathToFile, int lines)
{
	QFile file(pathToFile);
 
	if (!file.exists())
		return "file doesn't exist...";
 
	file.open(IO_ReadOnly);
 
	file.at(file.size()-1);
 
	int count = 0;
 
	while ( (count <=lines) && (file.at() > 0) )
	{
		QChar ch = file.getch();
		file.at(file.at()-2); /// minus 2 because getch moves one forward
 
		if (ch == '\n')
			count++;
 
	}
 
	QString r = file.readAll();
 
	file.close();
 
	return r;
}

QString UpdateAvSrc::getLastLinesFromFile(QString pathToFile, int lines)
{
	QFile file(pathToFile);
	
	if (!file.exists())
		return "file doesn't exist...";

	file.open(IO_ReadOnly);
	
	file.at(file.size()-1);
	
	int count = 0;
	
	while ( (count <=lines) && (file.at() > 0) )
	{
		QChar ch = file.getch();
		file.at(file.at()-2); /// minus 2 because getch moves one forward
		
		if (ch == '\n')
			count++;
		
	}

	QString r = file.readAll();
	
	file.close();
	
	return r;
}

To copy to clipboard, switch view to plain text mode 

[wysota]

@wysota: since your example parses the fil from the beginning, it could be rather slow in my app (the file could well be a couple of megs)

Yes, I know. I said it's simple, not that it's fastest. But reading char by char and making a seek every read is not efficient too. The fastest thing would be probably to make a kind of binary search -- split the file in half, take the second half, split it in half, take the second half, etc. until you have a single character. If it's a newline, mark the newline as found and go back one step, take the preceding character, check if it's newline, etc. If you do a smart check of each group, finding a n-th newline from the end of the file shouldn't be hard. Of course, in the worst case you have to scan the whole file...

[soul_rebel]

if i only want the last three or five lines of a logfile that may have up to 40000 lines it is faster to read char by char from the end than continously splitting the thing in halves, is it not?
thanks anyway!

[wysota]

if i only want the last three or five lines of a logfile that may have up to 40000 lines it is faster to read char by char from the end than continously splitting the thing in halves, is it not?
thanks anyway!

Provided that you know that it contains 40000 lines, than yes. But what if it contains three or four (huge) lines?

Besides, it is never worth reading char by char. Every device reads (at least) a complete block at once, so you can safely go 1024 by 1024 bytes at a time. It'll be much faster this way. And if you notice, that's like splitting the file in "halves" up to a 1k slice -- the algorithm is always the same, no matter if you start from beginning, end or from the middle. The whole idea is to have a way to check if a slice contains a new line without scanning each byte, to gain some computing time. If it doesn't, it's not worth checking it. For example on Windows you'd have to check only each second byte, as the newline consists of two characters. Another way would be to use 32b calculations to check whether a block may contain a newline.

One way or the other, if you really value your time -- just cut&paste the code from "tail"

[zxzxy1988]

mark it... I was confused by the question several days ago

[ChrisW67]

Did you really need to wake up a six year old thread to add a nonsensical comment?