Re: memory allocation question
From: Jerry Coffin (jcoffin_at_taeus.com)
Date: 10/21/04
- Next message: Ronen Kfir: "A loop with C struct"
- Previous message: Chris \( Val \): "Re: Simple constructor/copying Qs"
- In reply to: Chris \( Val \): "Re: memory allocation question"
- Next in thread: Chris \( Val \): "Re: memory allocation question"
- Reply: Chris \( Val \): "Re: memory allocation question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 21 Oct 2004 09:19:03 -0700
"Chris \( Val \)" <chrisval@bigpond.com.au> wrote in message news:<2t74tiF1rrlrkU1@uni-berlin.de>...
[ ... ]
> Hi Jerry.
Hi Chris.
[ ... ]
> | The problem in this case isn't with the type conversions involved. The
> | problem is that seeking to the end of a file opened in binary mode
> | simply may not work correctly at all, and even if it does, the size of
> | the file may not accurately reflect what you wrote to it.
>
> I'm interested in the part that may cause it to *not work correctly*,
> and the reason that it *may* not accurately reflect what I wrote to it.
The part can prevent it from working correctly is that some OSes
(mostly ones most of us would rather never see or hear about) use
strange formats for binary files that don't really support such
things. Seeking is based on the notion that a file fits the UNIXesque
notion that a file is a stream of bytes. Some OSes treat files (in
general) somewhat differently.
Differences range from mild, such as MacOS (pre-OS X) files having two
"forks", all the way to relatively wild, such as file systems that
build/maintain indexed files, so the indexes are parts of the file
proper -- some of these are only slightly short of a database manager
built into the file system. In these cases, a file is usually treated
more as a collection of records than a stream of bytes, and "end of
file" may be a difficult concept to define -- the order of records in
the file is based on which index is currently selected, so seeking to
the last record (in the order defined by some particular index) may
land you somewhere in the middle of the space used to store the
records.
[ ... ]
> Ok, I don't know or understand the technical how's or why's just
> yet, and I'll have to find some further material to read up on that.
One example many of us older farts had to deal with was CP/M: its
directory entry for a file simply did not have a field to tell how
long the file was. The file system only tracked which sectors on the
disk were dedicated to that file. If part of a sector was empty, the
file system didn't care: you got the whole sector anyway, and when you
read the last sector, it treated the entire sector as a valid part of
the file, regardless of how little had ever actually had anything
written to it.
> So was 'Josuttis' wrong to use such an construct himself then ?
Technically, probably yes. Realistically, it probably doesn't make a
huge difference: probably well over 90% of the people who read his
book work (almost) exclusively on systems where it's just fine. The
few to whom it doesn't apply are already accustomed to most books
being wrong about things like this anyway -- an in fact, are often
largely accustomed to C's file I/O being useless for their purposes
anyway.
> I understand that the book is no longer recent, but he seems to
> be pretty thorough, but at the end of the day, he still demonstrates
> it's use.
This isn't a new part of the language (it's been basically the same
since C89) so age shouldn't really be a factor. In reality, in this
case older books are a bit more likely to be accurate, since many of
the systems that make it significant are older mainframes and such
that still in fairly wide use when the C89 standard was written, but
are quickly fading into obscurity.
> | The bottom line is pretty simple: for portable code, you have only two
> | choices: either design your code so it'll work without knowing the
> | length of the file, or else record the information yourself, and read
> | it back in when you need it.
>
> I can't argue with that, it's too logical :-)
Sure you can -- you can argue that I'm being pedantic in my definition
of "portable". I'm defining "portable" as meaning that conforming to
the C++ standard requires it to work. Realistically, most peope will
never care about writing code that can be compiled (unchanged, no
#ifdef's, etc.) for absolutely everything that can claim to be C++.
For most people, totally non-portable code is just fine, and running
with minmal #ifdefs and such on Linux, Windows and MacOS is almost
more than they really even care about...
> Thanks Jerry.
Surely.
--
Later,
Jerry.
The universe is a figment of its own imagination.
- Next message: Ronen Kfir: "A loop with C struct"
- Previous message: Chris \( Val \): "Re: Simple constructor/copying Qs"
- In reply to: Chris \( Val \): "Re: memory allocation question"
- Next in thread: Chris \( Val \): "Re: memory allocation question"
- Reply: Chris \( Val \): "Re: memory allocation question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
