On Mon, 29 Jul 2002 22:10:22 +0000 (UTC) Rex Couture <Rex_member@pathlink.com> wrote:

> Please allow me one last impudent suggestion.  If it's dangerous and not
needed
> except for comptibility (or maybe for some rare, unforseen circumstance), why not forbid pointer arithmetic by default?  It could be allowed with a switch
for
> compatibility.

I wouldn't ming having something like that. Some sort of a subset of D, with no pointer arithmetic, available from the compiler by request.

> I'm also a little concerned that subscript range checking is always turned off in the final compilation, whether this is really needed or not.  I certainly
am
> capable of leaving undetected subscript range errors in my programs.

I think there should be a separate switch and/or language statement to control subscript range checking. Having it on in debug builds, and off in release builds seems suitable for most coders, but just in case you also want it in release build, a switch should be there...

On Mon, 29 Jul 2002 16:50:58 -0700 "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote:

>    After all, what are pointers good for?
> 
> 1- Referencing polymorphic classes.

These are covered by object references in D, which don't support arithmetic.

> 2- Referencing elements of an array.

You can almost always cast a pointer to a dynamic array, which will be bounds-checked.

Hi,

"Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:ai4k20$10vp$1@digitaldaemon.com...
> "Rex Couture" <Rex_member@pathlink.com> wrote in message news:ai4ege$pin$1@digitaldaemon.com...
>
> 3- This is just a cast. It doesn't need arithmetic, as long as raw memory
is
> just represented by an integer.
>
>    The end result is that the only case really needed in D is number 3.
And
> all of it can be done easily by using integers for addresses, and
converting
> to/from typed pointers, so pointer arithmetic is definitely not needed.

Making code depend on pointers fitting into integers will cause problems with portability. For instance, AS/400 has very large pointers that will not fit into any integral type. Another example is DOS' segmented memory model where a pointer is 32 bit and an int is 16 bit wide. DOS might not be an issue anymore, but we might very well see a segmented model again - next time with 64 bit pointers and 32 bit integers, I suspect. Your solution to the problem is IMHO bad practice.

Regards,
Martin M. Pedersen

"Martin M. Pedersen" wrote:

> Making code depend on pointers fitting into integers will cause problems with portability. For instance, AS/400 has very large pointers that will not fit into any integral type. Another example is DOS' segmented memory model where a pointer is 32 bit and an int is 16 bit wide. DOS might not be an issue anymore, but we might very well see a segmented model again - next time with 64 bit pointers and 32 bit integers, I suspect. Your solution to the problem is IMHO bad practice.

Yeah, when you absolutely need pointer arithmetic, all other options are just hacks.  However, we should try to push the language to a point where 99% of the programs will never need it...

I sincerely hope we've learned our lesson from the segmented memory nightmare...let's not do that again :(

--
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))) ]

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374676562744097@news.digitalmars.com...

> On Mon, 29 Jul 2002 16:50:58 -0700 "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote:
>
> >    After all, what are pointers good for?
> >
> > 1- Referencing polymorphic classes.
>
> These are covered by object references in D, which don't support
arithmetic.

   My point exactly. Keep reading ;-)

> > 2- Referencing elements of an array.
>
> You can almost always cast a pointer to a dynamic array, which will be bounds-checked.

   That sounds like another reasonably good option.

Salutaciones,
                         JCAB

"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:ai66ul$2rq1$1@digitaldaemon.com...

> "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:ai4k20$10vp$1@digitaldaemon.com...
>
> > 3- This is just a cast. It doesn't need arithmetic, as long as raw
memory
> > is just represented by an integer.
>
> Making code depend on pointers fitting into integers will cause problems with portability. For instance, AS/400 has very large pointers that will
not
> fit into any integral type. Another example is DOS' segmented memory model where a pointer is 32 bit and an int is 16 bit wide. DOS might not be an issue anymore, but we might very well see a segmented model again - next time with 64 bit pointers and 32 bit integers, I suspect. Your solution to the problem is IMHO bad practice.

   On the contrary. I wasn't suggesting to make pointers fit any specific
integral type. I was suggesting creating a new integral type that would be
used to represent addresses in raw memory. I'd assume some operations would
be pretty much platform-specific, like separating the segment and offset
parts of it and such, but still it should support the basic arithmetic
operations. And making part of its interface platform-specific doesn't sound
like such a bad idea, as this type of stuff would only be needed for system
work, which is inherently non-portable at its core.

   So, this would be different from C/C++ pointers in general in that this
would be just raw addresses, kind of like a char*. It would not be like a
void*, because it would allow arithmetic. But it would be something similar
at its core.

Salutaciones,
                         JCAB

On Tue, 30 Jul 2002 12:23:18 -0700 "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote:

>    So, this would be different from C/C++ pointers in general in that this
> would be just raw addresses, kind of like a char*. It would not be like a
> void*, because it would allow arithmetic. But it would be something similar
> at its core.

Then maybe just allow pointer arithmetic on void* as if it was char*?
I remember someone suggested it before, and it doesn't sound like
a bad idea to me.

Pavel Minayev wrote:

> On Tue, 30 Jul 2002 12:23:18 -0700 "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote:
> 
> 
>>   So, this would be different from C/C++ pointers in general in that this
>>would be just raw addresses, kind of like a char*. It would not be like a
>>void*, because it would allow arithmetic. But it would be something similar
>>at its core.
>>
> 
> Then maybe just allow pointer arithmetic on void* as if it was char*?
> I remember someone suggested it before, and it doesn't sound like
> a bad idea to me.

It's been in a long time.  You can do it in GCC too, and maybe C99.

"Rex Couture" <Rex_member@pathlink.com> wrote in message news:ahsg4p$f0k$1@digitaldaemon.com...
> In article <ahsbn4$9ms$1@digitaldaemon.com>, OddesE says...
> >For the most parts, you don't need pointers. You can use one-dimensional dynamic arrays and object references for most occasions were you might have used pointers in C/C++.
>
> That's good news.  I think object references are really pointers by
another
> name, but they do seem safe.

Pointers which the compiler has complete control over, so it can do more to ensure they're used safely.  References are pointers minus most of the sharp nasty dangerous parts.

Those of you who are advocating using dynamic arrays instead of pointer arithmetic:   Yes that's a step in the right direction (at least the compiler can verify the validity of the array itself and bounds check the index) but it doesn't prevent bad indices from occurring.  A lot of pointer arithmetic is of the iteration form;   p++ or p+=4  instead of the more risky p2 = p + x;

Adding the iterator concept to the language would eliminate the need for a whole class of potential uses for pointer arithmetic, and also bypass its close relative, the indexed array.  Indexing is (potentially) slower performance than iteration anyway.  When in any doubt whatsoever about the optimization ability of the compiler, it's better to write for (T* i = &array[array.size]; --i >= &array[0]; ) *i = 0;  than for (int i = array.size; --i >=0; ) array[i] = 0; just because the former is effectively a pre-optimized form of the latter.  An even better optimizer may replace the whole loop with a block fill (memset).

Just as iteration isn't a good substitute for indexing, indexing isn't a good substitute for iteration.  True native language iteration allows elimination of many range checks and safety holes.

Sean

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ai866v$4r0$1@digitaldaemon.com...
> "Rex Couture" <Rex_member@pathlink.com> wrote in message news:ahsg4p$f0k$1@digitaldaemon.com...
> > In article <ahsbn4$9ms$1@digitaldaemon.com>, OddesE says...
> > >For the most parts, you don't need pointers. You can use one-dimensional dynamic arrays and object references for most occasions were you might have used pointers in C/C++.
> >
> > That's good news.  I think object references are really pointers by
> another
> > name, but they do seem safe.
>
> Pointers which the compiler has complete control over, so it can do more
to
> ensure they're used safely.  References are pointers minus most of the
sharp
> nasty dangerous parts.
>
> Those of you who are advocating using dynamic arrays instead of pointer arithmetic:   Yes that's a step in the right direction (at least the compiler can verify the validity of the array itself and bounds check the index) but it doesn't prevent bad indices from occurring.  A lot of
pointer
> arithmetic is of the iteration form;   p++ or p+=4  instead of the more risky p2 = p + x;
>
> Adding the iterator concept to the language would eliminate the need for a whole class of potential uses for pointer arithmetic, and also bypass its close relative, the indexed array.  Indexing is (potentially) slower performance than iteration anyway.  When in any doubt whatsoever about the optimization ability of the compiler, it's better to write for (T* i = &array[array.size]; --i >= &array[0]; ) *i = 0;  than for (int i = array.size; --i >=0; ) array[i] = 0; just because the former is
effectively
> a pre-optimized form of the latter.  An even better optimizer may replace the whole loop with a block fill (memset).

--Of course memsets can be faster then iteration, but memsets are considered to be a slow block copying techniqiue (when compared to an ASM version), why is this so? (I guess it's implementation dependent.)

> Just as iteration isn't a good substitute for indexing, indexing isn't a good substitute for iteration.  True native language iteration allows elimination of many range checks and safety holes.
>
> Sean
>

I agree.