how do i read odd numbered lines from a file

[rudranee]

hi there,
can anyone tell me how to lines from a file which are odd numbered i.e.
1st,3rd,5th...lines.

i tried incrementing file pointer by 2 (fp=fp+2)
but it does'nt work
Can someone give me the code please.

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

hi there,
can anyone tell me how to lines from a file which are odd numbered i.e.
1st,3rd,5th...lines.

i tried incrementing file pointer by 2 (fp=fp+2)
but it does'nt work
Can someone give me the code please.

You could just read in two lines to the same char-array, thereby
discarding the one you don't want. And the filepointer is incremented
the correct number of bytes each time.

So the problem with fp=fp+2 is that line lengths can vary and you don't
know each linelength on beforehand...


Best regards
Martin Jørgensen

 

[Richard Heathfield]

Martin Jørgensen said:

You could just read in two lines to the same char-array, thereby
discarding the one you don't want. And the filepointer is incremented
the correct number of bytes each time.

No, it isn't!

The file pointer is NOT incremented, because the file pointer does not point
to the file! I know it sounds like it does, but it really, really doesn't.
What it points to is some internal doodad that contains information about
the file. One of the items of information that internal doodad stores is a
"file position indicator" - and /that/ is incremented.

So the problem with fp=fp+2 is that line lengths can vary and you don't
know each linelength on beforehand...

No, the problem with fp=fp+2 is that it turns a valid pointer into an
invalid one for no gain. Please don't give advice unless you are absolutely
100% sure it's correct - and even then, please check in K&R or the Standard
to ensure that you are right to be sure.

 

[Roberto Waltman]

can anyone tell me how to lines from a file which are odd numbered i.e.
1st,3rd,5th...lines.

i tried incrementing file pointer by 2 (fp=fp+2)
but it does'nt work
Can someone give me the code please.

If by "incrementing the file pointer" you mean you did this:

#include <stdio.h>

...
FILE *fp = fopen(...);
...
fp = fp + 2;
...

That does not do what you want; Surprisingly, it increments the file
pointer, it does not read from the file, or modify the current
position in the file stream in any way.
After the increment fp will have a value 2*sizeof(FILE) bytes larger
than before, pointing to a memory area that most likely is not a FILE
structure and definitively is not the FILE structure you opened.
Attempting to read via fp will cause undefined behavior. (Because it
will modify random memory locations)

Hint: If you had in front of you a document (printed single side) and
you wanted to read only the odd numbered pages. How would you do it?

 

[santosh]

hi there,
can anyone tell me how to lines from a file which are odd numbered i.e.
1st,3rd,5th...lines.

A line is defined in C as a sequence of characters terminated by a
newline character. While the actual end-of-line sequence varies between
operating systems, the C standard library ensures conversion to the
newline character.

So to read odd numbered lines, you'll have to read from the beginning
of the file and keep track of each line. You can store the odd lines
into your buffer while even lines can simply be read and discarded.

i tried incrementing file pointer by 2 (fp=fp+2) but it does'nt work

A pointer to type FILE is not a "file pointer" in the sense you seem to
understand. It points to an internal, implementation defined, data
structure which hold a lot of "meta" information about the file to
which it is attached. Merely changing this pointer's value will give
you pointer pointing to an unknown area of memory, which will
eventually cause undefined behaviour.

Can someone give me the code please.

This group helps those who make a sincere attempt, not those who simply
want to pass the course, by hook or by crook, even if it's only for a
mind-numbing BPO job.

So, try your best attempt, and if you encounter problems, post your
question and your code.

 

[Simon Biber]

hi there,
can anyone tell me how to lines from a file which are odd numbered i.e.
1st,3rd,5th...lines.

Others have given you some good advice already. Here is some pseudo-code:

FILE *fp = fopen(filename, "r");
if(fp)
{
char buf[1024];
while(fgets(buf, sizeof buf, fp))
{
/* discard the line we just read and read another */
if(!fgets(buf, sizeof buf, fp)) break;

do_something_with(buf);
}
}

i tried incrementing file pointer by 2 (fp=fp+2)
but it does'nt work

Sorry but this just made me laugh out loud!

The file pointer does not point into an array of lines in the file. It
points to some data structure that, in a system-specific way, holds
whatever state information is required about an open file, the current
position, and the buffering. A FILE* object should only ever hold either
a null pointer or the result of an fopen function.

There is a way to seek to a particular location in a file if you know
its byte offset. Unfortunately, there's no simple way to determine where
each line starts and ends, without reading all the characters in and
comparing them to '\n'. That's what the fgets function that I used above
does.

 

[CBFalconer]

can anyone tell me how to lines from a file which are odd
numbered i.e. 1st,3rd,5th...lines.

Others have given you some good advice already. Here is some
pseudo-code:

FILE *fp = fopen(filename, "r");
if(fp)
{
char buf[1024];
while(fgets(buf, sizeof buf, fp))
{
/* discard the line we just read and read another */
if(!fgets(buf, sizeof buf, fp)) break;

do_something_with(buf);
}
}

That has the problem of coping with the EOL actions of fgets. I
suggest ggets (see below for availability) is more suitable.

char *buffer;
FILE *fp;

if (fp = fopen(filename, "r") {
do {
if (0 != fggets(fp, &buffer) break;
free(buffer); /* discard odd numbered lines */
if (0 != fggets(fp, &buffer) break;
doSomethingWith(buffer);
free(buffer);
} while (1);
} /* untested */

See <http://cbfalconer.home.att.net/download/>

--
"Our enemies are innovative and resourceful, and so are we.
They never stop thinking about new ways to harm our country
and our people, and neither do we." -- G. W. Bush.
"The people can always be brought to the bidding of the
leaders. All you have to do is tell them they are being
attacked and denounce the pacifists for lack of patriotism
and exposing the country to danger. It works the same way
in any country." --Hermann Goering.

 

[Andrew Poelstra]

Others have given you some good advice already. Here is some pseudo-code:

That's some mighty C-looking psuedo-code. ;-)

FILE *fp = fopen(filename, "r");
if(fp)
{
char buf[1024];
while(fgets(buf, sizeof buf, fp))
{
/* discard the line we just read and read another */
if(!fgets(buf, sizeof buf, fp)) break;

do_something_with(buf);
}
}

i tried incrementing file pointer by 2 (fp=fp+2)
but it does'nt work

Sorry but this just made me laugh out loud!

It made me reread the original post a few times. Then I laughed.

From your code I read "sizeof buf", which is one of those obvious things
I never thought of. I would have always written 1024, and then changed
the number in two places every time I needed to. The unnecessary pains
I go through because I don't think...

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Martin Jørgensen said:




No, it isn't!

The file pointer is NOT incremented, because the file pointer does not point
to the file! I know it sounds like it does, but it really, really doesn't.
What it points to is some internal doodad that contains information about
the file. One of the items of information that internal doodad stores is a
"file position indicator" - and /that/ is incremented.

I also meant that.

No, the problem with fp=fp+2 is that it turns a valid pointer into an
invalid one for no gain. Please don't give advice unless you are absolutely
100% sure it's correct - and even then, please check in K&R or the Standard
to ensure that you are right to be sure.

That was my mistake... But please don't think that errors don't get
corrected by other people in this newsgroup and that it therefore is an
absolute catastropy to write comments to other peoples posts. This group
is large enough for both (or all three of us). I was thinking of some
FSEEK code I recently made where the file position can be incremented or
stored just as the OP had in mind and I don't see anything wrong in
telling him that the line lengths vary and therefore he can't do what he
probably thought he could do.


Best regards
Martin Jørgensen

 

[Peter Nilsson]

hi there,
can anyone tell me how to lines from a file which are odd numbered i.e.
1st,3rd,5th...lines.

Others have given you some good advice already. Here is some pseudo-code:

FILE *fp = fopen(filename, "r");
if(fp)
{
char buf[1024];
while(fgets(buf, sizeof buf, fp))
{
/* discard the line we just read and read another */
if(!fgets(buf, sizeof buf, fp)) break;

do_something_with(buf);
}
}

Note that this processes the 2nd, 4th, etc... lines, and at face value
it ignores
the possibility that a line may be longer than sizeof buf characters.

You can avoid storing the line unnecessarily by doing something like...

if (fscanf(fp, "%*[^\n]") != EOF)
fgetc(fp);

 

[Richard Heathfield]

Martin Jørgensen said:

That was my mistake...
Indeed.

But please don't think that errors don't get
corrected by other people in this newsgroup and that it therefore is an
absolute catastropy to write comments to other peoples posts.

Well, it's not an absolute catastrophe, no, but it does increase our
workload if people give incorrect advice, and of course there is always the
danger that the advice might slip through the net and go uncorrected.

This group is large enough for both (or all three of us).

And indeed for many more. Please don't misunderstand me. You are most
welcome in comp.lang.c, not least because you seem very capable of
listening, learning, and asking bright questions. We're counting on you to
become an expert so that we can all retire and leave all the questions for
you to answer.

But please do try to take a little more care, that's all. Let me put it this
way - your answer showed that you don't really understand the whole "file
pointer" idea, right? Now, I would be prepared to bet a carrot, or maybe
even a potato, that you /knew/ you didn't really understand it. Am I right?

It turns out that, by answering a question wrongly, you gained the
opportunity to learn a little about file pointers. So all's well that ends
well. But if you get this sneaky feeling that you don't really know what
you're talking about, it's better not to answer at all than to guess.

Trust me on this. I've been there, done that, got several T-shirts and scars
to prove it. I've learned that guessing how C works is not the best way to
help people. Once, quite a few years ago now, I even made the mistake of
saying "The Standard says that such-and-such is the case", because it
seemed obvious to me that it would say that, so I didn't feel it necessary
to go and look - and about eighteen trillion people all yelled "WHERE does
it say that?" So I went and looked - and looked, and looked, and looked,
and to my astonishment the Standard didn't say that at all! I had to
apologise for making an incorrect claim, and of course I felt a bit of a
fool. Don't make the same mistake.

I was thinking of some
FSEEK code I recently made where the file position can be incremented or
stored just as the OP had in mind

Sure, but it's the file /position/ that is modified, not the file pointer.
It is a significant distinction.

and I don't see anything wrong in
telling him that the line lengths vary and therefore he can't do what he
probably thought he could do.

That in itself is quite right, when carefully separated from your "file
pointer" advice.

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Martin Jørgensen said: -snip-

But please do try to take a little more care, that's all. Let me put it this

Got it.

way - your answer showed that you don't really understand the whole "file
pointer" idea, right? Now, I would be prepared to bet a carrot, or maybe
even a potato, that you /knew/ you didn't really understand it. Am I right?

No. I actually knew it, because I had seen a couple of times that the
file-pointer seem to point to some kind of data-structure holding some
strange data-values. Where did I see it? In my debugger...

It's no big deal and hard not to see IMO. I've now tried debugging
programs many times in windows, linux and on my macintosh computer with
even more different debuggers (tried at least 5-6) and every time I try
to investigate what FILE *fp points to I do see this strange
data-structure. I have also worked enough with pointers to know that
FILE *(fp+2) just points to a different memory location. I use a lot of
pointers in the program you just helped me with the other day and if I
didn't understood how pointers worked, I probably couldn't have done all
of that.

So I simply wrote the wrong answer, because I was thinking of some place
in my code where I got something like: position = ftell(fp); and that
can be incremented or decremented and I thought that the OP meant that
he could add 2 byte positions to get rid of CRLF to solve his problem
(thereby skipping an empty line).

The point is then: That also works for empty lines, but that's probably
not enough for him.

It turns out that, by answering a question wrongly, you gained the
opportunity to learn a little about file pointers. So all's well that ends
well. But if you get this sneaky feeling that you don't really know what
you're talking about, it's better not to answer at all than to guess.

I just got corrected and that's no big deal for me.

Trust me on this. I've been there, done that, got several T-shirts and scars
to prove it. I've learned that guessing how C works is not the best way to
help people. Once, quite a few years ago now, I even made the mistake of
saying "The Standard says that such-and-such is the case", because it
seemed obvious to me that it would say that, so I didn't feel it necessary
to go and look - and about eighteen trillion people all yelled "WHERE does
it say that?" So I went and looked - and looked, and looked, and looked,
and to my astonishment the Standard didn't say that at all! I had to
apologise for making an incorrect claim, and of course I felt a bit of a
fool. Don't make the same mistake.

Well I understand you and we all make mistakes. But if you never had
made any mistake, you probably wouldn't be where you are today. And you
wouldn't be half as good a programmer as you probably are today.

Sure, but it's the file /position/ that is modified, not the file pointer.
It is a significant distinction.

If I didn't knew that I probably couldn't have programmed my
import_data.c file, which you perhaps tried just the other day. It also
uses a lot of pointers to read in data from an input-file and it seeks
for [location]-values and does a lot of validation.

That in itself is quite right, when carefully separated from your "file
pointer" advice.

I get the point, but I don't consider the question the OP asked about to
be too difficult for me. I programmed something very similar to what he
asks about and it works quite good, although the code perhaps is
slightly ugly seen from a a more professional programmers point of view.

If I hadn't programmed this myself, well then I think I wouldn't have
answered. So I really don't think this is a very advanced or difficult
question and I don't feel I learned anything really new by this thread.


Best regards
Martin Jørgensen

 

[Dann Corbit]

(e-mail address removed)> wrote in message

hi there,
can anyone tell me how to lines from a file which are odd numbered i.e.
1st,3rd,5th...lines.

i tried incrementing file pointer by 2 (fp=fp+2)
but it does'nt work
Can someone give me the code please.

#include <stdio.h>
char string[32767];
int main(void)
{
int counter = 0;
while (fgets(string, sizeof string, stdin)) {
++counter;
if (counter % 2)
fputs(string, stdout);
}
return 0;
}

Of course, this is totally the wrong answer because it does not do what was
asked. It also reads the even numbered lines but it ignores them.

The right answer is to use a database (really -- I'm not kidding).

IMO-YMMV.

 

[Ben Pfaff]

(e-mail address removed)> wrote in message


The right answer is to use a database (really -- I'm not kidding).

Well, it depends. If you're writing a filter that processes an
entire file in sequential order, then I don't a database is the
right answer. If you're writing something that does complicated
or randomly ordered processing, then something like Berkeley DB
with the Recno backend might make a lot of sense.

 

[Dann Corbit]

Well, it depends. If you're writing a filter that processes an
entire file in sequential order, then I don't a database is the
right answer. If you're writing something that does complicated
or randomly ordered processing, then something like Berkeley DB
with the Recno backend might make a lot of sense.

I would argue that it is not possible in C (without using some sort of
database) to skip over lines in a file in the general case. If that is an
actual requirement, then C needs some kind of a helper (like a database).
Or we can limit the problem to binary files with fixed record length (which
again is not solving the problem as stated).

It's a stupid homework problem anyway. I don't think that the professor
should ask the students to do something that really is not possible to do
correctly with the tool set given.

The problem statement may not have been what was presented though. I am
guessing that we are missing some important details.

 

[Ben Pfaff]

I would argue that it is not possible in C (without using some sort of
database) to skip over lines in a file in the general case.

The OP didn't say he needed to skip lines. He just said he
needed to read the odd-numbered lines. I don't think there's
anything wrong with reading the whole file to solve that
problem.

[much snippage above, trying to focus on the bits I find
interesting]

 

[Dann Corbit]

The OP didn't say he needed to skip lines. He just said he
needed to read the odd-numbered lines. I don't think there's
anything wrong with reading the whole file to solve that
problem.

Quite right. I was thinking about reading only the odd numbered lines (IOW:
skipping lines) which can't really be done without some sort of assumptions
or extensions.

Probably, your answer is a lot better than mine then.

[much snippage above, trying to focus on the bits I find
interesting]

 

[Keith Thompson]

I would argue that it is not possible in C (without using some sort of
database) to skip over lines in a file in the general case. If that is an
actual requirement, then C needs some kind of a helper (like a database).
Or we can limit the problem to binary files with fixed record length (which
again is not solving the problem as stated).

It's a stupid homework problem anyway. I don't think that the professor
should ask the students to do something that really is not possible to do
correctly with the tool set given.

[...]

I must be missing something.

First off, the original question was incorrectly stated:

"can anyone tell me how to lines from a file which are odd
numbered ..."

Presumably there should be a verb between "to" and "lines".

Second, for any reasonable interpretation of the original question, I
don't seen any problem with doing it in standard C. Reading a line
whose maximum length isn't known in advance can be tricky, but there
are a number of functions floating around that do exactly that -- and
if you can assume a maximum length, you can just use fgets(). If you
want to store all the odd-numbered lines in memory, it's just a matter
of dynamic allocation: set up a pointer to (the first element of) an
array of char* pointers, each of which points to a dynamically
allocated string, and expand the array using realloc() as necessary.
Skipping every other line as you read the file is trivial. If all you
want to do is filter stdin to stdout, skipping even-numbered lines,
you don't even need to read a line at a time; just keep track whether
you've seen an even or odd number of '\n' characters, and use that to
decide whether to print each character.

Did you see something in the problem statement that I missed?

 

[Dann Corbit]

{snip}

Did you see something in the problem statement that I missed?

I misread the problem statement as "read only the odd numbered lines from a
file". I couldn't parse the original problem statement very well, so I read
between the lines a bit.

I think I interpreted it that way, because he was trying to accomplish the
task by advance the file pointer.

Ben was right. Just read the lines and spit out the odd numbered ones (like
the filter program I pasted in my earliest post on the topic).

 

[Keith Thompson]

{snip}

I misread the problem statement as "read only the odd numbered lines from a
file". I couldn't parse the original problem statement very well, so I read
between the lines a bit.

Which, given the problem statement, is of course exactly what you need
to do. }

I think I interpreted it that way, because he was trying to accomplish the
task by advance the file pointer.

Ok, I think I see what you mean. You thought he wanted to read only
the odd-numbered lines, not reading the even-numbered lines at all *as
opposed to* reading all the lines and discarding the even numbered
ones. (Which is probably a silly thing to do, even if you can figure
out a way to do it.) It's easy enough if you're allowed to do an
initial scan over the input file and create an index.