Re: [boost] [constrained_value] Constrained Value review results

Subject: Re: [boost] [constrained_value] Constrained Value review results
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-10-11 08:15:47

Robert Kawulak wrote:
> > From: Stewart, Robert
>
> > Let me clarify something that has just occurred to me.  I've been
> > writing strictly in the abstract about a compile time bounded
> > type and a runtime bounded type and about names for them.  I've
> > not been making any specific references to your types as they now
> > exist.
>
> OK, sounds reasonable. The thing is that the "bounded" class
> template is universal and equally suitable for dynamic and static
> bounds. The only reason for existence of "bounded_int" is to
> save some typing when defining bounded types that have bounds
> expressible as compile time constant expressions. So instead of:
>
> bounded< int, boost::mpl::integral_c<int, 0>, boost::mpl::integral_c<int, 10> >
>
> you can just say:
>
> bounded_int<int, 0, 10>

That is certainly worthwhile.

> So yes - the "rt_bounded"/"ct_bounded" abstraction doesn't
> map to "bounded"/"bounded_int" and what I'm asking for is NOT
> a name for bounded class with bounds that don't change, but a
> better name for "bounded_int".

To create good names does require good understanding which I clearly didn't have and I'm still fuzzy on a couple of points, I think.

> > > There are even cases when "bounded_int" cannot be used to
> > > define static bounds and you have to use "bounded" instead
> > > these are all the cases where the bounds cannot be expressed
> > > directly using compile time constant expressions, e.g. for
> > > floats or rational numbers. See the example with rational
> > > numbers in the second part of this subsection:
> > >
> <http://tinyurl.com/332vmf5#constrained_value.tutorial.compile_time_fixed_bounds>
> >
> > In which case the type cannot be compile time bound and a runtime
> > bound type must be used.  I see no problem here.
>
> Strictly speaking it's not a runtime bound. You cannot change
> the value of quarter2type object. It has no storage and only
> expresses some fixed value by its type, just like
> boost::mpl::integral_c does. Here's the difference (using
> types from the example above):
>
> bounded<rational>::type rt_rational;
> change_upper_bound(rt_rational, rational(1, 3)); // OK - can change bounds at runtime
>
> bounded<rational, quarter2type, half2type>::type ct_rational;
> change_upper_bound(ct_rational, rational(1, 3)); // COMPILATION ERROR!

OK, so if I have things right, there's the notion of fixed bounds
that, once set, cannot be changed thereafter.  How they get set
is part of the issue.  In one case, the bounds are compile time
constants, which you've captured, currently, with bounded_int.
In the quarter2type/half2type case, the bounds are specified at
compile time, but actually determined at runtime because they are
not compile time constants.  That's like creating a const object:
once initialized, its value cannot be changed, but the value from
which it is initialized can be computed at run time.

There's also the case of unfixed bounds that can be changed at
runtime, regardless of whether the bounds -- initial or later --
are determined at compile time.

Clearly, computing bounds at compile time versus runtime can be
considered another dimension added to that of whether the bounds
are fixed, so there are four combinations possible: compile time
fixed, runtime fixed, compile time unfixed, and runtime unfixed.
(The use of "fixed" is unfortunate, because it evokes fixed point
numbers, of course.)

When the value of the bounds is computed seems relatively
unimportant versus whether they can be changed at runtime.  Thus,
I think there should be two class templates that capture that
notion.  Each of them might reasonably have a helper that makes
specification of compile time constant bounds easier, like your
current bounded_int does.

If that taxonomy makes sense, then we must consider names, but
I'll not go that far unless you agree with this view of the
types.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.