By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,113 Members | 1,409 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,113 IT Pros & Developers. It's quick & easy.

Boost.Filesystem what would you add?

P: n/a
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.
--
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
Aug 3 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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.

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.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
Aug 3 '05 #2

P: n/a
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
Aug 3 '05 #3

P: n/a
Steven T. Hatton wrote:
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.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
Aug 3 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.