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-06 07:51:53

Robert Kawulak wrote:
>
> As Gordon Woodhull has suggested, it'd be nice to try finding
> a better name for bounded_int:
>
> > The unique characteristic of this class is not that it's
> > bounded or an int, but that the bounds are specified at
> > compile time.

A reasonable complaint, especially as there may be a runtime bounded integral type.  "bounded_int" could apply to either, so probably should be applied to neither.

> And from private correspondence:
>
> > As Thorsten mentioned, it might be helpful to
> > brainstorm/vote on the list for a better name for
> > bounded_int.  My favorite at this point is static_bounded,
> > since the use of a class static variable for bounds is
> > probably rare.  But you could probably do better.

"static" in this case is akin to that in BOOST_STATIC_ASSERT, which means compile time.  My preference is to use "CT" for that (because its an abbreviation for "compile time"), though it is very terse and could mean other things in other contexts.

> The template in a simplified form looks like this:
>
> template<typename ValueType, ValueType LowerBound, ValueType UpperBound>
> struct bounded_int
> { ... }
>
> Its characteristics are that the underlying value type is the
> same as the bounds type and the bounds are specified as
> compile time constants. According to the C++ Standard, type of
> the constants may be:
> - integral/enumeration,
> - pointer/reference to object/function,
> - pointer to member.
> Of the types, the most likely use case is integral, whence
> the name bounded_int (as a shortcut for "bounded integral",
> not necessarily "bounded integer"). This name does not express
> all the possible use cases, but it's hard to find a terse form
> of bounded_by_compile_time_constants. Somehow I don't like
> static_bounded because it may suggest that the underlying
> value or the bounds are static objects (in the meaning
> "global"); fixed_bounded or compile_time_bounded sounds no
> better to me.

"compile_time_bounded_int" is long, but clearly describes the class template.  (I didn't use "integral" because that has at least one other plausible meaning and cannot be disambiguated without context.)  You could also shorten or substitute words.  For example, instead of "compile_time," use "ct," "constant," or "const," and instead of "bounded," use "bound," "bounds," or "constrained."  Thus, I can offer these names:

   compile_time_bounded_int
   compile_time_bound_int
   compile_time_constrained_int
   ct_bounded_int
   ct_bound_int
   ct_constrained_int
   constant_bounded_int
   constant_bounds_int
   constant_bound_int
   constant_constrained_int
   const_bounded_int
   const_bounds_int
   const_bound_int
   const_constrained_int

The "const_" prefix is suggestive of "const_iterator" and the like, so may not be a good idea, but I think the "constant_" prefix is sufficiently different to work.  "const" or "constant" followed by "constrained" is a bit hard to pronounce.

>From among these, my vote would be for "ct_bound_int" or "constant_bounds_int" and being short and clear.

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