| Thread overview | |||||||||
|---|---|---|---|---|---|---|---|---|---|
|
March 21, 2008 Re: Smart slicing | ||||
|---|---|---|---|---|
| ||||
bearophile Wrote:
> Trevor Parscal:
> > Allowing negetive indexes seems like a nice feature - but in fact acts to hide bugs in software, which is something that D makes efforts not to do.
>
> In practice it rarely produces bugs, but note that my whole post was not about negative indexes, it was about out-of-bound arrays (positive) indexes.
>
> Bye,
> bearophile
Allowing out-of-bounds indexes hides bugs. An out of bounds index should always be an error which is considered exceptional.
If you handle the index wrapping yourself, it's obvious to everyone that in that particular case that would be an OK thing to do - in all other cases, it could potentially be an error..
- Trevor
| ||||
March 21, 2008 Re: Smart slicing | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Trevor Parscal | Trevor Parscal Wrote: > Allowing out-of-bounds indexes hides bugs. An out of bounds index should always be an error which is considered exceptional. I (like all all Ruby and Python programmers) use such things all the time, and only once in a while it actually produces a bug in my programs, so I presume you are wrong. > If you handle the index wrapping yourself, it's obvious to everyone that in that particular case that would be an OK thing to do - in all other cases, it could potentially be an error.. In my post I am talking about using an alternative (standard) syntax fur such usages (to keep speed up, not to remove bugs). Bye, bearophile | |||
March 23, 2008 Re: Smart slicing | ||||
|---|---|---|---|---|
| ||||
Posted in reply to bearophile | bearophile wrote:
> Trevor Parscal Wrote:
>> Allowing out-of-bounds indexes hides bugs. An out of bounds index should always be an error which is considered exceptional.
>
> I (like all all Ruby and Python programmers) use such things all the time, and only once in a while it actually produces a bug in my programs, so I presume you are wrong.
>
>
>> If you handle the index wrapping yourself, it's obvious to everyone that in that particular case that would be an OK thing to do - in all other cases, it could potentially be an error..
>
> In my post I am talking about using an alternative (standard) syntax fur
> such usages (to keep speed up, not to remove bugs).
>
I use my own vector/matix code in python. I made sure that out-of-bounds indexes are not silently ignored. This is a very valuable feature.
y[a:b:c] = z[d:e]
I rely on the error checking here to tell me when I mis-calculated. It has found many errors for me.
| |||
March 30, 2008 Re: Smart slicing | ||||
|---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Thu, 20 Mar 2008 20:48:34 -0400, bearophile wrote:
> Trevor Parscal Wrote:
>> Allowing out-of-bounds indexes hides bugs. An out of bounds index should always be an error which is considered exceptional.
>
> I (like all all Ruby and Python programmers) use such things all the time, and only once in a while it actually produces a bug in my programs, so I presume you are wrong.
He is not referring to when it is the programmers intent to do it. It is the times when an index has gone out of bounds by accident.
auto str = "Hello";
auto i = 0;
while(true) {
writefln(str[i++]);
}
ooops, I forgot an exit condition.
| |||
March 30, 2008 Re: Smart slicing | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | Jesse Phillips:
> He is not referring to when it is the programmers intent to do it. It is
> the times when an index has gone out of bounds by accident.
> while(true) {
> writefln(str[i++]);
I was talking about _slicing_, not about array indexing (that is 1..5 instead of 5), so you are talking about something different. For a single index I agree that's an error (and that's a runtime error in Python too).
In the meantime nearly everyone has said this is a bad feature to add to D, so I have stopped advocating for it :-) There are quite more important things I like to think/talk about.
Bye,
bearophile
| |||
March 31, 2008 Re: Smart slicing | ||||
|---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Sun, 30 Mar 2008 19:44:57 -0400, bearophile wrote:
> Jesse Phillips:
>> He is not referring to when it is the programmers intent to do it. It
>> is the times when an index has gone out of bounds by accident.
>> while(true) {
>> writefln(str[i++]);
>
> I was talking about _slicing_, not about array indexing (that is 1..5 instead of 5), so you are talking about something different. For a single index I agree that's an error (and that's a runtime error in Python too).
>
> In the meantime nearly everyone has said this is a bad feature to add to D, so I have stopped advocating for it :-) There are quite more important things I like to think/talk about.
>
> Bye,
> bearophile
ah, yes, my mistake. I forgot that I was reading old articles. In any case I will explain what I was aiming for, and I did mean to use slicing.
while(true) {
auto subStr = str[0..i++];
//Do stuff with subStr
}
I just wanted to point out that if a variable is used an the programmer wishes to stop the said "loop" when you have reached the end but forgot to check, you have a working program that false to work as expected.
| |||
March 31, 2008 Re: Smart slicing | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | Jesse Phillips:
> while(true) {
> auto subStr = str[0..i++];
> //Do stuff with subStr
> }
> I just wanted to point out that if a variable is used an the programmer
> wishes to stop the said "loop" when you have reached the end but forgot
> to check, you have a working program that false to work as expected.
In C/C++ you often put bugs like that in the code because:
- you are using too much low level abstractions: higher level functions (like map, filter, etc, and list comp/generators too) allow you to iterate and process collections avoiding to manage indexes by yourself.
- the syntax is so cluttered that it doesn't let you see the bugs well;
- You don't have an interactive shell to try every little snippet of code;
- (and there are other causes too).
Bye,
bearophile
| |||
Copyright © 1999-2021 by the D Language Foundation
Permalink
Reply