Seeking and Reading a CFile
Nick Schultz
I can execute the first Read fine, reading in BUFFER_LENGTH bits...
I then loop through the data, reading and handling different data types (In
my example below, I only showed one case but other types are similar), I
just use one byte to distinquish between different types.
After finding out the type, I check to make sure that the entire structure
made it in the buffer, if not I then try to reposition the file pointer by
dwRead-i, such that the first byte read in is the same type identifier and I
can resume reading the entire type.
I thought this should work, however on the second Read, dwRead = 0, meaning
no bytes were read.
What did I do wrong?
Here is the code:
Cfile file;
file.Open(...);
while((dwRead = file.Read(buffer, BUFFER_LENGTH)) > 0){
bool refill;
for(int i = 0 ; i < dwRead;i++)
{
//first make sure there was enough room to read next byte (size
byte)
if(i == (dwRead -1)){
//the type identifier was the last byte, reposition -1 and get
another chunk
file.Seek( -(dwRead - i) , CFile::current);
break;
}
refill = false;
switch(buffer[i])
{
case DATAPT:
if( (i + sizeof(DataPt) ) >= dwRead-1){
file.Seek( -(dwRead - i) , CFile::current);
refill = true;
}
else{
handleDataPt((DataPt*) &buffer[i+1]);
i += sizeof(DataPt);//advance i past size of DataPt to
next type Identifier
}
break;
}
if(refill)
break;
}
if(refill && dwRead != BUFFER_LENGTH)
break;//requested to refill, however it was end of file...corrupted
data
}
file.Close();
Thanks,
Nick
Nick Schultz
file.Seek( -(dwRead - i) , CFile::current);
to:
int move = -(dwRead - i);
file.Seek( move , CFile::current);
and it now works.. why is this so?
Nick
"Nick Schultz" <nick.s...@flir.com> wrote in message
news:OdLnyirE...@TK2MSFTNGP06.phx.gbl...
Nick Schultz
file.Seek( (int)-(dwRead - i) , CFile::current);
dwRead and i are both ints, why aren't the results ints as well?
Nick
"Nick Schultz" <nick.s...@flir.com> wrote in message
news:OGjESnrE...@TK2MSFTNGP04.phx.gbl...
Tom Serface
Do you get any warnings? What is dwRead defined as? Perhaps you have an
unsigned conversion problem.
Tom
"Nick Schultz" <nick.s...@flir.com> wrote in message
news:OdLnyirE...@TK2MSFTNGP06.phx.gbl...
Norbert Unterberg
Nick Schultz schrieb:
> also casting it to an int works as well:
> file.Seek( (int)-(dwRead - i) , CFile::current);
>
> dwRead and i are both ints, why aren't the results ints as well?
>
Look again; the name "dwRead" implies it is a DWORD. If it is not then it is an
abuse of hungarian notation and you should drop the "dw" prefix.
Norbert
Giovanni Dicanio
"Nick Schultz" <nick.s...@flir.com> ha scritto nel messaggio
news:OdLnyirE...@TK2MSFTNGP06.phx.gbl...
> while((dwRead = file.Read(buffer, BUFFER_LENGTH)) > 0){
Reading CFile::Read prototype here:
http://msdn.microsoft.com/en-us/library/ctka0kks(VS.80).aspx
CFile::Read returns a UINT (unsigned int).
So, probably dwRead is a UINT in your code?
Considering the *unsigned* nature of dwRead, I would prefer a control like:
(dwReade = file.Read(...)) != 0
instead of > 0 (I would use > or < only for *signed* integers, not unsigned
ones).
> bool refill;
> for(int i = 0 ; i < dwRead;i++)
This is not correct, because dwRead is an unsigned int, and so 'i' should be
the of the same type (or a type with larger range). Instead, you are looping
using an int.
I would do:
for ( UINT i = 0; i < dwRead; i++ )
...
> if(i == (dwRead -1)){
Maybe you have problems here because 'i' and 'dwRead' are of different
types...
You may try defining both 'i' and 'dwRead' as UINT.
Giovanni
Joseph M. Newcomer
examination of the CFile::Seek documentation will reveal:
virtual ULONGLONG Seek(LONGLONG lOff, UINT nFrom)
So if you compute a negative size of an unsigned value, you get a 32-bit negative number,
but then it is expanded to a massive positive offset when the value is converted to a
LONGLONG.
Something about using the correct datatypes comes to mind here. A DWORD is most
*definitely not* an int! You are erroneously presuming
(a) a DWORD is an int
it is not, this is a mistake; one is unsigned long and the other is (signed) int and
(b) you can use a 32-bit offset when a 64-bit offset is required
obtaining a 64-bit offset by zero-extending an unsigned value which is supposedly
representing a signed value is clearly an error.
The failure of trusting HN to tell you what is going on is also an error. (a) don't use
it (b) if you must use it, USE THE CORRECT DATA TYPES AND THE CORRECT PREFIX.
The point of using the (int) cast is that it forces a sign-extended conversion of the
value. What will cause it to work correctly all the time is using the correct data types.
joe
On Wed, 10 Sep 2008 08:34:31 +0200, Norbert Unterberg <nunte...@newsgroups.nospam>
wrote:
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm