Niels Dekker wrote:
No need to change the original implementation of array::c_array()! Your
change of its return type should be sufficient: T (&c_array())[N] { return elems; }
You are completely right !
Andrey Semashev wrote:
Why not simply accessing elems directly? It's public.
It looks like it's indeed okay to access boost::array::elems directly. But tr1::array::elems is marked as "Exposition only". Other TR1 implementations have indeed named their tr1::array data member differently.
Unfortunately c_array() is also specific to Boost. So I've proposed to add this member function to std::array as well (LWG issue #930), returning a reference to the array. (Including overloads for const and rvalue arrays.)
I argue that c_array() function does not do what we could implicitly expect from it regarding its name. A C array type encapsulates a pair of information: its size and its elements type. I guess it's a shame to break this pair as we usually do. BTW, a reference on array is implicitly convertible into a pointer on its 1st element. So the change would be really minor. This following lines of code would still work: { array<int,10> toto; int* item_ptr = toto.c_array(); } As far as I can see, the only improvement which would be brought by the change is that sizeof( toto.c_array() ) would return value 10*sizeof(int), the real size of the C array. About the array_cast() I will open an other thread. I'm working also on an array_ref<T,N> class template which exports quite the same interface as a boost::array and wraps a reference on C array. The main purpose is to allow an existing C array to be used as a STL sequence container. If I can convince about the benefit of these 2 new features, I guess it would be nice to add them into the existing boost array package as in my point of view the boost::array class, array_ref class and array_cast function create a consistent unit. best regards, herve