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. I suppose the fixed-size arrays could have been implemented as static only but the compact notation, particularly with the underscored array, the naming of which I'm not too keen on, would be lost for large arrays. The assumption was that in most cases there wouldn't be a problem so the null::allocator was set as the default. The memory allocations occur when the function object array_constructor, at line 113 in the header <array.hpp>, calls array_allocate at line 123 on a type with more than one pointer symbol appended. The function object calls itself recursively with the final allocation, or the only one for a one dimensional array, being called at line 139 of the array_constructor that begins on line 130. array_allocate can be found at line 23 of the same file. The last line in the primary template part of array_constructor resets the previously allocated memory to point to the addresses appropriate for the requested dimensions. A similar scheme is present for the resizeable arrays with the function object named pointer_constructor beginning at line 115 in the header <pointer.hpp>. Regards Brian On 6/24/11, Larry Evans <cppljevans@suddenlink.net> wrote:
On 06/23/11 15:57, Brian Smith wrote: [snip]
The design of the arrays closely follows that provided by the language. For fixed-size static arrays the data member is an intrinsic array whose type is determined from the template arguments passed,
which type, AFAICT, is calculated by boost::maps::detail::array_type in boost/maps/support/generic.hpp (around line 84).
the obvious difference for non-static arrays is the data member's type, which for an N-dimensional array is the requested element type with N pointer symbols appended.
which type, AFAICT, is calculate by boost::maps::pointer_type, again in generic.hpp (around line 66).
However, even after reading the docs at:
libs/maps/doc/html/maps/concepts.html#maps.concepts.fixed_size_arrays
I'm still unable to infer any advantage to using anything other than the default allocator and thereby avoid this:
runtime construction requires five memory allocations
which occurs with any non-default allocator.
Brian, could you explain the advantage of using an allocator other than null::allocator?
BTW, could you point out where the "five memory allocations" occur? I've looked at the code some without success so far, but it would be nice if you could just point it out since you know exactly where it is.
TIA.
[snip]
-regards, Larry
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- www.maidsafe.net