Re: [boost] Possible class submission: Sparse Array

I don't know if I can post here, but here goes...
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Spencer Collyer Sent: Wednesday, April 26, 2006 11:20 AM To: boost@lists.boost.org Subject: [boost] Possible class submission: Sparse Array
I'd like to canvas opinions on whether it is worth submitting a class I've developed to Boost. 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.
Would there be a bounds type for specifying runtime bounds? It seems the upper bound if specified, can only be specified at compile time and this would limit the size of your arrays... Or is this by design? Thanks!

On Wed, 26 Apr 2006 12:33:06 -0700, Sohail Somani wrote:
Would there be a bounds type for specifying runtime bounds? It seems the upper bound if specified, can only be specified at compile time and this would limit the size of your arrays... Or is this by design?
Sohail, Because the bounds checking is specified using an inherited policy class, there is in principle no reason why run-time bounds cannot be used, and I did indeed look at doing this. The option I came up with was to have a set_limit function on the bounds policy which you would call to define the limits at run time. The only reason I haven't gone ahead and done the work to implement run-time limits as yet is because I'm still not sure about the answers to a few questions: 1) Should the user be forced to set the limit (or limits) on the bounds before any accesses to the array elements are allowed? I'm inclined to say 'yes' to this, as otherwise we have nothing to check element accesses against. This does mean that every element access needs to check if the bounds have been set (and probably throws an exception if not) before it can carry out its operation. 2) If the answer to (1) is 'no', what do we do if the user specifies a limit which is violated by any of the elements already on the array? I'm inclined to say the default limit-violated action for the policy should be carried out immediately, but it may be preferable to only check on the next access. 3) Should the user be allowed to change the limits more than once? There are two cases to deal with here: (a) no array accesses have yet taken place, so no elements exist that can violate the new limits; (b) one or more array accesses have taken place, so violating elements may exist, in which case we have the same question as in (2) again. My own thoughts are that the answer to (1) should be 'yes', in which case question (2) is irrelevant. As for (3), I think the user should only be allowed to set the limits once. Both these could be achieved using a bool to indicate whether the limits have been set or not. I've currently got eight bounds policies defined, six of which could conceivably have run-time specified equivalents. If people think this would be a good idea to add them it will be a relatively quick job to do so. Of course, as this is policy-based, there is nothing to stop the user implementing their own policy for these things if they find the ones I have supplied don't meet their needs. Spencer -- <<< Eagles may soar, but weasels don't get sucked into jet engines >>> 7:48am up 39 days 19:21, 21 users, load average: 0.43, 0.27, 0.28 Registered Linux User #232457 | LFS ID 11703
participants (2)
-
Sohail Somani
-
Spencer Collyer