|
|
Blitz Devel : |
From: Julian C. Cummings (cummings_at_[hidden])
Date: 2003-01-03 13:57:57
Hi Tom,
There are some problems with this idea. First, operator[]
can only take a single argument, not a comma-delimited list
of arguments like operator(). So the last method in your
example below would not be valid code. That is one reason
why operator[] makes an ideal indexing operator for any
inherently one-dimensional container such as a vector or
a deque, but does not work so well for a multi-dimensional
array container. In fact, the blitz Vector and TinyVector
classes support operator[] as a synonym for operator().
The other problem is that as you noted at the end of your
comments, there is already a definition for operator[]
with the blitz Array definition. The idea of this method
is to support indirect addressing of arrays, by allowing
the user to refer to an arbitrary list of array elements.
In addition, operator[] has been overloaded to accept a
single integer argument and return a single component of
a multicomponent Array. This is used when you have an
Array of TinyVector elements (or some other indexable type)
and you want to refer to a single component of the array
of vectors. So this overloaded operator[] would conflict
with the first method in your example below.
I can understand why you might want containers to adhere
to a single standard operator for indexing, but there are
significant drawbacks to designing a multi-dimensional
array class that uses operator[] to do this. You should
consider whether your class framework is intended to deal
with multi-dimensional storage types or not. If so, you
may need to consider how operator[] and your iterator types
will support this. If not, use the blitz Vector storage
type, which already provides the operator[] indexing.
Regards, Julian C.
Dr. Julian C. Cummings
Staff Scientist, CACR/Caltech
(626) 395-2543
cummings_at_[hidden]
> -----Original Message-----
> From: blitz-dev-admin_at_[hidden]
> [mailto:blitz-dev-admin_at_[hidden]]On Behalf Of Tom Hilinski
> Sent: Friday, January 03, 2003 5:28 AM
> To: blitz-dev_at_[hidden]
> Subject: [Blitz-dev] Array::operator[]
>
>
> I would like to consider providing operator[] for Array, identical to
> operator() (my idea is to simply call operator(), all inline).
>
> The reason is to provide compatibilty with std:: containers
> (vector, deque)
> that provide operator[], and allow Array to be used
> interchangably with them
> via a template parameter. We have a small template class
> framework that can
> accept a container to use for its internal storage, but it must provide
> element access via operator[] (as well as iterator's, already available in
> Array).
>
> An additional benefit would be the tremendous ease of modifying
> our existing
> models to use blitz Arrays rather conventional dynamically
> allocated arrays,
> which are often indexed by [].
>
> For example, the following functions show how I propose
> implementing these:
>
> template<class P_numtype, int N_rank>
> class Array : public MemoryBlockReference<P_numtype>
> {
> .....
> T_numtype operator[](int i0) const
> {
> return operator() (i0);
> }
>
> T_array operator[](Range r0) const
> {
> return operator() (r0);
> }
>
> template<class T1, class T2>
> _bz_typename SliceInfo<T_numtype,T1,T2>::T_slice
> operator[](T1 r1, T2 r2) const
> {
> return operator() (r1, r2);
> }
>
> etc.
>
> I see in the 0.6 source that operator[] is overloaded once to accept a std
> container:
>
> template<class T_indexContainer>
> IndirectArray<T_array, T_indexContainer>
> operator[](const T_indexContainer& index)
>
> I don't think this should cause an issue with my proposed operator[]'s.
>
> Do you have any ideas on the implications and issues I would face by
> providing operator[]?
>
> Tom Hilinski
>
> Natural Resource Ecology Laboratory
> Colorado State University
> E-mail: Tom.Hilinski_at_[hidden]
>
> _______________________________________________
> Blitz-dev mailing list
> Blitz-dev_at_[hidden]
> http://www.oonumerics.org/mailman/listinfo.cgi/blitz-dev
>