www.digitalmars.com         C & C++   DMDScript  

D - Overloading array operator

reply "QUS" <qus go2.pl> writes:
Is there a chance to have [] overloaded in D?

cheers,
QUS
Aug 20 2003
parent reply "Walter" <walter digitalmars.com> writes:
Yes. It needs to be done, I just haven't done it yet.

"QUS" <qus go2.pl> wrote in message news:bhvgir$1ksk$1 digitaldaemon.com...

 Is there a chance to have [] overloaded in D?

 cheers,
 QUS
Aug 27 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
 "QUS" <qus go2.pl> wrote in message news:bhvgir$1ksk$1 digitaldaemon.com...

Is there a chance to have [] overloaded in D?




Walter wrote:

 Yes. It needs to be done, I just haven't done it yet.


This needs consideration. What i mean: C++ makes it a real pain to 
define classes which behave as if they were multi-dimensional array - 
and D has been heading the same way. I think you should allow do define 
a method to resolve to an array access operator - with multiple 
parameters - not only integers so that hasharrays can be imitated. Then, 
we also need to distinguish between reads and writes.

Calling syntax would seem to cause the least ambiguity if it were 
pascal-like.

	myArray[1, 2, 3, "str"] = 5;
could resolve to:
	myArray.oparray_w(1, 2, 3, "str", 5);

	local = myArray[1, 2, 3, "str"];
could resolve to:
	myArray.oparray_r(1, 2, 3, "str");

Sather uses a_get and a_set, IIRC.

If the name is the same for both reads and writes, this results in 
ambiguity which would not allow to make array acesses by fewer 
parameters in some cases - like when you need an array to do further 
work on.

-eye
Aug 28 2003
next sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Ilya Minkov" <midiclub 8ung.at> escreveu na mensagem
news:bikq49$iar$1 digitaldaemon.com...

 "QUS" <qus go2.pl> wrote in message




news:bhvgir$1ksk$1 digitaldaemon.com...

Is there a chance to have [] overloaded in D?




 Walter wrote:
  > Yes. It needs to be done, I just haven't done it yet.

 This needs consideration. What i mean: C++ makes it a real pain to
 define classes which behave as if they were multi-dimensional array -
 and D has been heading the same way. I think you should allow do define
 a method to resolve to an array access operator - with multiple
 parameters - not only integers so that hasharrays can be imitated. Then,
 we also need to distinguish between reads and writes.

 Calling syntax would seem to cause the least ambiguity if it were
 pascal-like.

 myArray[1, 2, 3, "str"] = 5;
 could resolve to:
 myArray.oparray_w(1, 2, 3, "str", 5);

 local = myArray[1, 2, 3, "str"];
 could resolve to:
 myArray.oparray_r(1, 2, 3, "str");

 Sather uses a_get and a_set, IIRC.

 If the name is the same for both reads and writes, this results in
 ambiguity which would not allow to make array acesses by fewer
 parameters in some cases - like when you need an array to do further
 work on.

 -eye



There's also the issue with slices that are important to multi-dimensional
arrays, like matrices, and strides (currently unavailable in D) which can
both be represented by the [ ] operator. The Blitz++
<http://www.oonumerics.org/blitz/> library has good examples of this.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003
Aug 29 2003
prev sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 This needs consideration. What i mean: C++ makes it a real pain to
 define classes which behave as if they were multi-dimensional array -


Check out the fixed_/frame_array_2/3/4d templates in STLSoft

It might have been a laborious task, but other than making some stupid
indexing typos in development they weren't what I would call "a real pain"
Aug 29 2003
parent reply Ilya Minkov <webmaster midiclub.de.vu> writes:
Matthew Wilson wrote:

 Check out the fixed_/frame_array_2/3/4d templates in STLSoft


Ah, thanks. :) with its documentation i would never have found them if 
you didn't mention...

Well, they solve a problem of creating real multi-dimensional arrays, 
not objects or properties which *behave* as if they were an array, but 
would retrieve data from elsewhere, and store it elsewhere. This need 
not necesarily be in memory, it can be a database or whatever.

A look at the boost also gave a real array, but no fake 
multi-dimensional arrays. Nor does Blitz++ seem to.


 It might have been a laborious task, but other than making some stupid
 indexing typos in development they weren't what I would call "a real pain"


So laborous in fact, that one would think twice before doing them. A 
screen of code (proxies!) to make something work, which only needs 2 
lines with decent language support?

It is the task of D, to make routine coding faster and easier, and 
besides to move most klugdy library parts into the core language to make 
using such features easier.

-eye
Aug 31 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Ilya Minkov" <webmaster midiclub.de.vu> wrote in message
news:bitlt7$1sib$1 digitaldaemon.com...

 Matthew Wilson wrote:

 Check out the fixed_/frame_array_2/3/4d templates in STLSoft


 Ah, thanks. :) with its documentation i would never have found them if
 you didn't mention...


well, ahem, yes, the STLSoft documentation is not the best. I'd be
interested in any specific thoughts you might have to improve it.


 Well, they solve a problem of creating real multi-dimensional arrays,
 not objects or properties which *behave* as if they were an array, but
 would retrieve data from elsewhere, and store it elsewhere. This need
 not necesarily be in memory, it can be a database or whatever.


This is an intriguing issue. I may well implement such a component for C++
in STLSoft. If you take a look at the current multidim arrays you can see
that a higher order array's [] operator returns a proxy instance of a lower
order array, e.g.

template<   ss_typename_param_k T
        ,   ss_size_t N0
        ,   ss_size_t N1
        ,   ss_typename_param_k P   =   do_construction<T>
        >
class frame_array_2d
{
     typedef frame_array_1d<T, N1, P>                        dimension_type;

       . . .

     dimension_type          operator [](index_type i0);
    const dimension_type    operator [](index_type i0) const;

so it would be a very small matter to allow user-calls to do the same thing
on raw memory. If you think this is something worth having, and that would
see real use, then I'll give it a go. (Although it will have to wait until
the next release, which is lurking behind several higher-priority things.)


 It might have been a laborious task, but other than making some stupid
 indexing typos in development they weren't what I would call "a real




pain"

 So laborous in fact, that one would think twice before doing them. A
 screen of code (proxies!) to make something work, which only needs 2
 lines with decent language support?


Well I can see how the language could do that for us, but I'm concerned that
we may put things in the language which, by virtue of being iceberged (most
of the implementation is under the surface) implies safety, but yet relies
on specific knowledge on the part of the coder that the compiler cannot
validate. If, perhaps, we could cast some memory to a multi-dim array, then
I think that would be fine.


 It is the task of D, to make routine coding faster and easier, and
 besides to move most klugdy library parts into the core language to make
 using such features easier.

 -eye
Aug 31 2003