Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #16869 > unrolled thread

stream functions

Back to article view | Back to comp.lang.c

Contents

  stream functions "Bill Cunningham" <nospam@nspam.invalid> - 2012-02-07 16:50 -0500
    Re: stream functions John Gordon <gordon@panix.com> - 2012-02-07 23:07 +0000
      Re: stream functions "Bill Cunningham" <nospam@nspam.invalid> - 2012-02-07 18:31 -0500
        Re: stream functions "Bill Cunningham" <nospam@nspam.invalid> - 2012-02-07 18:33 -0500
          Re: stream functions Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-02-08 02:39 +0100
            Re: stream functions Keith Thompson <kst-u@mib.org> - 2012-02-07 18:39 -0800
              Re: stream functions "Bill Cunningham" <nospam@nspam.invalid> - 2012-02-07 22:36 -0500
                Re: stream functions Nobody <nobody@nowhere.com> - 2012-02-08 19:43 +0000
            Re: stream functions Barry Schwarz <schwarzb@dqel.com> - 2012-02-07 21:01 -0800
        Re: stream functions John Gordon <gordon@panix.com> - 2012-02-08 15:13 +0000
          Re: stream functions "Bill Cunningham" <nospam@nspam.invalid> - 2012-02-08 15:54 -0500
            Re: stream functions John Gordon <gordon@panix.com> - 2012-02-08 21:09 +0000
              Re: stream functions "Bill Cunningham" <nospam@nspam.invalid> - 2012-02-08 17:37 -0500
                Re: stream functions John Gordon <gordon@panix.com> - 2012-02-08 23:16 +0000
                  Re: stream functions Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-13 02:14 -0800
                    Re: stream functions James Kuyper <jameskuyper@verizon.net> - 2012-02-13 05:53 -0500
                      Re: stream functions Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-13 03:23 -0800
                    Re: stream functions Markus Wichmann <nullplan@gmx.net> - 2012-02-14 21:50 +0100
                Re: stream functions "Heinrich Wolf" <invalid@invalid.invalid> - 2012-02-09 10:45 +0100
                  Re: stream functions "Bill Cunningham" <nospam@nspam.invalid> - 2012-02-09 22:37 -0500
            Re: stream functions Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-13 02:17 -0800
        Re: stream functions gordonb.qxgs4@burditt.org (Gordon Burditt) - 2012-02-13 01:03 -0600
          Re: stream functions Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-13 08:23 +0000
          Re: stream functions Keith Thompson <kst-u@mib.org> - 2012-02-13 02:06 -0800
          Re: stream functions David Thompson <dave.thompson2@verizon.net> - 2012-02-18 23:12 -0500

Page 2 of 2 — ← Prev page 1 [2]

#17195

On Feb 8, 8:54 pm, "Bill Cunningham" <nos...@nspam.invalid> wrote:

<snip>

>     Ok so with a page of text, like a man page for example; scanning that
> text would best be done with what? scanf or fscanf?

scanf() reads from stdin fscanf() reads froma  file. What would you
think?

[toc] | [prev] | [next] | [standalone]

#17191

>    Yes I read the man pages. That's what it looked like to me. What you 
> said about f*pos functions handling things too big, well...It wasn't in the 
> man pages so it's new to me. 

These functions are new to C99.  

> I guess it would depend on what the sizeof that 
> pointer to that fpos_t type was I guess. What are you fseeking in a text 
> file for? 

It is very common for a program to fseek() to the end of a log file
(or sometimes a data file) to add messages to it.  Using fopen(name,
"a") is not always useful as you might sometimes write to somewhere
other than the end.

The combination of ftell() and fseek() is useful to go back to a
position where you've been before, and for a large file it is likely
to be faster than just reading stuff and throwing out the data.

It isn't that unusual to save the position of the line before you
read it, read the line, then when you find the line you want, fseek()
back to where the line begins, and re-write it.  Some NNTP server
implementations used this for the news "active" file.  You can't
change the length of the line, although you could possibly make
fields shorter if the format allows "padding".

> I know text right? What if I was seeking for  a number in a column 
> of a text file written with nano? Say 10. How would I skip all the other 

I presume "nano" is some kind of text editor, not a Star Trek character
nor an Apple product.

> 10's in the file?

fseek() seeks to a *POSITION* in a (text or binary) file.  It does
not look at the data in the file.  If you want a generalized "file
search" function or SQL implementation, look elsewhere.  You'll probably
need to read the file until you find the record/line that you want.
fseek() does not know of artificial constructs you might ascribe
to parts of a text or binary file like "line", "record", "column",
"paragraph", "chapter", "section", or "page".

[toc] | [prev] | [next] | [standalone]

#17192

On Mon, 2012-02-13, Gordon Burditt wrote:
[attribution lost]
>> I guess it would depend on what the sizeof that 
>> pointer to that fpos_t type was I guess. What are you fseeking in a text 
>> file for? 
>
> It is very common for a program to fseek() to the end of a log file
> (or sometimes a data file) to add messages to it.  Using fopen(name,
> "a") is not always useful as you might sometimes write to somewhere
> other than the end.

Explain, please. My manual says about "a":

   Open for appending (writing at end of file).  The file is created
   if it does not exist.  The stream is positioned at the end of the
   file.

Someone else might have appended to the file after you fopen()ed it,
but the same is true for fseek().

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#17193

gordonb.qxgs4@burditt.org (Gordon Burditt) writes:
> John Gordon wrote:
>>    Yes I read the man pages. That's what it looked like to me. What you 
>> said about f*pos functions handling things too big, well...It wasn't in the 
>> man pages so it's new to me. 
>
> These functions are new to C99.  

No, fgetpos() and fsetpos() are in C90.

[attribution line added]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#17593

On Mon, 13 Feb 2012 01:03:22 -0600, gordonb.qxgs4@burditt.org (Gordon
Burditt) wrote:

> >    Yes I read the man pages. That's what it looked like to me. What you 
> > said about f*pos functions handling things too big, well...It wasn't in the 
> > man pages so it's new to me. 
> 
> These functions are new to C99.  
> 
Nope, fgetpos/fsetpos/fpos_t were new in C89.

POSIX ftello/fseeko/off_t were later, but still before C99 IIRC.
(And offtopic.)

> The combination of ftell() and fseek() is useful to go back to a
> position where you've been before, and for a large file it is likely
> to be faster than just reading stuff and throwing out the data.
> 
<snip example>

Yep. And for a large file that's very likely an understatement.

> fseek() seeks to a *POSITION* in a (text or binary) file.  It does
> not look at the data in the file.  <snip>
> fseek() does not know of artificial constructs you might ascribe
> to parts of a text or binary file like "line", "record", "column",
> "paragraph", "chapter", "section", or "page".

Well, if you use fixed length records fseek(,rec*K,SEEK_SET) works, at
least in a binary stream. And some structures use metadata that points
to byte locations, such as a B-tree index. But for probably most of
the files most application programmers use nowadays, I agree.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web