Boost logo

Boost :

Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: Stjepan Rajko (stjepan.rajko_at_[hidden])
Date: 2008-12-01 19:55:49

On Mon, Dec 1, 2008 at 5:30 AM, Jeff Garland
<jeff_at_[hidden]> wrote:
> The review of the Robert Kawulak's Constrained Value library begins today
> December 1, 2008, and will end on December 10th -- I will be the review
> manager. Please post reviews to the developer list.

Hi Robert,

This seems like a very useful library, and after a cursory look of the
documentation I feel that it has nicely well-rounded functionality.

I have a couple of questions at this point (mostly extreme nit-picks
about things that confused me when trying to think about how all I
could use this library).

In the basic definitions you have:
"Constrained object is a wrapper for another object. It can be used
just like the underlying object, with one exception: it can be
assigned only a value which conforms to a specified constraint." ...

"It can be used just like the underlying object":
I have a suspicion that it can't be used "just like" the underlying
object in all circumstances :-) I assume you can't call member
functions of the underlying object if it's a class type (with the same
syntax), or provide a constrained<int> as an argument to a function
that takes an int &. Could you provide a slightly more precise
explanation? The examples I looked at all use the constrained object
in operator expressions. Is it that it can be used just like the
underlying object in (most) operator expressions? In your wrapping
iterator example you have:
... so I assume you can't do *(iter++). (if so, why not?)

"it can be assigned only a value which conforms to a specified constraint":
when you say assigned, I'm thinking of the assignment operator, but
you constrain more than that. Perhaps there is a more inclusive way of
saying this? (maybe "it can only hold values which conform to a
specified constraint"?)

In your example "Object remembering its past extreme values", the
policy is changing the constraint object directly. But, in your
tutorial, you have:
"Constraint of a constrained object cannot be accessed directly for
modification, because the underlying value could become invalid
according to the modified constraint. Therefore the constraint of a
constrained object is immutable and change_constraint() function has
to be used in order to modify the constraint. ..."
Is the example violating how the library should be used?

The value() function returns the underlying object by const &... so,
I'm assuming that the constraint is not allowed to depend on any
mutable parts of the underlying object's state?



Boost list run by bdawes at, gregod at, cpdaniel at, john at