Boost logo

Boost :

Subject: Re: [boost] Interest in multi-dimensional array class templates.
From: Brian Smith (bjs3141_at_[hidden])
Date: 2011-06-25 17:08:15


On 6/25/11, Larry Evans <cppljevans_at_[hidden]> wrote:
> On 06/24/11 20:29, Brian Smith wrote:
>> If you're program uses a relatively large number of static arrays all
>> in scope at the same time or if a few relatively large static arrays
>> are in scope the stack checker crashes the program when its run, the
>> heap allocated arrays can be present in greater numbers or used when
>> relatively large arrays are required.
>
> If stack space is limited, then why not just allocate the static
> array on the heap with something like:
>
> typedef
> int
> elem_t
> ;
> typedef
> bounds3<2,3,4>
> bounds_t
> ;
> typedef
> array
> < elem_t
> , bounds_t
> , true
> , null::allocator
> >::type
> array_static_t
> ;
> array_static_t*
> p_static=new array_static_t;
>
> ? You would then have only 1 call to any allocator
> instead of 3 and save space on the heap besides.
>
You're correct. Now for the excuses part. The problem materialised
early in the development when I was working on a pretty old computer
and to be honest I never thought of setting up the problem the way
you've suggested. The computer I have now, although still not too
great, could handle the problem without resorting to the above.
Initially the static and dynamic arrays were separate and it was not
too far in the distant past that I combined them using the base
classes. All things considered that might have been a mistake,
although the main reason for doing so was, and still is, the fact that
the memory allocations are not the determining factor where
performance is concerned, albeit it has an effect. And besides it
gives you more options.

Thank's Larry.

Regards
Brian
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
www.maidsafe.net

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk