I have not looked at the ConstrainedValue library enough to review it, but from the discussion here the "multi-constraint predicates" are a somewhat different thing. Specifically, the disabling of run-time checking, the ability to query and change constraints at run-time, and the performance issues for numerics. Rather than delay a library that appears useful and promising, and diffuse the testing effort, it might be better to add multi-constraint predicates later, after the appropriate requirements and design efforts. John -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Kawulak Sent: Tuesday, December 09, 2008 6:38 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [boost] [review][constrained_value]ReviewofConstrainedValueLibrary begins today
From: Gordon Woodhull
I think the best solution for dynamic constraints union (or intersection) is to use boost::signal, and this is how I would implement this. Again, this is a possible addition to the library in the future if it proves generally needed.
Ditto. Nothing needs to be added to the library, but a bunch of stuff needs to get tested.
The point is that if such multi-constraint predicates prove needed in many use cases, it'd be nice to add them to the library so users don't have to define them on their own. Regards, Robert _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users