Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-03 17:03:35

At 12:29 PM 3/3/2002, Jeff Garland wrote:

>> iterator into an iterator matching the standard requirements for
>> iterators and the filenames seems to be an obvious choice for this: A
>> basic goal was to make simple things simple and filling a container
>> the names in a container using
>> std::vector<std::string> dir((dir_it("dir2")), dir_it());
>> seems to be easy enough (note, BTW, that your approach makes even
>> like this much harder!).
>What's wrong with:
> std::vector<std::directory_entry> dir((dir_it("dir2")), dir_it());
>I don't see why this is harder...

I'm with Jeff; I don't see the problem. In fact his code above is one of
my test cases.

>Well sometimes the client will want the full path and sometimes not. The
>earlier discussion was that the client needs a way to manipulate these
>without having to write non-portable path manipulation code.

Yes, and also without having to explicitly call composition or
decomposition functions.

>> The whole property map issue is to avoid special handling of
>I'm not generally in disagreement with the property map approach...

And I'm not either, particularly for most of the attributes, which may vary
from system to system.

But there are a few basic attributes (name, directory path, full path and
is_directory) which IMO should be required, and should be accessible with
very straightforward syntax. Otherwise people will make mistakes, write
non-portable code, and it will get messy.

>Again, I don't see how it is going to be 'opaque'. There is going to be
>some type returned by operator*. I presume what you are saying is the
>useful thing a client can do is to send this into the property maps to
>And at the end of the story I'm fine with the full blown property
>It's not my preferred interface approach in general b/c I believe the
>design is more obscure and outside convention for new users. But I
>understand the motivations, and no matter, b/c this can easily be
>However to be consistent it clearly says to me that operator* should not
>return std::string, but must return dir_entry. It's just that dir_entry
>provides no public methods....

I assume you mean no public methods beyond those required for use in
standard containers.

But that sounds awfully dogmatic. What possible harm comes from making a
small number of functions public?

This seems like the wrong library to use as a vehicle to try to convince
people to use only the new property map idiom. Why not use the old member
function idiom for the common uses (names, is_directory), and leave the new
idiom for the optional attributes?


Boost list run by bdawes at, gregod at, cpdaniel at, john at