Re: [boost] new version of array<>

From: Nicolai Josuttis (nico_at_[hidden])
Date: 2000-05-26 10:14:26

Thomas Holenstein wrote:
> 
> Hello,
> 
> OK, here are some suggestions about Nico's array class.
> Some of them might have been discussed before.  So please
> ignore these.
> 
> I think
> 
> - rangecheck should be private (Does the aggregate
>   restriction does hold for methods?)
> 
it IS an aggregate restriction

> - an array<int, N> should be comparable to a array<short, N>,
>   so we probably need more templatized versions of operator==,
>   operator<, etc.
> 
OK

> - an array<int, N> should be comparable to an array<int, M>,
>   returnig false (I'm not sure of this...)
> 
no, I don't think so. This won't even compile because these
are different types and that's fine. For anything else
we have STL algorithms.

> - sometimes it would be useful to have full grown iterators,
>   instead of just pointers. (see for example the libstdc++-v3
>   faq on http://sourceware.cygnus.com/libstdc++/faq/#5_1 )
> 
of course. This is just ONE implementation that (as it is usual
in the STL) prefers speed over safety.
May be other iterators should optionally be provided
(via preprocessor).

> - Why do you include <iterator>?
> 
for reverse_iterator stuff

> - I think Jeremy's right, use mismatch for !=.  It's faster.
> 
OK
> 
> 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 constructur, you could get quite busy.
> Otherwise it would be possible to have a constructor
> array<..>(const T& elem = T())
> 
I tend to agree.
Let's see how others think in the next couple of weeks.

> Thomas
> 
> ------------------------------------------------------------------------
> Find long lost high school friends:
> http://click.egroups.com/1/4056/3/_/9351/_/959346756/
> ------------------------------------------------------------------------

-- 
Nicolai M. Josuttis          	http://www.josuttis.de/
Solutions in Time        	mailto:solutions_at_[hidden]