www.digitalmars.com         C & C++   DMDScript  

D - Arrays

reply "Vathix" <Vathix kernel.net> writes:
None of this is necessary but might be good for convenience:

1)
Why can't I use ++, += etc on a dynamic array's .length?  Those operators
are for typing less, so why can't I be lazy with this too?  :+)

2)
I think it would be handy to allow concating a single object to an array
with ~.
e.g.  arrayObject ~ singleObject

3)
Would it really be considered going out of bounds if you were slicing an
array of 0 elements past the last element (or before the first)?  It
shouldn't even access the memory at the location so I think it should be
allowed.
e.g.  myObj[0 .. i] ~ myObj[i + 1 .. myObj.length]
If I wanted to remove the i'th object and i + 1 was the end.
Apr 12 2003
next sibling parent reply J C Calvarese <jcc-47 excite.com> writes:
I'm with you.  I've been annoyed with each of those issues.  I suspect 
there's a reason for each, but they still bug me.

Vathix wrote:
 None of this is necessary but might be good for convenience:
 
 1)
 Why can't I use ++, += etc on a dynamic array's .length?  Those operators
 are for typing less, so why can't I be lazy with this too?  :+)

Somebody wrote before why this was prohibited, but I don't remember quite what it was. It seemed like it was to keep us from shooting ourselves in the foot with things like: s[s.length++] = "whatever"; but I don't remember what's so bad about that...
 
 2)
 I think it would be handy to allow concating a single object to an array
 with ~.
 e.g.  arrayObject ~ singleObject

Yeah, sometimes it'd be very convenient to concatenate a fixed-length string and a variable-length string, too.
 
 3)
 Would it really be considered going out of bounds if you were slicing an
 array of 0 elements past the last element (or before the first)?  It
 shouldn't even access the memory at the location so I think it should be
 allowed.
 e.g.  myObj[0 .. i] ~ myObj[i + 1 .. myObj.length]
 If I wanted to remove the i'th object and i + 1 was the end.
 
 

It'd suit me fine if you had a five element array and s[7..100] just yielded an empty set. "Error: Access Violation" grates on my nerves. :) Justin
Apr 13 2003
parent reply "anderson" <anderson badmama.com.au> writes:
"J C Calvarese" <jcc-47 excite.com> wrote in message
news:b7b4l8$191j$1 digitaldaemon.com...
 I'm with you.  I've been annoyed with each of those issues.  I suspect
 there's a reason for each, but they still bug me.

 Vathix wrote:
 None of this is necessary but might be good for convenience:

 1)
 Why can't I use ++, += etc on a dynamic array's .length?  Those


 are for typing less, so why can't I be lazy with this too?  :+)

Somebody wrote before why this was prohibited, but I don't remember quite what it was. It seemed like it was to keep us from shooting ourselves in the foot with things like: s[s.length++] = "whatever"; but I don't remember what's so bad about that...

As I remember, it was a memory management thing because Walter was tring to protect people from writing loops using array++ within. We went into large discussions about memory blocks ect... and other techniques in an attempt to find some solution. It was eventually decided against because apparently it was to hard to come up with something optiminal for all (most) cases. Anyhow, a point was also brought up about "s[s.length++] = "whatever";" was: What is the precidence order? Anyhow you can use, s ~= "whatever";
 2)
 I think it would be handy to allow concating a single object to an array
 with ~.
 e.g.  arrayObject ~ singleObject

Yeah, sometimes it'd be very convenient to concatenate a fixed-length string and a variable-length string, too.
 3)
 Would it really be considered going out of bounds if you were slicing an
 array of 0 elements past the last element (or before the first)?  It
 shouldn't even access the memory at the location so I think it should be
 allowed.
 e.g.  myObj[0 .. i] ~ myObj[i + 1 .. myObj.length]
 If I wanted to remove the i'th object and i + 1 was the end.

It'd suit me fine if you had a five element array and s[7..100] just yielded an empty set. "Error: Access Violation" grates on my nerves. :) Justin

Apr 17 2003
parent J C Calvarese <jcc7 cox.net> writes:
Comments below...

anderson wrote:
 "J C Calvarese" <jcc-47 excite.com> wrote in message
 news:b7b4l8$191j$1 digitaldaemon.com...
1)
Why can't I use ++, += etc on a dynamic array's .length?  Those


operators
are for typing less, so why can't I be lazy with this too?  :+)

Somebody wrote before why this was prohibited, but I don't remember quite what it was. It seemed like it was to keep us from shooting ourselves in the foot with things like: s[s.length++] = "whatever"; but I don't remember what's so bad about that...

As I remember, it was a memory management thing because Walter was tring to protect people from writing loops using array++ within. We went into large discussions about memory blocks ect... and other techniques in an attempt to find some solution. It was eventually decided against because apparently it was to hard to come up with something optiminal for all (most) cases. Anyhow, a point was also brought up about "s[s.length++] = "whatever";" was: What is the precidence order? Anyhow you can use, s ~= "whatever";

Thanks for the background (yeah precedence order would be a problem in that case). I'd like to be able to just type: "s.length++;" to increase the elements in the array, but oh well. (I'll promise not to use put it in brackets if that would help.) Thanks for the ~= hint. I'll try use it to my advantage. Justin
Apr 17 2003
prev sibling next sibling parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
I agree with 3 certainly.

I do recall that there were compelling reasons against 1, but cannot
remember what (sorry).

No opinion as yet on 2

"Vathix" <Vathix kernel.net> wrote in message
news:b7aqi4$12o6$1 digitaldaemon.com...
 None of this is necessary but might be good for convenience:

 1)
 Why can't I use ++, += etc on a dynamic array's .length?  Those operators
 are for typing less, so why can't I be lazy with this too?  :+)

 2)
 I think it would be handy to allow concating a single object to an array
 with ~.
 e.g.  arrayObject ~ singleObject

 3)
 Would it really be considered going out of bounds if you were slicing an
 array of 0 elements past the last element (or before the first)?  It
 shouldn't even access the memory at the location so I think it should be
 allowed.
 e.g.  myObj[0 .. i] ~ myObj[i + 1 .. myObj.length]
 If I wanted to remove the i'th object and i + 1 was the end.

Apr 13 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
1) was because that style is considered sloppy memory management.  However I
don't see the problem if the array properly reserved enough space before you
start.  I believe that a language shouldn't prevent someone from writing
sloppy code because if it does it'll also inadvertently prevent someone from
writing truly creative genius code.  Besides performance isn't always the
top issue.  I think it'd be convenient and that convenience merits
inclusion.  If you cannot currently reserve space for an array, perhaps you
should be able to.  Or maybe D needs some kind of "array constructor helper"
object which manages an array that is in process of being built, and
maintains the reserved space etc, and frees up any extra space when the
array is finished being built.

2) I think this should be allowed for much the same reason as 1).

3)  I disagree with you guys because it would require more runtime bounds
checks to do that.  Every slice would require the extra bounds checks.  If
you want a language that won't ever give you a GPF then you are going to
have to live with the performance of Java or some other heavyweight
language.

Sean

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:b7bbul$1ctk$1 digitaldaemon.com...
 I agree with 3 certainly.

 I do recall that there were compelling reasons against 1, but cannot
 remember what (sorry).

 No opinion as yet on 2

 "Vathix" <Vathix kernel.net> wrote in message
 news:b7aqi4$12o6$1 digitaldaemon.com...
 None of this is necessary but might be good for convenience:

 1)
 Why can't I use ++, += etc on a dynamic array's .length?  Those


 are for typing less, so why can't I be lazy with this too?  :+)

 2)
 I think it would be handy to allow concating a single object to an array
 with ~.
 e.g.  arrayObject ~ singleObject

 3)
 Would it really be considered going out of bounds if you were slicing an
 array of 0 elements past the last element (or before the first)?  It
 shouldn't even access the memory at the location so I think it should be
 allowed.
 e.g.  myObj[0 .. i] ~ myObj[i + 1 .. myObj.length]
 If I wanted to remove the i'th object and i + 1 was the end.


Apr 13 2003
next sibling parent J C Calvarese <jcc-47 excite.com> writes:
Thanks for the explanations.

Sean L. Palmer wrote:
 3)  I disagree with you guys because it would require more runtime bounds
 checks to do that.  Every slice would require the extra bounds checks.  If
 you want a language that won't ever give you a GPF then you are going to
 have to live with the performance of Java or some other heavyweight
 language.

That's a certainly valid point. I understand that a certain responsibility will have to fall on the programmer in order to keep the possibility of light and fast programs around, but it seems to me that every time I do a slice, I have to check the length first. I guess you and others are writing code where they sometimes know they're not slicing out of bound, but when I need to write code to check the length every time I wonder if this is a job better handled by the compiler itself. Perhaps as my programming techniques improve, I won't need to check nearly as often. At that point I would completely agree with you. I don't want the compiler doing so many runtime checks that the code is bloated either. But if the same check is called for every time anyways, I'd prefer to let the compiler take care of it. Justin
Apr 13 2003
prev sibling parent "Vathix" <Vathix kernel.net> writes:
Since I think runtime bounds checking is only for -debug, I don't see why it
would be so hard to determine 0 elements and allow it.  As for -release, it
wouldn't even be a problem since it shouldn't access the 0 elements.
Apr 18 2003
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Vathix wrote:

 None of this is necessary but might be good for convenience:
 
 1)
 Why can't I use ++, += etc on a dynamic array's .length?  Those operators
 are for typing less, so why can't I be lazy with this too?  :+)

This didn't get described correctly. It's because of "a [a.length ++] = 4", which is an undefined expression. Like the ban on "if (a = b)", I think it's addressed at the wrong level; it should identify this easy-to-write and incorrect code in the semantic level, rather than having a catch-all that grabs many benign uses of .length.
 2)
 I think it would be handy to allow concating a single object to an array
 with ~.
 e.g.  arrayObject ~ singleObject

Yeah, the inconsistency between ~= and ~ is a flaw.
 3)
 Would it really be considered going out of bounds if you were slicing an
 array of 0 elements past the last element (or before the first)?  It
 shouldn't even access the memory at the location so I think it should be
 allowed.
 e.g.  myObj[0 .. i] ~ myObj[i + 1 .. myObj.length]
 If I wanted to remove the i'th object and i + 1 was the end.

I second a subset of this - the debug test for slicing is incorrect; it should be "start <= length" rather than "start < length". Zero-length slices of out-of-range values are just wrong, and your code right there wouldn't allow it anyway (out-of-range "i" results in negative slices).
Apr 21 2003
next sibling parent Burton Radons <loth users.sourceforge.net> writes:
Burton Radons wrote:
 I second a subset of this - the debug test for slicing is incorrect; it 
 should be "start <= length" rather than "start < length".  Zero-length 
 slices of out-of-range values are just wrong, and your code right there 
 wouldn't allow it anyway (out-of-range "i" results in negative slices).

Whoops, this is exactly what DMD does now, so I'm happy with the status quo.
Apr 21 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Am I correct in saying that the problem is that we can't know if postfix++
happens before or after the assignment, which depends on the ++ executing
before the assignment, or it'll store into invalid memory?

// a [a.length ++] = 4;  // bad

This seems to be a sort of reverse argument for defining when postfix ++
happens better.  Instead of just "before the next sequence point" define it
to be "before any expression which uses the result of the x++ is evaluated".
At least for arguments which aren't simple integers, such as a.length, where
incrementing has side effects.

C is so imprecise.  D doesn't have to be.  The result:  more portable code
for everybody.

Sean

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:b82ja0$hdf$1 digitaldaemon.com...
 Vathix wrote:

 None of this is necessary but might be good for convenience:

 1)
 Why can't I use ++, += etc on a dynamic array's .length?  Those


 are for typing less, so why can't I be lazy with this too?  :+)

This didn't get described correctly. It's because of "a [a.length ++] = 4", which is an undefined expression. Like the ban on "if (a = b)", I think it's addressed at the wrong level; it should identify this easy-to-write and incorrect code in the semantic level, rather than having a catch-all that grabs many benign uses of .length.

Apr 22 2003