Re: [boost] Bounded types (or maybe not 'bounded' anymore? ;-)

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-09-29 08:49:51

From: "Robert Kawulak" <kawulak_at_[hidden]>
> > 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_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;