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-07 07:41:30

Robert Kawulak wrote:
> From: Stewart, Robert
>
> Maybe even "c" alone would suffice?
>
> bounded_c<int, 0, 10>
>
> Reminds me of boost::mpl::integral_c.

That's exactly why I dislike it.  In MPL, it refers to a compile time constant.  The bounds, in this case, are compile time constants, but the value represented by bounded_c isn't.

> > instead of "bounded," use "bound," "bounds,"
>
> Using "bound" or "bounds" seems misleading to me. The object
> represented by the type is a bounded value, not value of the bounds.

I was using "bound" as a verb in those cases: "ct_bound" means bound at compile time.  According to reference.com, "bound" as a noun is usually in the plural, so I didn't confuse "bound" as a noun in my suggestions, though I can see how others might.

I suggested bounds because it was in the context of a name like "ct_bounds_int" in which the bounds applied to the integral type were fixed at compile time.  Since "int" is not be in the name, we can use "value" instead: ct_bounds_value.  In that case, though, "bound" fits better, but seems to suggest that the value is fixed at compile time (as in MPL's "_c" suffix): ct_bound_value.

> > or "constrained."
>
> Constrained objects are a superset of bounded objects while
> we're looking for a name for a subset of bounded objects so using
> "constrained" does not make sense.

OK.  I was just looking back at the library name and realized "constrained" wasn't among the suggestions offered or rejected in your post, so I didn't want to miss that option.

> > >From among these, my vote would be for "ct_bound_int" or
> > "constant_bounds_int" and being short and clear.
>
> The "int" suffix is unnecessary, the whole point was to
> replace it with something better. ;-)

I didn't understand that "int" wasn't supposed to be part of the name from your initial post.

> > From: Paul A. Bristow
> > I also like the word 'static' - it implies 'fixed at
> > compile time' to me,
> > but I agree static has other possible implications.
>
> How about "statically_bounded"?

That's longer, but it does work.  If we can agree on "ct," it would be better because shorter.

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