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

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

David Abrahams wrote:
> "Peter Dimov" <pdimov_at_[hidden]> writes:
>
>> David Abrahams wrote:
>>>
>>> FWIW, Boost.Function is overkill for many simple cases.  This might
>>> be a case where the FS library should just provide a class with a
>>> virtual function:
>>>
>>>         struct checker
>>>         {
>>>              virtual ~checker() {}
>>>              virtual bool operator()( std string const& ) = 0;
>>>
>>>              shared_ptr<checker> next; // suggested.
>>>         };
>>
>> Boost.Function makes things simpler for the user.
>>
>> enum check_type { check_posix, check_windows, ... };
>> bool my_name_checker(std::string const & s, check_type t);
>>
>> Compare
>>
>> bind(my_name_checker, _1, check_posix)
>>
>> against
>
>   <snip>
>
> So I left out a few bits <snip>

That's all very nice but 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.

I am a bit surprised that Boosters themselves do not seem to want to support
one of their own key libraries. Maybe because I am used to the C++ extension
callback and event systems invented by Microsoft and Borland for their
frameworks, anything less or more restricted seems primitive to me. That is
why I am quite happy with the excellent work done on boost::function,
boost::bind, and boost::signals by their implementors.

The latter reminds me to ask, although off-subject for this thread, why
boost::signals wasn't submitted for TR1. The C++ standard library sorely
needs an event model and boost::signals is a good one with kudos to Mr.
Gregor.