Re: [boost] Possible class submission: Sparse Array

From: Spencer Collyer (spencer_at_[hidden])
Date: 2006-04-27 04:03:37

On Wed, 26 Apr 2006 22:21:44 +0200, Robert Kawulak wrote:
> Hi, 
> 
> > From: Spencer Collyer
> 
> > bounds:
> > This determines what the bounds on the sparse_array are, and 
> > how values
> > that exceed them are handled. For example, the 'unbounded' 
> > policy allows
> > virtually any positive value of the subscript type to be 
> > used, 'bounded'
> > only allows values within the (compile-time specified) max
> value and
> > throws if a subscript exceeding this is given, while 
> > 'clamped' makes such
> > value equal to the max value.
> 
> I'm working (actually, I'm having a long pause with the work :P)
> on a Boost library that will actually implement this piece of
> functionality, i.e. constrained types. In short, it aims to
> provide a set of flexible, policy-based template classes allowing
> to create constrained types, like bounded types with compile-type
> bounds, run-time specified bounds etc. The code is almost ready,
> but the documentation and tests need work.
> 
> If you'd be interested in reusing my library in your project,
> just let me know. Unfortunately I can't tell when the library
> would be 100% ready, although I try to finish it as soon as
> possible.
> 
> Below is an excerpt from the motivation section of the
> documentation.

Robert,

Yep, I've seen some of the discussions on your Constrained Types library - probably the only thing I miss from my days being forced to program in Pascal many years ago :-) I'd love to see this library make it into Boost.

The way my sparse_array class is designed there should in principle be nothing to stop a user using one of your constrained types as a subscript. However, I do have one concern - the way the iterators are handled, I need to be able to specify a value that is one-past the maximum allowed subscript (which is why the 'unbounded' policy doesn't allow to use _all_ positive values - it has to reserve the maximum value for its end() iterator).

If I read your suggestion right, you are thinking that we could replace the bounds policy with one of your constrained types? Because of the need to reserve the one-past-the-end value for the end() iterator, I'm not sure that would be feasible. We need to be able to store the one-past-the-end value but not allow the user to specify it as a valid subscript.

Does that make sense?

I'm beginning to think I need to get something posted on the web so people have something concrete to look at...

Spencer

-- 
<<< Eagles may soar, but weasels don't get sucked into jet engines >>>
8:53am up 39 days 20:26, 21 users, load average: 0.15, 0.04, 0.02
Registered Linux User #232457 | LFS ID 11703