>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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
