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


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


 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