Boost.Filesystem what would you add?

  • Thread starter Steven T. Hatton
  • Start date
S

Steven T. Hatton

Anybody looked at this stuff?

http://www.boost.org/libs/filesystem/doc/index.htm

Most of it seems fairly straightforward. If you happen to do thing such as
put ~/code/c++/project in your path, be sure to read up on

boost::filesystem::path::default_name_check(boost::filesystem::native);

(BTW, C++ should splat the last std::exception to console by _default_!)

IIRC Dietmar mentioned wanting to get suff like the name and filesize from
an fstream. This won't do exactly that. In particular, I don't see a way
of asking an fstream for it's filename. It does have a utility to check
the size of a file, however. You could probably build some kind of smart
file handle with all the pieces.

I'd like to see a generic stream handle that would file I/O and network I/O
uniformly.
 
D

Dietmar Kuehl

Steven said:
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.

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.
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.
 
S

Steven T. Hatton

Dietmar said:
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.
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
 
D

Dietmar Kuehl

Steven said:
BTW, I'm
not sure if a file can actually have two 'real' names.

On POSIX systems files can have more than one "real" name. It is
called a "hard link". You can determine the number of current
hard links for a file (or a file descriptor) but you cannot determine
[easily] the set of names.
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.

Stream buffers are not designed to work this way.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top