问题描述
在考虑替换文件中的单词时线程，我想知道只用一个文件指针完成同样的事情是多么容易
。这导致了一些问题...
"对于文本流，offset必须为零，或ftell返回的值（在
哪个案例来源必须是SEEK_SET）。
如果offset是ftell返回的值（返回当前文件
位置），原点是SEEK_SET，然后fseek（）将位置设置为
当前位置。这样做有什么意义？而且，更重要的是，为什么
不能像二进制流一样随机发送文本流（即，
offset可以是任意数量的字节）？我是否正确理解了这一段？
如果是这样，fgetpos（）和fsetpos（）可以用于近似fseek（）的文本
streams？
-
Christopher Benson-Manica |我*应该*知道我在说什么 - 如果我
ataru（at）cyberspace.org |不，我需要知道。火焰欢迎。
如果您将其视为
或之前由ftell返回的值，那似乎更有意义，"所以你
可以保存ftell值并在以后使用它。
-
Michael
Aahh ...;（现在*那*更有意义。但是，为什么限制？或者
相反，为什么二进制流可以随时寻找他们想要的东西，而文本
流被限制为适当的并且寻找至少是某个地方/>
在过去的某个时间点有效吗？也许我应该回家，呃？;）
-
Christopher Benson- Manica |我*应该*知道我在说什么 - 如果我
ataru（at）cyberspace.org |不，我需要知道。火焰欢迎。
Aahh ......;（现在*那*更有意义。但是，为什么限制？或者
通常，对此感到疑惑的人会想到
试图fseek（）到一个算术计算的位置
文件中的
：在这样的一个或多个字符之前或之后的某些字符 - 这是一个位置。但是这个新职位应该如何界定？b $ b？ fseek（stream，1000，SEEK_SET）应该去哪里？
- 从
开始并做getc时你会达到相同的位置（流）1000次？这个
可能需要和getc（）s一样长，如果
，则无法计算目的地。对于
示例，请考虑读取MS-DOS文件，其中
对CR / LF必须转换为单个''\ n''
个字符;正确的目的地取决于如何跳过很多这样的对，并且如果没有实际读取它们，可能不会知道。
- 文件开头的1000个字节？这可能
根本不是一个有效的角色位置;它可能无法通过重复的getc（）来
到达那个位置
。例如，考虑读取一个OpenVMS VAR文件，其中每行包含一个双字节计数，一个有效负载和一个有效负载。和一个可能的填充
字节。这些字节中的一些没有图像。在
数据中getc（）可以读取，反之，getc（）返回的''\ n''字符
实际上并不存在于文件中。 br />
那里有很多文件组织，
以及支持文本流中任意搜索的要求
会使高效的C实现很难或不可能。
创建fgetpos（）和fsetpos（）的原因之一是
，以便为文件系统提供更好的支持，而不是那些
C长大了。
-
On thinking about the "replace a word in a file" thread, I wondered how easy
it would be to accomplish the same thing with only one file pointer. This led
me to some questions...
"For a text stream, offset must be zero, or a value returned by ftell (in
which case origin must be SEEK_SET)."
If offset is a value returned by ftell (which returns the current file
position), and origin is SEEK_SET, then fseek() sets the position to the
current position. What is the point of doing so? And, more importantly, why
can''t text streams be fseek()''ed randomly like a binary stream can (i.e.,
offset can be any number of bytes)? Do I understand this paragraph correctly?
If so, can fgetpos() and fsetpos() be used to approximate fseek() for text
streams?
--
Christopher Benson-Manica | I *should* know what I''m talking about - if I
ataru(at)cyberspace.org | don''t, I need to know. Flames welcome.
It seems to make more sense if you read that as
"or a value previously returned by ftell," so you
may save the ftell value and use it later.
--
Michael
Aahh... ;( Now *that* makes more sense. Still, why the restriction? Or
rather, why do binary streams get to seek whereever they want, while text
streams are constrained to be proper and seek to someplace that was at least
valid at some point in the past? Maybe I should just go home, eh? ;)
--
Christopher Benson-Manica | I *should* know what I''m talking about - if I
ataru(at)cyberspace.org | don''t, I need to know. Flames welcome.
Aahh... ;( Now *that* makes more sense. Still, why the restriction? Or
rather, why do binary streams get to seek whereever they want, while text
streams are constrained to be proper and seek to someplace that was at least
valid at some point in the past? Maybe I should just go home, eh? ;)
Usually, people who wonder about this are thinking of
trying to fseek() to an arithmetically-calculated position
in the file: so-and-so many characters before or after such-
and-such a position. But how should this new position be
defined? Where should fseek(stream, 1000, SEEK_SET) land?
-The same position you''d reach by starting at the
beginning and doing getc(stream) 1000 times? This
might take just as long as doing the getc()s, if
there''s no way to calculate the destination. For
example, consider reading an MS-DOS file, where
pairs of CR/LF must be translated to single ''\n''
characters; the proper destination depends on how
many such pairs are skipped over, and that may not
be knowable without actually reading them.
-1000 bytes from the start of the file? That might
not even be a valid character position at all; it
might not be possible to arrive at that position
by repeated getc()s. For example, consider reading
an OpenVMS VAR file, where each line consists of a
two-byte count, a "payload," and a possible padding
bytes. Some of those bytes have no "image" in the
data getc() can read, conversely, the ''\n'' characters
returned by getc() do not actually exist in the file.
There are lots and lots of file organizations out there,
and a requirement to support arbitrary seeking in text streams
would make efficient C implementations difficult or impossible.
One of the reasons fgetpos() and fsetpos() were created was
to give better support to file systems less simple than those
C grew up with.
--
Er*********@sun.com
这篇关于FSEEK的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！