www.digitalmars.com         C & C++   DMDScript  

D - Let's not allow [] with pointers

reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Since we now have arrays as native parts of the type system, let's 
disallow the use of the [] operator on pointers.  If somebody wants to 
use the pointer as the base of an array and index off of it, then let 
them use pointer arithmetic:
    char *ptr;
    char  val = *(ptr+143);

Also, when you have a pointer-to-array, you should be required to 
dereference the pointer manually...don't let [] go "through" the pointer 
to the array underneath.

These two changes will help prevent a lot of bugs, at least for me.  In 
previous posts I've mentioned that I sometimes have arrays of pointers. 
  But I can never remember the syntax...should it be
    type*[] var;
or
    type[]* var;

And I have to look it up every time.  But if [] didn't work on pointers, 
(AND [] didn't automatically go "through" the pointer), then if I used 
the wrong syntax and then tried to access my array:
    var[x]
then I would get a syntax error "[] not valid on pointers."
Sep 23 2002
parent reply "Walter" <walter digitalmars.com> writes:
You make a good point, but I'm not sure people would be ready to accept
losing that bit of syntactic sugar.

"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D8F6893.6030204 deming-os.org...

 Since we now have arrays as native parts of the type system, let's
 disallow the use of the [] operator on pointers.  If somebody wants to
 use the pointer as the base of an array and index off of it, then let
 them use pointer arithmetic:
     char *ptr;
     char  val = *(ptr+143);

 Also, when you have a pointer-to-array, you should be required to
 dereference the pointer manually...don't let [] go "through" the pointer
 to the array underneath.

 These two changes will help prevent a lot of bugs, at least for me.  In
 previous posts I've mentioned that I sometimes have arrays of pointers.
   But I can never remember the syntax...should it be
     type*[] var;
 or
     type[]* var;

 And I have to look it up every time.  But if [] didn't work on pointers,
 (AND [] didn't automatically go "through" the pointer), then if I used
 the wrong syntax and then tried to access my array:
     var[x]
 then I would get a syntax error "[] not valid on pointers."
Sep 25 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I'm just not convinced that there is any reason to use it anymore.  If you
have an array, you should be using an array, not a pointer.  If you need
low-level pointer arithmetic (you're doing systems programming, for example),
then you should use pointer arithmetic.  Under what kinds of circumstances
would a pointer-as-array make sense?  Examples, anybody?

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Sep 26 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D9307F3.67DB5AC5 deming-os.org...

 I'm just not convinced that there is any reason to use it anymore.  If you
 have an array, you should be using an array, not a pointer.  If you need
 low-level pointer arithmetic (you're doing systems programming, for


example),

 then you should use pointer arithmetic.  Under what kinds of circumstances
 would a pointer-as-array make sense?  Examples, anybody?


If you're interfacing to C code in D, such as manipulating 0 terminated
strings.
Sep 26 2002
parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D9307F3.67DB5AC5 deming-os.org...
 

I'm just not convinced that there is any reason to use it anymore.  If you
have an array, you should be using an array, not a pointer.  If you need
low-level pointer arithmetic (you're doing systems programming, for


 
 example),
 

then you should use pointer arithmetic.  Under what kinds of circumstances
would a pointer-as-array make sense?  Examples, anybody?


 
 
 If you're interfacing to C code in D, such as manipulating 0 terminated
 strings.


Right, I've been there with my current project.  So, currently we need 
the [] slicing syntax to generate an array from a pointer.  Maybe there 
should be some other syntax?  Maybe a cast syntax?

     char[] toString(char *ptr)
     {
       return cast(char[strlen(ptr)])ptr;
     }
Sep 26 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D9347FC.4020805 deming-os.org...

 Right, I've been there with my current project.  So, currently we need
 the [] slicing syntax to generate an array from a pointer.  Maybe there
 should be some other syntax?  Maybe a cast syntax?

      char[] toString(char *ptr)
      {
        return cast(char[strlen(ptr)])ptr;
      }


To generate an array from a pointer, use:

    ptr[0..strlen(ptr)]
Sep 27 2002
parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D9347FC.4020805 deming-os.org...
 

Right, I've been there with my current project.  So, currently we need
the [] slicing syntax to generate an array from a pointer.  Maybe there
should be some other syntax?  Maybe a cast syntax?

     char[] toString(char *ptr)
     {
       return cast(char[strlen(ptr)])ptr;
     }


 
 
 To generate an array from a pointer, use:
 
     ptr[0..strlen(ptr)]
 
 


Right.  What I was saying is that we could (probably) get away with [] 
on pointers if we had an alternate syntax (or an intrinsic function) 
that would create an array from a pointer.
Sep 27 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D949441.8050005 deming-os.org...

 Walter wrote:

 "Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D9347FC.4020805 deming-os.org...


Right, I've been there with my current project.  So, currently we need
the [] slicing syntax to generate an array from a pointer.  Maybe there
should be some other syntax?  Maybe a cast syntax?

     char[] toString(char *ptr)
     {
       return cast(char[strlen(ptr)])ptr;
     }



 To generate an array from a pointer, use:

     ptr[0..strlen(ptr)]


 Right.  What I was saying is that we could (probably) get away with []
 on pointers if we had an alternate syntax (or an intrinsic function)
 that would create an array from a pointer.


I don't understand why the existing syntax to convert a ptr to an array is
not suitable.
Sep 28 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
It's a very good syntax, for that purpose.

The problem is, that I have already had some bugs where I used [] on pointers,
thinking I was accessing an array.  When you have a pointer-to-array or
array-of-pointers, it can get problematic.  If we didn't allow [] on pointers,
it would immediately show up those sorts of bugs.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Sep 28 2002
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Russ Lewis wrote:

 It's a very good syntax, for that purpose.
 
 The problem is, that I have already had some bugs where I used [] on pointers,
 thinking I was accessing an array.  When you have a pointer-to-array or
 array-of-pointers, it can get problematic.  If we didn't allow [] on pointers,
 it would immediately show up those sorts of bugs.
 


If you're getting trouble it's not yet a reason to get rid of the 
feature in the language, unless it is misused very often or without 
purpose. I guess that if the structs and such are kept, it also should be.

The example: I want a pretty large array of a size which is not 
constant. I allocate a dynamic array of the requiered raw length, 
rows*colums. Then i set a pointer to pointer aray denoting rows, and 
initialize it. The result: i can access it with 'array[y][x]'. It 
becomes obvious that it should be that instead of [x][y] after some 
thinking, but it was a source of a strange behaviour in my early C code. 
Why the heck are my sprites not rectangular? Because i was drawing 
screen columns thinking of them as of rows, and since it is not square...

My point is, there better be a syntax like array[x,y] which would 
translate into array[y][x]. And multi-dimensional contunuous arrays, 
with their current dimensions written in their header and used to 
calculate pointers. Hm. I'm still not sure what is faster for huge 2D 
arays of unknown size: access through indirection, or access through 
multiplication? Second can obviously be optimised out by the compiler, 
by bringing it out of the loops and such. Hm.

Another thing is, for example, i define a class for a 2D array. I 
overload the [] oerator, and make it return *something* containing a 
row, which has to be another class, so that [] can be overloaded on it, 
right?

It would be good, if array[x,y,z] gets implemented, that it can be 
overloaded all at once, to make it all easier. The overloading function 
would then get, for example, an array of indices.

-i.


 --
 The Villagers are Online! http://villagersonline.com
 
 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]
Jan 17 2003
parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
I say we keep array indexing on pointers and add real rectangular arrays
like you say.

Rectangular (or multidimensional box) dynamic arrays would be a little pain
to implement, but static arrays (dimensions known at compile time) would be
easy.

Without that, you end up needing little helper or proxy classes for your
rows.

Sean


"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:b09a6e$30j4$1 digitaldaemon.com...

 Russ Lewis wrote:

 It's a very good syntax, for that purpose.

 The problem is, that I have already had some bugs where I used [] on




pointers,

 thinking I was accessing an array.  When you have a pointer-to-array or
 array-of-pointers, it can get problematic.  If we didn't allow [] on




pointers,

 it would immediately show up those sorts of bugs.


 If you're getting trouble it's not yet a reason to get rid of the
 feature in the language, unless it is misused very often or without
 purpose. I guess that if the structs and such are kept, it also should be.

 The example: I want a pretty large array of a size which is not
 constant. I allocate a dynamic array of the requiered raw length,
 rows*colums. Then i set a pointer to pointer aray denoting rows, and
 initialize it. The result: i can access it with 'array[y][x]'. It
 becomes obvious that it should be that instead of [x][y] after some
 thinking, but it was a source of a strange behaviour in my early C code.
 Why the heck are my sprites not rectangular? Because i was drawing
 screen columns thinking of them as of rows, and since it is not square...

 My point is, there better be a syntax like array[x,y] which would
 translate into array[y][x]. And multi-dimensional contunuous arrays,
 with their current dimensions written in their header and used to
 calculate pointers. Hm. I'm still not sure what is faster for huge 2D
 arays of unknown size: access through indirection, or access through
 multiplication? Second can obviously be optimised out by the compiler,
 by bringing it out of the loops and such. Hm.

 Another thing is, for example, i define a class for a 2D array. I
 overload the [] oerator, and make it return *something* containing a
 row, which has to be another class, so that [] can be overloaded on it,
 right?

 It would be good, if array[x,y,z] gets implemented, that it can be
 overloaded all at once, to make it all easier. The overloading function
 would then get, for example, an array of indices.

 -i.


 --
 The Villagers are Online! http://villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]
Jan 17 2003