Hiding class pointers -- was it a good idea?
Bill Baxter
dnewsgroup at billbaxter.com
Thu Aug 16 10:26:01 PDT 2007
Jason House wrote:
> Bill Baxter wrote:
>> Jason House wrote:
>>> I was thinking recently of an interesting syntax twist... Always
>>> require & when trying to get to an address, and use the raw variable
>>> name and "." to refer to whatever is pointed to. Obtaining an
>>> address would require &.
>>>
>>> It's an interesting change, but would likely be too confusing to
>>> switch over. Somehow I bet even suggesting the idea will mark me as
>>> a crack pot :)
>>
>> Well realistically none of this is likely to change anyway, so you're
>> free to suggest anything you want. :-)
>> I was thinking about something like that as well, though. But
>> couldn't really think how to make it useful.
>>
>> My thinking was that in D we have classes sort of "shifted" by one
>> from structs
>>
>> pointer-to-pointer pointer value
>> struct &(&p) &p p
>> struct* &p p *p
>> class &p p N/A
>>
>> So instead of that make structs default to pointers too, to shift
>> everything back to be the same:
>>
>> pointer-to-pointer pointer value
>> struct# &(&p) &p p
>> struct &p p *p
>> class &p p N/A
>
> I was thinking of something more consistent.
>
> pointer-to-pointer pointer value
> struct N/A &p p
> struct* &&p &p p
> class &&p &p p
> T ??? &p p
Oh, I see. So you mean that no matter what, the compiler would figure
out what dereferencing was necessary, and you always have to explicitly
say whether you want a pointer or not. Interesting.
So pointer math becomes pretty tedious for one. Maybe that's ok.
And then what happens when you're given some T (which could be pointer
to pointer to int, say) and you want dereference it one level further?
And what about aliases? If I have
alias int* intp;
alias int** intpp;
intp x;
Then x can simultaneously be described as int**, intp*, or intpp.
But why is struct pointer-to-pointer N/A. Shouldn't the N/A be under
'value' for class?
--bb
More information about the Digitalmars-d
mailing list