David Abrahams wrote: > "Peter Dimov" <[EMAIL PROTECTED]> 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost