[boost] Re: Re: [Filesystem] Exact type of name checking function?

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-08-18 18:08:26

Beman Dawes wrote:
> At 02:08 PM 8/18/2003, Edward Diener wrote:
>
>  >... one of the reasons, as I understand it, for
>  >boost::function and boost::bind is so the end-user has the benefit
>  of >defining his callback as he sees fit and not have it more rigidly
> dictated
>  >by the implementation. That is the main reason I support such a
>  callback >for boost::filesystem checking for pathname validity; it
> gives the
> end-user
>  >maximum flexibility while letting the internals of
>  boost::filesystem deal >with the result of the callback as it sees
> fit. Inevitably, somewhere
> down
>  >the road, programmers will say that the callback system is too
>  rigid for >their needs, no matter how simple is seems as if it
>  should be now. With >boost::function such a complaint is very close
>  to impossible. I am not >trying to create more work for the
>  implementor, only suggesting that the >most flexible callback
> implementation done now will save possibly more
> work
>  >in the future and be beneficial to end-users.
>
> Edward,
>
> If we loaded Boost.Filesystem up with every feature which would be
> beneficial to some user at some future time, it would be full of
> caches, allocators, path translators, vast numbers of compound
> operations, file system virtualizers, generation dataset emulators,
> partitioned dataset emulators, and a lot of other stuff. Some, like
> wide-character path names, I'd dearly love to add. Everything on that
> list is useful, sometimes very useful.

You are confusing the use of choosing a callback method with adding a new
feature. If you are already determined to add a callback method, as a new
feature, to allow the end user to specify what is a valid filepath name, why
not use the callback method which is already a part of the Boost libraries ?
Of course you can choose a simpler, less flexible callback method if you
like. But I truly don't see how that can be better from a design point of
view than allowing the user to pass in a boost::function as his callback.

I am not advocating using boost::function because its there. I'm advocating
using it because it cleanly solves what you want to do: allow the user to
pass a callback method to you to determine the valid filepath name.

Nor do I understand the overhead involved. However you design
boost::filesystem to use your callback, the callback "pointer", if you will,
will get passed into some functionality, you will store it away somewhere,
and later when your functionality has to determine whether or not a filepath
name is valid, you grab the pointer from wherever you have stored it and
call the callback function for an answer. What is the difference whether the
pointer is some variation of C++ function pointers or is a boost::function,
which can encompass them all ? To your internal design it should be the
same. But to the end user boost::function gives him the maximum flexibility
of binding in whatever he likes. So where is the downside to using it over
some more constrained method ? Surely secreting away a boost::function is
just as easy as doing so for any specific type of callback pointer. And
calling a callback function through boost::function is likewise.

The only thing I can think of is that you don't want boost::filesystem to
rely on this other implementation at all. Fine, if it isn't as portable as
boost::filesystem is and using it will reduce your portability, I can
understand that. But boost::function will almost certainly be in the next
C++ standard, and C++ compilers are catching up to standard C++. So I expect
that compilers in the near future will do so too. I used boost::function and
boost::bind to provide event handling in my own library for VC6, one of the
least compliant libraries around. So it is really hard to believe that any
compiler that can't use boost::function and boost::bind, with all the
excellent workarounds that the implementors of those created to get around
compiler weaknesses, is worthy of being targeted by boost::filesystem.