Dietmar Kuehl wrote:
Steven T. Hatton wrote: IIRC Dietmar mentioned wanting to get suff like the name and filesize
from an fstream.
I think you remember incorrectly! I know pretty well that a file may
not be associated with any name. For example, it is not that unusual for
temporary files to be openend and immediately be removed on POSIX systems:
the file and its contents is still around, but it has no name. In
addition, POSIX files can have many names.
Yes. This is true. But that doesn't mean there's no value in getting a name
when it exists. I was thinking in terms of something explicitly designed
to work with named files, and files which are 'predictable'. I talking
about something that the program would assemble, not some thing you could
apply to every file descriptor to extract information from it. BTW, I'm
not sure if a file can actually have two 'real' names. I know they can be
symlinked, but you can test to see if that's really the name. It's been
quite some time since I studied the details of file systems, and I'm sure
they've changed.
Likewise, I have never been interested much in file size because this is
a pretty volatile property anyway: when you have read it, it may not be
correct anymore because some other process may have written to the file.
As for getting the file size, I thought that would be useful to allocate
space for it when you read it in. That /does/ raise some interesting
questions, such as how to find out if the file (size) has changed since you
opened it.
It seems to me move semantics could be useful here. It may actually be
what's happening in some cases already. That is, allocate a filebuf with
the size of the file, read the file in, and hand the buffer over to, say, a
vector, rather than copying the content of the buffer from one location to
another.
I'd like to see a generic stream handle that would file I/O and network
I/O uniformly.
This is, IMO, the wrong way to go in a C++ context. The way to go is
to implement stream buffers for the relevant streams.
I meant handels in the abstract. Sure, the underlying implementation is
going to vary, but there are certain concepts which apply to both reading a
file from a harddrive, and reading it from a network connection. Perhaps
you don't see that as the perview of the Standard. I know this sort of
thing is done with C++. I can point Konqueror at many different kinds of
resources (i.e., use different protocols), and get a uniform user
interface.
svn://anonsvn.kde.org/home/kde/trunk/KDE
sftp://my.secure.host/path/to/stuff
ftp://ftp.suse.com/
file://home/usrname/
smb://path/to/resource
shttp://secure.host.abc/
http://doc.trolltech.com/4.0/index.html
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell