From: "Robert Kawulak" <kawulak@student.agh.edu.pl>
From: Simon Buchan
[sig?]
What's this?
My guess is he's calling your attention to the lost attribution.
In bounded policies I use passed_value_type initialize() where passed_value_type is value_type for integral types and const value_type & for other types. The second returns a reference to a static object - that's the most efficient method I can think of, initialization takes only one copy-construction (for details please look into the code).
ref to static? It feels cludgy.
It's not a static created only for initialisations. Bounds specifier's functions min_value() and max_value() create function-scope static objects and return them, this way the objects aren't being created every time the functions are called (and they're called very often, so I think this is reasonable for non-integral types). And initialize() only returns min_value() and that's it.
Once you go with a function local static, you have to worry about thread safety. In the simpler range bounded approach, the type includes the boundaries, so there's no need for statics. It would only be the more complicated bounding policies that might have need for this behavior. Thus, don't force the creation of statics in your design. Ensure that if they are used, it is the choice of the policy writer.
Uhh, maybe you're right ;-) I don't know why, but it just "byte my eyes" when I see a type named "something_value"... Nevermind, if people here really resist that it should be called constrained_value instead of constrained_type, then OK - I'll change it.
Why not just 'constrained'? ie. constrained<int>?
Sounds good, and how to call the library? 'constrained_types'?
The library name should probably be "Constrained," the namespace, "constraineds," and the type, "constrained," if you go this route. (That's in keeping with Boost.Tuple, which uses the "tuples" namespace and the "tuple" type.) If you call it the "Constrained Types" library, and use the namespace "constrained_types," does "constrained" for the type name fit with Boost prior art and intention? Those names sound a lot better, so that may be sufficient justification, but I don't want to presume this approach is acceptable to Boost as a whole. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;