|
Boost : |
From: Mark Rodgers (mark.rodgers_at_[hidden])
Date: 2000-05-27 04:26:50
From: Thomas Holenstein <tholenst_at_[hidden]>
> Furthermore I suggest not making it an aggregate: after
> all, if you want a array of 1000 Elements of a class which
> has no default constructor, you could get quite busy.
> Otherwise it would be possible to have a constructor
> array<..>(const T& elem = T())
I'm not so sure. As I understand it, the intent was to provide
a thin wrapper on built-in arrays without the overhead of vector.
If you are going to allow arrays of classes with no default
constructor, you won't be able to use a built-in array in the
implementation. Keep adding "it would be nice to have..."
features, and before you know it you'll have reinvented vector.
At the other end of the scale, I think one of the principle
advantages of an array class over vector would be the ability
to specify an initialisation list. If it lost this, I doubt I
would use it; I don't think the overhead of vector is enough
by itself to make me want something else.
Furthermore, if we want to default initialise all elements in
arrays of built-in types, can't we just do this:
array<int,1000> a = {{}};
I don't think that is too bad. And I don't see anything wrong
with
array<int,1000> a;
std::fill(a.begin(), a.end(), 100);
if I want to fill my array with other values.
So in total, I have to say I like the array presented very much
as it is and think it being an aggregate is very important.
Just one minor quibble though. Shouldn't it be
void swap (array& y) {
std::swap_ranges(begin(), end(), y.begin());
}
and
template<class T, std::size_t N>
bool operator== (const array<T,N>& x, const array<T,N>& y) {
return std::equal(x.begin(), x.end(), y.begin());
}
and
template<class T, std::size_t N>
bool operator< (const array<T,N>& x, const array<T,N>& y) {
return std::lexicographical_compare(
x.begin(), x.end(), y.begin(), y.end());
}
I'm a bit surprised to see someone who's written a book about the
standard library failing to use it! ;-)
Mark
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk