[boost] Re: Boost Array: read/write access to entire data

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2002-10-30 07:41:59

On Wed, 30 Oct 2002 12:28:09 +0200 (Jerusalem Standard Time), Yitzhak
Sapir <yitzhaks_at_[hidden]> wrote:

>Would it be possible to request that Boost Array provide read/write access
>to the internal array data?  I've been using array.elems for this at
>first, but apparently, elems is public only to provide {...}
>initialization lists.  (I consider such initialization lists important
>since a global array object will now behave like a global array in all
>that concerns order of initialization of objects in the system).  However,
>I'd also like to be able to have read/write access.  For example, if I use
>a Win32 API ::ReadFile to read from a pipe that I created, I would like to
>provide the array as the buffer.  Many other API functions take a buffer
>and length type arguments, and even portable object-oriented systems have
>such functions such as the ACE Communication Framework.  In those cases I'd
>like to use a boost::array<> to encapsulate an array (even if just so I
>can write: peer().recv(buffer, buffer.static_size, 0) in ACE), but without
>read/write access to the internal array, I cannot, and I feel
>uncomfortable accessing an undocument class member that is public only
>because of a design constraint.

Hmmm... I suppose the intent is that array<T, N>::iterator is always a
T*. It is typedef'd to make generic code work but the fact that it
corresponds always to a pointer (I think) is not, in this specific
case, an implementation detail. But you would better ask to Nicolai.
Note that he says in the docs:

   "I don't have time to read all boost mails. Thus, to make sure
    that feedback arrives me, please send me a copy of each mail
    regarding this class."

BTW, is there any interest in a *resizable* array template? I'd like
such a structure for the internals of dynamic_bitset. Compared to
vector<>, it would provide a specialized implementation for types
whose copy constructor cannot throw and, above all, the possibility of
"uninitialized construction and resizing", something that is IMHO very
useful when dealing with C APIs. The first feature can be obtained for
vector<> too, the second one can't (by design). I have not thought to
this with the care it deserves but this is the basic idea. Feedback,
suggestions and insults are welcome :-)

Genny.