Re: [Boost-users] [boost] [review][constrained_value] Review ofConstrainedValueLibrary begins today

Subject: Re: [Boost-users] [boost] [review][constrained_value] Review ofConstrainedValueLibrary begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-08 19:24:42

Hi Jesse,

	> From: jesseperla

	> The only other things that I would say need to be thought through in
the design is unions of constraints instead of just intersections of them. For
example, I was checking this out a while back, and it manages the sets of
intervals/etc. well: http://www.herold-faulhaber.de/itl/

Well, maybe in the future. This should be relatively easy to add as extension to
the library, but may require some time to define the requirements and interface
well.

	> Why not just use numeric_limits<risk_aversion::value_type>?
        1) Because I was too stupid to think of that, and 
        2) Because I want to be able to write generic functions such as:
        template<typename T>
        bool is_NaN(T& t)
        {
        return (t == std::numeric_limits< T >::quiet_NaN());
        }

Then you may specialise those functions for constrained -- I think it's a better
solution than providing numeric_limits for constrained in the library.

	>Actually, only the mutating operators (++, --, =, += etc.) are
overloaded. For
	>I don't think this is needed. If you write:
	> constrained<int> x, y, z;
	> z = x + y;
	>Then simply the + operator for int is used.
        Even better. As long as it works for all of the auto conversions between
intrinsic types we are also in business. e.g. 
        constrained<int> x, y, z;
        double c;
        z = c * x + y;

Yup, should work.

Best regards,
Robert