On Mar 16, 4:09 pm, Joe Gottman <jgott...@carolina.rr.com> wrote:
> I think that if we do add initializer_lists to
> C++0x, we should take the opportunity to give std::array a fuller
> interface.
>
> Some useful constructors and assignment-operators for array<T, N>
> include the following:
>
> array(); //Default constructor to ensure the entire array is initialized.

With the current state of POD definition this cannot be done.
E.g. even with the currently proposed *extended* definition of
POD's, see

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2172.html

array must have a default c'tor which has no effect. This will not
change even if the new, but better controlled enablement/disablement
of special members will be accepted, see

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2210.html

> explicit array(const T &v); // Initialize with N copies of v
>
> array(array &&a); //Move constructor. Does element-by-element moves
>
> template <class Iterator>
> array(Iterator first, Iterator last); //two-iterator constructor
>
> template<class U, size_T M>
> array(const array<U, M> &a); // converting constructor
>
> template <class U, size_t M>
> array(array<U, M> &&a); //Converting move constructor
>
> array(initializer_list<T> init_list);  // If we add these others, we
> must define an initializer_list constructor.
>
> template <class U, class M>
> array operator=(const array<U,M> &a); //Converting assignment operator
>
> template <class U, class M>
> array operator=(array<U,M> &&a); //Converting move-assignment operator
>
> array &operator=(initializer_list<T> init);
>
> void assign(initializer_list<T> init);
> template <class Iterator>
>
> array &assign(Iterator first, Iterator last); //Assignment from pair of
> iterators
>
> array &operator=(array &&v); //Move assignment

I think these could all be added without violating the *new* POD
proposal. With old POD definition (that is the current one) not a
single
c'tor would be allowed.
With the new definition the data member can also be made private,
which supports better encapsulation.

Greetings from Bremen

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Document N2220 in the 2007-03 mailing,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2220.pdf ,
discusses uses of the proposed new initializer_list class in the
standard library.  It says that we should not change std::array because
arrays can already be initialized via initializer_lists.  This is true,
but at the cost of array not having any user-defined constructors or
assignment operators.  I think that if we do add initializer_lists to
C++0x, we should take the opportunity to give std::array a fuller
interface.

Some useful constructors and assignment-operators for array<T, N>
include the following:

array(); //Default constructor to ensure the entire array is initialized.

explicit array(const T &v); // Initialize with N copies of v

array(array &&a); //Move constructor. Does element-by-element moves

template <class Iterator>
array(Iterator first, Iterator last); //two-iterator constructor

template<class U, size_T M>
array(const array<U, M> &a); // converting constructor

template <class U, size_t M>
array(array<U, M> &&a); //Converting move constructor

array(initializer_list<T> init_list);  // If we add these others, we
must define an initializer_list constructor.

template <class U, class M>
array operator=(const array<U,M> &a); //Converting assignment operator

template <class U, class M>
array operator=(array<U,M> &&a); //Converting move-assignment operator

array &operator=(initializer_list<T> init);

void assign(initializer_list<T> init);
template <class Iterator>

array &assign(Iterator first, Iterator last); //Assignment from pair of
iterators

array &operator=(array &&v); //Move assignment

Note that when we initialize an array from a range, we should have a
consistent policy about what to do when the number of elements in the
range is not equal to N. The simplest is to default-initialize trailing
elements if the number of elements is less than N and to drop elements
from the end of the input if the number of elements is greater than N.

Joe Gottman

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]