[boost] Re: boost::array

From: Robert Ramey (ramey_at_[hidden])
Date: 2003-08-11 11:18:49

>Ramey wrote:

>> Actually this suits my current need.  It compiles in my environment.
>> Does this mean its universally OK?.  I thought I had seen something
>> like this before but couldn't find it in any of my references so I had been
>> trying something variations on:

>If you look at the regression tests you will find a couple of failures.
>On windows Borland and MSVC6/7.0 cannot be initialised for anything but
>the basic types (int, double, const char *, etc)  The two tests that
>fail are based on array< std::string >.  If array< const char *> is
>substituted they initialise correctly and pass the tests.

>So yes, this is correct for conforming compilers, and so long as you are
>not using user defined types will work even on the current compilers
>that are broken.

Hmmm - are there any references or language in the standard that
supports this?

>> Presumably boost::array was motivated by the desire to make
>> an array look like a container - which is what I wanted.  I found
>> it unsatisfactory because of the copying.  Would it not be interesting
>> to make an equivalent that would take either an array reference
>> or a pointer and give it a ful container like interface so that one could
>> do something like:
>> 
>> const int array[] = {1, 2, 3, 4};
>> boost::container_facade<int> cfa(array);

>> std::copy(cfa.begin(), cfa.end(), ...);

>Ok, here's the awkward question.  How do we determine cfa.end()?
>boost::array works with fixed size arrays, so always knows the size of
the array.
>If you want a variable sized array, then the standard library already
>provides this with std::vector.  So I assume you want either

OK, lets assume the above example were modified to something like

const int array[] = {1, 2, 3, 4};
boost::container_facade<int> cfa(array, sizeof(array)/sizeof(int));

or perhaps

const int array[] = {1, 2, 3, 4};
boost::container_facade<int, sizeof(array)/sizeof(int);> cfa(array);

or ???

its even concievable that the size could be determined at template
instantiation time using mpl magic.  In anycase, I don't see 
geting the size of the array at an early enough time to be
any serious obstacle.

>a/ a fixed-size array, of size unknown at compile time.
> or
>b/ an array fixed at compile time, owned outside the container, but
>supplying a container-like wrapper?

>(a) is certainly possible, and something I have considered implementing
>several times myself.  However, given std::vector covers so much of the
>need I find it hard to justify writing an extra class.  AFAICT, the main
>difference is the lack of push_back, pop_back, insert and erase.

std::vector is a run-time construct while array is essentially a compile
time construct.  I see them as complementary rather than competing
methods.  

The issue above is exacly the same in regards to boost::array.
I presume this issue was resolved in favor of adding boost::array to
boost.  The only real issue is there place for a version of boost::array
that doesn't require copying.

>(b) I am not sold on, as all other containers I am familiar with own
>their contents.  I feel this change of idiom might confuse otherwise
>clear code.

We often use containers of pointers/ shared pointers etc.  I don't know
if that qualifies as containers that "own thier contents"

b is what I'm refering to.  To avoid confusion it might be given a different
name - e.g. container_facade or to emphasize identity of interface
and shared implementation it might be boost::array_ref.  This is not
a huge issue for me.  Though generally I prefer to leverage on
known names to save storage in my aging brain.

>Also note that one of the listed advantages of boost::array is that it
>does indeed copy-by-value.  This means you need to pass-by-reference to
>achieve 'traitional' array passing, but have a new facility available
>that some of us do find useful <g>

It really comes down to this.  I know I would find it useful. For me its not a great
problem now as it would be easy to build using boost::array as a basis.  The
real question is whether sufficient number of other people would find it 
sufficiently useful to justify enhancing boost::array (or making something else)
to support the container facade view point.

-- 
AlisdairM