seekg Concerns On Fragmented File

[Tom]

Given: A binary data file of records.

Task: Random access using seekg().

I've never found any documentation stating that the offset from begin
file marker is safe on a fragmented file. I've observed how binary
files are buffered in the past. But I have never tested against a
fragmented file. Perhaps I am paranoid or whatever. Maybe
fragmentation is no worse than changing tracks on the drive?

If the fragment starts at byte 50 and you offset 100 bytes from the
begin marker ... does the method scan for fragments? If so, is it any
faster than a sequential read method?

Any thoughts on the topic?

Please, no OT police comments. Thanks.

-- Tom

[Victor Bazarov]

Tom wrote:

Given: A binary data file of records.

Task: Random access using seekg().

I've never found any documentation stating that the offset from begin
file marker is safe on a fragmented file.
There is no concept of "fragmentation" in C++ (or C) streams. The
continuity of the stream is ensured by the host system.
I've observed how binary
files are buffered in the past. But I have never tested against a
fragmented file. Perhaps I am paranoid or whatever.
Could be. Do you feel being watched?
Maybe
fragmentation is no worse than changing tracks on the drive?
"Tracks on the drive" concept is absent from C++ as well.
If the fragment starts at byte 50 and you offset 100 bytes from the
begin marker ... does the method scan for fragments? If so, is it any
faster than a sequential read method?
Could be. Impossible to tell without clocking them both.
Any thoughts on the topic?
Beyond what I've just typed, not really. Seeking ahead in a file
that allows direct access is often faster than reading out all of
the intermediate bytes. But if the stream is truly sequential, then
seeking forward is _exactly_ like reading out all extraneous bytes,
at least that's IME.
Please, no OT police comments. Thanks.
You've just made one. Why should others be deprived of that right?

-- Tom

V
--
Please remove capital As from my address when replying by mail

[Jim Langston]

"Tom" <Th********@earthlink.net> wrote in message
news:4q********************************@4ax.com...

Given: A binary data file of records.

Task: Random access using seekg().

I've never found any documentation stating that the offset from begin
file marker is safe on a fragmented file. I've observed how binary
files are buffered in the past. But I have never tested against a
fragmented file. Perhaps I am paranoid or whatever. Maybe
fragmentation is no worse than changing tracks on the drive?

If the fragment starts at byte 50 and you offset 100 bytes from the
begin marker ... does the method scan for fragments? If so, is it any
faster than a sequential read method?

Any thoughts on the topic?

Please, no OT police comments. Thanks.

-- Tom

Fragmentation and reading fragmentation happens at the OS level. Unless
you're writing your own disk driver you shouldn't have to worry about it.
As such, seekg is safe for fragmented files. If it wasn't safe, the OS
would be a piece of... well, you know, and unusable.

The OS itself is going to buffer the file read/writes independant of the
..exe's buffers in whatever language.

In other words, don't worry about it.

[Mike Wahler]

"Tom" <Th********@earthlink.net> wrote in message
news:4q********************************@4ax.com...

Given: A binary data file of records.

Task: Random access using seekg().

I've never found any documentation stating that the offset from begin
file marker is safe on a fragmented file. I've observed how binary
files are buffered in the past. But I have never tested against a
fragmented file. Perhaps I am paranoid or whatever. Maybe
fragmentation is no worse than changing tracks on the drive?

If the fragment starts at byte 50 and you offset 100 bytes from the
begin marker ... does the method scan for fragments? If so, is it any
faster than a sequential read method?

Any thoughts on the topic?

Please, no OT police comments. Thanks.

A (compliant) C++ implementation will ensure that all
stream operations treat a stream as a contiguous sequence
of characters, whether or not this is true at a 'lower level'
(e.g. OS, hardware, etc).

'File fragmentation' is an operating system issue,
not part of the 'abstract machine' defined by the
language.

-Mike

[Tom]

Victor, Jim, Mike -- thank you each for your input.

I've never been accused of being afraid to ask a question. I also have
zero fear of asking a dumb one, because I am so darn use to it by now.
:)

Every single day in this newsgroup I have learned. It's a very good
thing too.

There are many experts in here. Those who have more answers than
questions I salute you. I wonder ... is there some way to prompt the
gurus to just blog away in here about their C++ skills? Time is
precious and I am not trying to infringe on anyone's time ... but I
know I am not the only newb who'd be reading those blogs and
benefitting as well. hmmm, blog sounds a bit mundane. How about a
snazzy name: "C_log<xxx>"? Where "xxx" is the topic of your choice.
Easily identified and avoided by those so inclined, and also
highlighted for those who are anxious to read them. Excuse me,
sometimes I dream ..... Thanks again & good night.

- Tom

[Default User]

Tom wrote:

There are many experts in here. Those who have more answers than
questions I salute you. I wonder ... is there some way to prompt the
gurus to just blog away in here about their C++ skills?

I think the experts answering questions is more likely to result in
infodumps on topics that people are actually interested in. That's why
the question was asked in the first place.

Brian

[JustBoo]

On Wed, 08 Feb 2006 06:23:14 GMT, Tom <Th********@earthlink.net>
wrote:

I've never been accused of being afraid to ask a question. I also have
zero fear of asking a dumb one, because I am so darn use to it by now.
:)
"Keep on raging - to stop the aging." - Dale Carnegie :-)
Every single day in this newsgroup I have learned. It's a very good
thing too.
I used to do the same. It's harder nowadays with the clueless academic
NetCops.There used to be a lot more dicussion of C++ programming
instead of the same robotic answers repeated over and over. I can't
tell you how many "little gems" fell out of what would now be called
off-topic discussions. Not to say their wasn't a few egotistical
netcops around, but most just ignored them.
There are many experts in here. Those who have more answers than
questions I salute you. I wonder ... is there some way to prompt the
gurus to just blog away in here about their C++ skills?

This has happened from time to time. Herb Sutter used to do a, umm,
what was it called, Gotw: Gotcha of the Week? A little exercise
everyone could play with. He made a name for himself and now slaves
for the Evil Empire. "C++"/CLI... I don't know how he sleeps at night.
Oh wait, I guess I do: very, very richly that's how. I guess everyone
has their price. And no, I've never been offered mine yet. :-)

Plauger would/does reveal stuff on occasion while selling his wares. I
found Joseph Newcomer an absolute hoot. (Good Thing.) He was a
pragmatic Real Programmer (r)(tm) and didn't suffer the ludicrous
exercises of the Topic Nazis. (Probably why he doesn't come round
anymore.) Anyway...

I'm not sure there is anyone left here with the breadth of experience
and character that could do such a thing, and be the least bit
interesting. Most of the regulars here now are narrowly trained myopic
academics with little practical experience as far as I can tell. The
fact they can't figure out how to *skip a thread* they don't like
tells me all I need to know.

I think most of the people that could do it are now writing books or
are doing actual blogs. It is a great idea Tom. I don't want to be the
pessimist... anything could happen I guess.:-)

Behold! in Liberty's unclouded blaze, We lift our heads, a race of
other days. - Charles Sprague