
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@sig.com 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.