Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-08-14 16:12:27


At 02:59 PM 8/14/2002, Jeff Garland wrote:

>I'm trying to write a program to list a directory using the filesystem
lib
>and
>I'm running into a couple problems. First, here's the program:
>
>#include "boost/filesystem/operations.hpp"
>#include <iostream>
>
>namespace fs = boost::filesystem;
>
>int main()
>{
> try {
>
> fs::path start("/home");
                     ^^^^^^^^
Change this to:

      fs::path start("/home", fs::system_specific);
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> fs::directory_iterator end_itr;
> fs::directory_iterator dir_itr(start);
> for (;dir_itr != end_itr; ++dir_itr) {
> std::cout << (dir_itr->file_path()) << std::endl;
> }
> }
> catch(std::exception& e) {
> std::cout << e.what() << std::endl;
> }
>
> return 0;
>}
>
>The first problem is that the checking code will not construct "/home" as
a
>valid path. This is a result of invalid_chars containing a '/'. When I
>remove '/' from the invalid_chars array the construction is allowed to
>proceed
>as expected. Seems like "/home" should be allowed on Unix or
generically?

See above. It should definite work with the "system_specific" constructor.
It is a bug in filesystem code if it doesn't.

>The second problem is that the program crashes on a ~directory_iterator
>when it calls to the counted_base destructor which fails in free. I
could
>not reproduce the problem by just constructing the iterators so it must
>have something to do with the results of operator++. Any ideas?

No. I've got a Linux box here (or rather the pieces of one that I put
together when I need to), but haven't tested recent versions on it. I'm
planning to re-test before the formal review, but doubt I will get to that
for a couple of weeks unless the 1.29.0 release goes smoothly.

Sorry, that isn't much help. If you can get me any more information, maybe
a bell will ring. Do make sure you have the latest version from the
sandbox CVS.

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk