Re: [boost] array.hpp

From: Ralf W. Grosse-Kunstleve (rwgk_at_[hidden])
Date: 2002-05-08 13:03:23

I think the "ref" and "const_ref" types in the array_family
that I wrote a couple of months ago are exactly what you need:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/include/cctbx/array_family/

This is a fairly trivial piece of code that you could simply
adopt to your environment. If you do not need the "accessors"
for multi-dimensional arrays you can easily simplify the code
further.

Ralf

P.S.: Sorry, there is no documentation for the rest of the
array family except for an out-dated design document
(http://cctbx.sourceforge.net/cvsdoc/page_array_family.html ;
the "Urgent" items are done.)

--- "Victor A. Wagner, Jr." <vawjr_at_[hidden]> wrote:
> We're writing a library to handle some large collections of data and have 
> been very heavily using std::vector in anticipation of perhaps needing to 
> hand this data off to a C or FORTRAN 'system' for further 
> processing.  Thusfar, there aren't any problems.  We just got the news that 
> our "library" will need to be callable from C, FORTRAN, or even MATLAB 
> programs.  The problem that crops up immediately is that there is no STL 
> container which will handle an array _which already exists_.
> 
> boost/array would more than suit our needs if only there were some way 
> (other than wholesale copying of the .hpp file and making a couple _very_ 
> small changes) to convince the array<class T, std::size_t N> that rather 
> than doing the:
> 
> T elem[N];
> 
> declaration in the class (and thereby allocating the array) we could 
> somehow(????) do
> 
> T* elem;  //I tried to figure out how to write a "reference to an array of 
> N elements of type T" and failed
> 
> and figure out how to get the address of this already extant array put into 
> the pointer elem.  None of the rest of the class would need to change, 
> since the syntax elem[x] works "identically" in both instances.
> 
> I know that the "normal" way of doing this would be to copy the array into 
> a vector then do all the magic C++/STL stuff.  This is impractical for two 
> reasons:
> 1) The array is often used as an in/out parameter, and this would entail 
> copying it twice (a rather large performance hit)
> 2) some of the arrays exceed 1/2 of the virtual space available so there 
> isn't any place to copy them to!
> 
> If anyone else is facing this problem we'd be glad to assist coming up with 
> a boostified solution.  I just hate to "cheap out" and edit array.hpp into 
> foreignarray.hpp just to solve this problem (especially after reading 
> Andrei's book and seeing all the "policy" template type discussions here).

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com