www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - array slicing

reply "Charles" <no email.com> writes:
This has probably already been mentioned , and I know D's not implementing
new features , but what about using negative numbers to indicate starting
from the end of the array

char [] x = "comma,";

char [] y = x[0 .. -1]; // y is 'comma'


No special charaters , no new keywords , no scoping rules ( is length still
a keyword in slicing ? ).

Thoughts ?

Charlie
Dec 16 2004
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 16 Dec 2004 16:45:09 -0600, Charles <no email.com> wrote:
 This has probably already been mentioned , and I know D's not  
 implementing
 new features , but what about using negative numbers to indicate starting
 from the end of the array

 char [] x = "comma,";

 char [] y = x[0 .. -1]; // y is 'comma'


 No special charaters , no new keywords , no scoping rules ( is length  
 still a keyword in slicing ? ).

I believe so, however I think it was decided it was not a GoodThing(TM).
 Thoughts ?

It has been mentioned before, the problem with it is: "that array subscripting in C and C++ and D can be done with signed integers because it is legal _and meaningful_ to pass a -ve subscript to mean prior to the given base (pointer and/or array)." - Matthew Another suggestion was to have a character or symbol to mean the end of the array, for example: char[] y = x[0..$-1]; so $ means the length of the array. Instead of '$', 'length' was decided upon and used. The problem with length is that it can conflict with global/local and other variables. So perhaps it's time to revisit the idea of using $? Regan
Dec 16 2004
next sibling parent reply "Charles" <no email.com> writes:
 "that array subscripting in C and C++ and D can be done with signed
 integers because it is legal _and meaningful_ to pass a -ve subscript to
 mean prior to the given base (pointer and/or array)." - Matthew

Hmm , could i get an example of how this would be useful in D's arrays ? Pointer's I can understand , and i could see the case for C/C++ , but for D ? Seems a big sacrifice for backward compatibility .
 The problem with length is that it can conflict with global/local and
 other variables.

I agree, especially since length is such a commonly used variable name.
 So perhaps it's time to revisit the idea of using $?

I dislike special charaters ( just my own feelings ) , visibly seems unappealing - breaks the consistency of the language, though I think its better than 'length'. Charlie "Regan Heath" <regan netwin.co.nz> wrote in message news:opsi4ieib023k2f5 ally...
 On Thu, 16 Dec 2004 16:45:09 -0600, Charles <no email.com> wrote:
 This has probably already been mentioned , and I know D's not
 implementing
 new features , but what about using negative numbers to indicate


 from the end of the array

 char [] x = "comma,";

 char [] y = x[0 .. -1]; // y is 'comma'


 No special charaters , no new keywords , no scoping rules ( is length
 still a keyword in slicing ? ).

I believe so, however I think it was decided it was not a GoodThing(TM).
 Thoughts ?

It has been mentioned before, the problem with it is: "that array subscripting in C and C++ and D can be done with signed integers because it is legal _and meaningful_ to pass a -ve subscript to mean prior to the given base (pointer and/or array)." - Matthew Another suggestion was to have a character or symbol to mean the end of the array, for example: char[] y = x[0..$-1]; so $ means the length of the array. Instead of '$', 'length' was decided upon and used. The problem with length is that it can conflict with global/local and other variables. So perhaps it's time to revisit the idea of using $? Regan

Dec 16 2004
next sibling parent Derek Parnell <derek psych.ward> writes:
On Thu, 16 Dec 2004 17:14:51 -0600, Charles wrote:


[snip]

 So perhaps it's time to revisit the idea of using $?

I dislike special charaters ( just my own feelings ) , visibly seems unappealing - breaks the consistency of the language, though I think its better than 'length'.

I agree. Let's go back to a real language like COBOL. ADD WS_NEWVALUE TO WS_VALUE GIVING WS_RESULT. None of this weirdo symbolic stuff. Let's all just use English words to make ourself perfectly understood ... and start all lines on column 10. ;-) Nah, just joking ... personally I like the '$' symbol used in this context. Its short, not a valid identifier, not used for anything else, and harks back to the commonly used regular expression syntax that means end-of-line. The other language I use regularly (Euphoria) has just introduced this symbol in its slicing syntax and it is glorious. I knew it would be a nice syntax-sugar-drop, but it suddenly has an uplifting effect in the way one approaches coding. It is no longer a chore to do end-of-slice coding. It fact, you sort of look for ways to use it 'cos its so cool. -- Derek Melbourne, Australia 17/12/2004 10:28:55 AM
Dec 16 2004
prev sibling parent reply "Charles" <no email.com> writes:
Actually I don't see the case for C/C++ , could anyone provide an example
where this behaviour is defined and reliable ?

Thanks,
Charlie

p.s. Anyone read imperfect C++ ( matthew's book ) ? I read a good review
about but haven't been able to find it at my local bookstores, will have to
order it :S.


"Charles" <no email.com> wrote in message
news:cpt4r1$epb$1 digitaldaemon.com...
 "that array subscripting in C and C++ and D can be done with signed
 integers because it is legal _and meaningful_ to pass a -ve subscript to
 mean prior to the given base (pointer and/or array)." - Matthew

Hmm , could i get an example of how this would be useful in D's arrays ? Pointer's I can understand , and i could see the case for C/C++ , but for

 ?  Seems a big sacrifice for backward compatibility .

 The problem with length is that it can conflict with global/local and
 other variables.

I agree, especially since length is such a commonly used variable name.
 So perhaps it's time to revisit the idea of using $?

I dislike special charaters ( just my own feelings ) , visibly seems unappealing - breaks the consistency of the language, though I think its better than 'length'. Charlie "Regan Heath" <regan netwin.co.nz> wrote in message news:opsi4ieib023k2f5 ally...
 On Thu, 16 Dec 2004 16:45:09 -0600, Charles <no email.com> wrote:
 This has probably already been mentioned , and I know D's not
 implementing
 new features , but what about using negative numbers to indicate


 from the end of the array

 char [] x = "comma,";

 char [] y = x[0 .. -1]; // y is 'comma'


 No special charaters , no new keywords , no scoping rules ( is length
 still a keyword in slicing ? ).

I believe so, however I think it was decided it was not a GoodThing(TM).
 Thoughts ?

It has been mentioned before, the problem with it is: "that array subscripting in C and C++ and D can be done with signed integers because it is legal _and meaningful_ to pass a -ve subscript to mean prior to the given base (pointer and/or array)." - Matthew Another suggestion was to have a character or symbol to mean the end of the array, for example: char[] y = x[0..$-1]; so $ means the length of the array. Instead of '$', 'length' was decided upon and used. The problem with length is that it can conflict with global/local and other variables. So perhaps it's time to revisit the idea of using $? Regan


Dec 17 2004
parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <cq07t2$jbn$1 digitaldaemon.com>, Charles says...
p.s. Anyone read imperfect C++ ( matthew's book ) ? I read a good review
about but haven't been able to find it at my local bookstores, will have to
order it :S.

I went to the best Computer Bookstore in Helsinki (, Finland), and they not only were familiar with the book, but they had sold out the first shipment in just a couple of days. I'm on the list. Looks like the per-hour-invested-writing rate will be "adequate" for Matthew, at least with this book! Congratulations!!
Dec 18 2004
parent "Charles" <no email.com> writes:
Yea my local bookstores dont carry any good technical books , but im asking
for it for christmas :).

 Congratulations!!

Second that :) Charlie "Georg Wrede" <Georg_member pathlink.com> wrote in message news:cq2kf8$2q4a$1 digitaldaemon.com...
 In article <cq07t2$jbn$1 digitaldaemon.com>, Charles says...
p.s. Anyone read imperfect C++ ( matthew's book ) ? I read a good review
about but haven't been able to find it at my local bookstores, will have


order it :S.

I went to the best Computer Bookstore in Helsinki (, Finland), and they not only were familiar with the book, but they had sold out the first shipment in just a couple of days. I'm on the list. Looks like the per-hour-invested-writing rate will be "adequate" for Matthew, at least with this book! Congratulations!!

Dec 19 2004
prev sibling parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:

 This has probably already been mentioned , and I know D's not  
 implementing
 new features , but what about using negative numbers to indicate starting
 from the end of the array

the array, for example: char[] y = x[0..$-1]; so $ means the length of the array. Instead of '$', 'length' was decided upon and used. The problem with length is that it can conflict with global/local and other variables. So perhaps it's time to revisit the idea of using $?

Or why not just stop with the Perl, and spell it out ? :-)
 import std.stdio;
 void main()
 {
   char [] x = "comma,";
   char [] y = x[0 .. x.length-1];
   writefln(y);
 }

--anders PS. perl -e 'print substr("comma,", 0, -1) . "\n"'
Dec 16 2004
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 17 Dec 2004 00:14:01 +0100, Anders F Björklund <afb algonet.se>  
wrote:
 Regan Heath wrote:

 This has probably already been mentioned , and I know D's not   
 implementing
 new features , but what about using negative numbers to indicate  
 starting
 from the end of the array

of the array, for example: char[] y = x[0..$-1]; so $ means the length of the array. Instead of '$', 'length' was decided upon and used. The problem with length is that it can conflict with global/local and other variables. So perhaps it's time to revisit the idea of using $?

Or why not just stop with the Perl, and spell it out ? :-)

Personally, I dislike Perl.
 import std.stdio;
 void main()
 {
   char [] x = "comma,";
   char [] y = x[0 .. x.length-1];
   writefln(y);
 }


Because this: void main() { Foo f = new Foo(); char[] y; y = f.longishStructureName.alsoKindaLongVariable[0..f.longishStructureName.alsoKindaLongVariable.length-1]; } is not as nice as: void main() { Foo f = new Foo(); char[] y; y = f.longishStructureName.alsoKindaLongVariable[0..$-1]; } One of the reasons "length" was added, also an array returned by a function: void main() { char[] y = foo()[0..$-1] } is nicer than: void main() { char[] temp = foo(); char[] y = temp[0..temp.length-1] } assuming foo() can be evaluated only once. Also consider multidimensional arrays. Regan
Dec 16 2004
next sibling parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:

 Personally, I dislike Perl.
 

 void main()
 {
     char[] y = foo()[0..$-1]
 }
 
 is nicer than:
 
 void main()
 {
     char[] temp = foo();
     char[] y = temp[0..temp.length-1]
 }
 
 assuming foo() can be evaluated only once.

I like Perl, that has lots of funky chars and ops. But I kinda like the explicit temp solution too... So I guess I'm ambivalent about all of it ? :-) Let's see what Walter says about it, I suppose. --anders
Dec 16 2004
prev sibling parent reply "Simon Buchan" <currently no.where> writes:
On Fri, 17 Dec 2004 12:56:32 +1300, Regan Heath <regan netwin.co.nz> wrote:

<snip>
 Because this:

 void main()
 {
 	Foo f = new Foo();
        char[] y;

 	y =  
 f.longishStructureName.alsoKindaLongVariable[0..f.longishStructureName.alsoKindaLongVariable.length-1];
 }

 is not as nice as:

 void main()
 {
 	Foo f = new Foo();
        char[] y;

 	y = f.longishStructureName.alsoKindaLongVariable[0..$-1];
 }

You do know you can just type f.longishStructureName.alsoKindaLongVariable[0..length-1]; right? Or is that what you meant with your next statement?
 One of the reasons "length" was added, also an array returned by a  
 function:

 void main()
 {
 	char[] y = foo()[0..$-1]
 }

 is nicer than:

 void main()
 {
 	char[] temp = foo();
 	char[] y = temp[0..temp.length-1]
 }

 assuming foo() can be evaluated only once.

As far as I am aware, they both compile, ($ for length, of course) and to the same instructions (except for the extra var, of course)
 Also consider multidimensional arrays.

A valid point, but the way they are currently done, you should be able to type foo[5][][17][][] reallyBigMultiArray; ... reallyBigMultiArray[length][3][14][length-3] = someFooArrayOfFiveFunction(); and it will pick the current subscript's scope's length, But I haven't tested it yet.
 Regan

-- "Unhappy Microsoft customers have a funny way of becoming Linux, Salesforce.com and Oracle customers." - www.microsoft-watch.com: "The Year in Review: Microsoft Opens Up" -- "I plan on at least one critical patch every month, and I haven't been disappointed." - Adam Hansen, manager of security at Sonnenschein Nath & Rosenthal LLP (Quote from http://www.eweek.com/article2/0,1759,1736104,00.asp) -- "It's been a challenge to "reteach or retrain" Web users to pay for content, said Pizey" -Wired website: "The Incredible Shrinking Comic"
Dec 18 2004
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 19 Dec 2004 20:56:30 +1300, Simon Buchan <currently no.where>  
wrote:
 On Fri, 17 Dec 2004 12:56:32 +1300, Regan Heath <regan netwin.co.nz>  
 wrote:

 <snip>
 Because this:

 void main()
 {
 	Foo f = new Foo();
        char[] y;

 	y =  
 f.longishStructureName.alsoKindaLongVariable[0..f.longishStructureName.alsoKindaLongVariable.length-1];
 }

 is not as nice as:

 void main()
 {
 	Foo f = new Foo();
        char[] y;

 	y = f.longishStructureName.alsoKindaLongVariable[0..$-1];
 }

You do know you can just type f.longishStructureName.alsoKindaLongVariable[0..length-1]; right? Or is that what you meant with your next statement?

Yes.
 One of the reasons "length" was added, also an array returned by a  
 function:

 void main()
 {
 	char[] y = foo()[0..$-1]
 }

 is nicer than:

 void main()
 {
 	char[] temp = foo();
 	char[] y = temp[0..temp.length-1]
 }

 assuming foo() can be evaluated only once.

As far as I am aware, they both compile, ($ for length, of course) and to the same instructions (except for the extra var, of course)

I had hoped they would. I realised this is only syntactical sugar however I believe it increases readability.
 Also consider multidimensional arrays.

A valid point, but the way they are currently done, you should be able to type foo[5][][17][][] reallyBigMultiArray; ... reallyBigMultiArray[length][3][14][length-3] = someFooArrayOfFiveFunction(); and it will pick the current subscript's scope's length, But I haven't tested it yet.

Exactly. It was my impression also that it should work, I haven't tested it yet either :) Regan
Dec 19 2004
prev sibling parent reply "Lionello Lunesu" <lionello.lunesu crystalinter.remove.com> writes:
 char [] y = x[0 .. -1]; // y is 'comma'


 No special charaters , no new keywords , no scoping rules ( is length 
 still
 a keyword in slicing ? ).

 Thoughts ?

What about char [] y = x[0...]; No keywords, and it can't possibly be interpreted any other way. No way to slice up to next-to-last element though. Lionello.
Dec 16 2004
next sibling parent reply k2 <k2_member pathlink.com> writes:
I also had a same idea. 

char[] foo = bar[x .. ]; // x to bar.length
char[] foo = bar[ .. x]; // 0 to x

It is very simple. 

What about

char [] y = x[0...];

No keywords, and it can't possibly be interpreted any other way. No way to 
slice up to next-to-last element though.

Lionello. 

Dec 17 2004
parent reply Derek <derek psyc.ward> writes:
On Fri, 17 Dec 2004 12:01:46 +0000 (UTC), k2 wrote:

 I also had a same idea. 
 
 char[] foo = bar[x .. ]; // x to bar.length
 char[] foo = bar[ .. x]; // 0 to x
 
 It is very simple. 
 
What about

char [] y = x[0...];

No keywords, and it can't possibly be interpreted any other way. No way to 
slice up to next-to-last element though.

Lionello.


Unfortunately this syntax is slightly ambiguous. It could mean that the coder has left something off. The compiler can no longer tell if you simply forgot something or not. Too easy to make that mistake, IMHO. -- Derek Melbourne, Australia
Dec 17 2004
parent reply "Lionello Lunesu" <lionello.lunesu crystalinter.remove.com> writes:
 I also had a same idea.

 char[] foo = bar[x .. ]; // x to bar.length
 char[] foo = bar[ .. x]; // 0 to x


I actually meant it with 3 dots, because it already exists as a 'something without end' notation in the language. But your 2-dot version would be good against Derek's argument:
char [] y = x[0...];


Unfortunately this syntax is slightly ambiguous. It could mean that the coder has left something off. The compiler can no longer tell if you simply forgot something or not. Too easy to make that mistake, IMHO.

Hmmm. I wonder if this reasoning can be applied to other constructions in D (or C for that matter). The double-dot ".." would be a good candidate then, since for it to be ambigous, the programmer would have to forget a dot and an expression in that case, which has a much smaller chance of occuring. Lionello.
Dec 17 2004
parent Georg Wrede < Georg Wrede_member pathlink.com> writes:
In article <cpuquc$29lb$1 digitaldaemon.com>, Lionello Lunesu says...
 I also had a same idea.

 char[] foo = bar[x .. ]; // x to bar.length



Too near "char[] foo = bar[x .. $]; // ..."
 char[] foo = bar[ .. x]; // 0 to x



Too near "char [] foo = bar[0..X] // ..." This of course assuming we are going to get a "$" operator as in Euphoria.
I actually meant it with 3 dots, because it already exists as a 'something 
without end' notation in the language. But your 2-dot version would be good 
against Derek's argument:

char [] y = x[0...];


Unfortunately this syntax is slightly ambiguous. It could mean that the coder has left something off. The compiler can no longer tell if you simply forgot something or not. Too easy to make that mistake, IMHO.

Hmmm. I wonder if this reasoning can be applied to other constructions in D (or C for that matter). The double-dot ".." would be a good candidate then, since for it to be ambigous, the programmer would have to forget a dot and an expression in that case, which has a much smaller chance of occuring. Lionello.

Dec 18 2004
prev sibling parent "Charles" <no email.com> writes:
Only problem with this is you can specify an offset from the end of the
array :(.

Charlie

"Lionello Lunesu" <lionello.lunesu crystalinter.remove.com> wrote in message
news:cpu384$1dgu$1 digitaldaemon.com...
 char [] y = x[0 .. -1]; // y is 'comma'


 No special charaters , no new keywords , no scoping rules ( is length
 still
 a keyword in slicing ? ).

 Thoughts ?

What about char [] y = x[0...]; No keywords, and it can't possibly be interpreted any other way. No way to slice up to next-to-last element though. Lionello.

Dec 17 2004