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-15 23:06:11

Robert Kawulak wrote:
> > From: Stewart, Robert
> > 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.
>
> I don't get it - what "compile time unfixed" would be?

The initial values are given with compile time constants, but they can be changed at runtime.

> > 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.
>
> Well, to be honest I don't see the taxonomy making things
> simpler, quite the contrary - it implies several
> implementations instead of just the one. Yet it only imposes
> unnecessary constraints restricting possible use cases, e.g.
> with the current "bounded" class template you may easily create
> objects with one bound that is fixed at compile time and the
> other being mutable (for instance number of days in a month).

I hadn't considered that each bound could be given with a compile time constant or not, and each could be fixed or unfixed.

> I understand that the simplified model of separate classes
> for fixed/unfixed bounds might look more as expected by a
> newcomer, but rather than multiplying entities I'd explain
> the existing model better in the tutorial if it's not
> explained well enough (is it not?)

Given that each bound can be found in the four quadrants independent of the other, your bounded_int class template is restrictive.  Don't you need an easier way to supply and configure the bounds so each can be placed into any of the four quadrants independently?

Ruminating...

bounded simply arranges for the bounds to be of the value type so they can be altered at runtime, right?  bounded_int requires compile time constants for both ranges and cannot be changed at runtime.  The key characteristic of the latter, to me, is that the bounds are fixed at compile time; they cannot be changed at runtime.  However, I get that bounded can also be configured with types that generate an initial value at runtime that cannot be changed thereafter (so they are, effectively of type T const rather than T.  Therefore, runtime mutability is not the entire picture for bounded_int.

The _c suffix, borrowed from MPL, is good for specifying that the bounds are compile time constants.  Adding that to "bounded" seems wrong because the bounded's value can still change, within the confines of the bounds.  (The same is true of "static" and "ct" as suffixes or prefixes.)

In your example with quarter2type, you show:

   bounded<rational, quarter2type, half2type>

Perhaps the best thing for what you're calling bounded_int is this;

   bounded<int, bound_c<0>, bound_c<10> >

It isn't as succinct as this:

   bounded_int<int, 0, 10>

but it does eliminate the troubling naming problem and, I think, reduces confusion.  Consider:

   bounded<int, bound_c<0>, big_prime>

There we combine both ideas without having to introduce anything new.

_____
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.