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-08 07:01:48

Robert Kawulak wrote:
> 2010/10/7 Stewart, Robert <Robert.Stewart_at_[hidden]>:
> >> > 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.
>
> You mean "bound" as past participle of "to bind", so "ct_bound" would
> mean something that has been bound (i.e., "binded") at compile time? I
> think the operation we want to express is bounding rather than
> binding...

I see the bounds as being applied at compile time, so it is bound to the specified range at compile time, so, yes, I meant the past participle of the infinitive "to bind."  That the bounds continue to apply at runtime after having been bound at compile time is not, I think, the principle distinction.

> > My suggestion was to make "ct" a prefix akin to "static_"
> > in static_cast and static_assert.  I do like the parallel
> > with "rt," so I would prefer these:
> >
> >   ct_bounded<int>
> >   rt_bounded<short>
>
> The former is the subset of the latter, so "rt_bounded" is not a good
> idea since it may represent objects with compile-time-fixed bounds as
> well. I think just "bounded" is the best.

Strictly speaking, runtime bounded is not a superset of compile time bounded, because one cannot choose to do either with the runtime bounded class, right?  Both types apply range checking at run time, and both behave like the underlying type (insofar as possible).  The differences, then, are when the bounds are applied and whether they can be changed at runtime.  Considering that the former is a characteristic of the latter, the principal difference is whether the bounds can change at runtime.  Thus, "bounded" is insufficient for the runtime version as that name implies both categories and does not clearly suggest the runtime variability.

-1 "bounded"

> 2010/10/7 Krzysztof Czainski <1czajnik_at_[hidden]>:
> > I prefere sufexes, becaluse then the part of the name, that
> > brings most information comes first:
> >
> > bounded_ct<int> x; // bounded at compile time of type int
> > bounded<int> x; // bounded (at run time) of type int
>
> I agree with you for the same reason.

We are certainly accustomed to postfix notation for many things, so using "ct" and "rt" as suffixes won't be harmful, and the names will sort lexicographically together in many contexts with the suffix.  My preference still is for the prefixes, but I don't much mind the suffixes.

> Moreover, if you start typing "boun..." in an IDE, its
> autocomplete will show both the options, so it has a small
> productivity advantage too. ;-)

Not using such a facility, that bears no weight with me, but if you do, I can imagine it will carry some weight with you.  However, don't get carried away by that idea since few will be typing those names particularly often, at least in normal code.  The names of objects of those types will be used far more often.

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