From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-04-11 07:38:37
At 02:13 PM 4/9/2002, Stewart, Robert wrote:
>From: Beman Dawes [mailto:bdawes_at_[hidden]]
>> Notice the find_file function:
>> // find_file ------------------------------------------//
>> // given a directory to recursively search
>> bool find_file( const string & dir_path, const string & name,
>> string & path_found, const string & ignore_dir_named="" )
>In my experience, output parameters such as path_found, are better put
>in the argument list, so they are grouped -- should there be more than
>-- and so they are always in an expected position. I tried putting them
>last, but that interfered with default arguments. Putting them first
>associates them with the return value of the function (in a manner of
I also used to put the output parameters first, but then the STL got me
doing it the other way around. I think on balance I like output first, for
the reasons you mention.
>(I'm mentioning this so that you consider it for find_file() but also any
>other functions you may write for the library.)
I really tried to write the example program as if it was just another
script I needed, and thus did not agonize of style.
For example, should some of the other functions return a bool, rather than
a string which gets set to "" on failure? I didn't worry about it. The
point being to get a feel for usage in a real program, not a demonstration
So, to get back to your point, we should definitely look at that sort of
issue if we decide to add such a function to Boost.
>Looking at this code, I find myself a bit confused by the terminology you
>have selected. I was troubled when I read your list (on the filesystem
>design page you posted), but didn't quite know what was wrong.
I'm not entirely happy with terminology either.
I spent some time reading the POSIX definitions at
I really don't see them as any less confusing, although it might be better
to just go with a standardized terminology. So for now, exact terminology
remains an open issue.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk