July 31, 2002
Sean L. Palmer wrote:
> 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;

What about
    char[] a;
    ...
    a = a[1..a.length];

Which is, effectively, pointer arithmetic (with bounds checking, if that is turned on)?

You could even create a new property called "next" to do it for you:
    "<array>.next" is defined as "<array>[1..<array>.length]"

And then your array reference works with the same semantics as a (non-reversible) iterator :)

July 31, 2002
Russell Lewis wrote:

> Sean L. Palmer wrote:
> 
>> 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;
> 
> 
> What about
>     char[] a;
>     ...
>     a = a[1..a.length];

Walter has agreed that:

    a = a[1..];

Is a good idea, and it's already in my port of DMD.  So a next property isn't necessary, and IMO it wouldn't be a good name anyway, as it's already a massively overloaded word.

August 01, 2002
"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374680226337732@news.digitalmars.com...
> 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 may have been me.

Did you mean?
> Then maybe just allow pointer arithmetic ONLY on void* ...?
(I'm not syntax checking your gramma. I'm just wondering about the
semantics(meaning)?)

I'm wondering how do you get the datatype from a void* in D and also in C++?

--PS

The two reasons why I don't use D all that much are:

1) No MFC or equivalent OO-control based classes.
2) No editor specific (or as useful) for D as MVS has for Visual C++.

I'm sure this will probably change in the future. And perhaps I'll be able to help with that (but not at the moment, I've got a hundred assignments, and an a continual stackoverflow ;) ).


August 01, 2002
"anderson" <anderson@firestar.com.au> wrote in message news:aibcpj$9ii$1@digitaldaemon.com...
>
> --PS
>
> The two reasons why I don't use D all that much are:
>
> 1) No MFC or equivalent OO-control based classes.
> 2) No editor specific (or as useful) for D as MVS has for Visual C++.
>
> I'm sure this will probably change in the future. And perhaps I'll be able to help with that (but not at the moment, I've got a hundred assignments, and an a continual stackoverflow ;) ).
>

--I just thought of something. It's a rhetorical thing for me. If I was to add MFC support I'd like a good editor, but to build the editor in D I'd need MFC. (Of course the editor could be developed in C++ (or in D with win32), and MFC could be added without an editor.)


August 01, 2002
On Thu, 1 Aug 2002 21:29:10 +0800 "anderson" <anderson@firestar.com.au> wrote:

> Did you mean?
>> Then maybe just allow pointer arithmetic ONLY on void* ...?
> (I'm not syntax checking your gramma. I'm just wondering about the
> semantics(meaning)?)

Yes, exactly.

> I'm wondering how do you get the datatype from a void* in D and also in C++?

What do you mean, "get the datatype"? You just cast it to whatever it
actually is...

> The two reasons why I don't use D all that much are:
> 
> 1) No MFC or equivalent OO-control based classes.

I'm waiting for the next DMD alpha to continue the development of WinD. In fact, as soon as I write class Bitmap, I'll release the first alpha. But, oh well, it's quite different from MFC. =)

> 2) No editor specific (or as useful) for D as MVS has for Visual C++.

The bad thing is, M$ doesn't give the SDK for MVS plugins for free.
For now, I've got stick with FAR + Colorer plugin, and wrote a
hilighting scheme for D. Works fine for me. But of course, an
IDE with integrated debugger, project manager, class browser, code
completion etc would be much better. =)
August 02, 2002
"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374700113674769@news.digitalmars.com...
> On Thu, 1 Aug 2002 21:29:10 +0800 "anderson" <anderson@firestar.com.au>
wrote:
>
> > I'm wondering how do you get the datatype from a void* in D and also in
C++?
>
> What do you mean, "get the datatype"? You just cast it to whatever it actually is...

Say you cast a void * to something else how do you get the previous datatype? I think it's impossible at the moment (although I'm not sure) without extra details. You need to data type to know the size of each memory component in the array at least. Perhaps there should be a special type of general array or perhaps (for the sake of learnability) something can be added to void * that is worked out at compile time (ie like a template).


August 02, 2002
Whoops,

Say you cast something to a void * how do you get the previous datatype? I
think it's impossible at the moment (although I'm not sure) without extra
details. You need to data type to know the size of each memory component
in the array at least. Perhaps there should be a special type of general
array or perhaps (for the sake of learnability) something can be added
to void * that is worked out at compile time (ie like a template).



August 02, 2002
anderson wrote:

> "Pavel Minayev" <evilone@omen.ru> wrote in message
> news:CFN374700113674769@news.digitalmars.com...
> 
>>On Thu, 1 Aug 2002 21:29:10 +0800 "anderson" <anderson@firestar.com.au>
>>
> wrote:
> 
>>>I'm wondering how do you get the datatype from a void* in D and also in
>>>
> C++?
> 
>>What do you mean, "get the datatype"? You just cast it to whatever it
>>actually is...
>>
> 
> Say you cast a void * to something else how do you get the previous
> datatype? I think it's impossible at the moment (although I'm not sure)
> without extra details. You need to data type to know the size of each memory
> component in the array at least. Perhaps there should be a special type of
> general array or perhaps (for the sake of learnability) something can be
> added to void * that is worked out at compile time (ie like a template).

You should be able to eventually do (using my generics syntax):

    struct Pointer
    {
        TypeInfo type;
        void *data;

        this ($type *data)
        {
            this.type = $type.next;
            this.data = data;
        }
    }

    int x;
    Pointer f = Pointer (&x);

    printf ("%s %d\n", f.type.kind, f.type.tsize);

Which will print "int 4".

August 02, 2002
"Rex Couture" <Rex_member@pathlink.com> wrote in message news:ai4ege$pin$1@digitaldaemon.com...
> 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 see Russ Lewis has just posted that suggestion too.  I
think it's a great
> idea.  Otherwise, a lot of people will probably use old ways out of habit.

One of D's goals is to allow people to continue using their old style so they can rapidly get up to speed using D. Over time, I expect they'll be seduced by the D way of doing things, and their coding style will naturally shift. I know this is how C++ became so popular. Eliminating pointers completely will significantly raise the barrier to entry to D, enough I feel to permanently marginalize it.

> 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.

It would be your choice to leave that on or off in your release code.


August 02, 2002
On Fri, 2 Aug 2002 13:09:41 +0800 "anderson" <anderson@firestar.com.au> wrote:

> 
> Whoops,
> 
> Say you cast something to a void * how do you get the previous datatype? I
> think it's impossible at the moment (although I'm not sure) without extra
> details. You need to data type to know the size of each memory component
> in the array at least. Perhaps there should be a special type of general
> array or perhaps (for the sake of learnability) something can be added
> to void * that is worked out at compile time (ie like a template).

Yes, it is impossible now.

Practically, what you're suggesting now is some kind of variant data type, only it doesn't store the data, but the pointer to it.