On Wednesday, 5 May 2010 at 22:42:19 UTC, Robert Clipsham wrote:
.ptr is only available for arrays. Internally, (dynamic) arrays
in D look like this:
struct {
size_t length;
T* ptr;
}
Thanks for this!! (I know this topic is old).
But it made me understand why I found that this is
On 06/05/10 00:11, bearophile wrote:
Robert Clipsham:
.ptr is only available for arrays.
And arr.ptr returns the pointer to the start of the memory that
contains the array data. While&arr is the pointer to the struct that
contains the pointer and the length.
Thanks for adding this, I probab
On 05/05/10 23:58, strtr wrote:
But wouldn't this (property sugar?) be nice?
I don't like it, I can see why you would though :)
int myInt = 6; int* ptrToMyInt = myInt.ptr; int myInt2 =
ptrToMyInt.deref; // you probably didn't mean *myInt ;)
I guess this is what I get for writing code quickl
Robert Clipsham:
> .ptr is only available for arrays.
And arr.ptr returns the pointer to the start of the memory that contains the
array data. While &arr is the pointer to the struct that contains the pointer
and the length.
> As for .value and .deref, these won't be implemented, you'll
> ha
Robert Clipsham Wrote:
> On 05/05/10 23:20, strtr wrote:
> > I keep on expecting .ptr to work on all types. What keeps this from being
> > the case?
> > And how about having a .value(.deref) property for known pointers?
> >
> > I feel a lot less comfortable with using stars and ampersands, becaus
On 05/05/10 23:20, strtr wrote:
I keep on expecting .ptr to work on all types. What keeps this from being the
case?
And how about having a .value(.deref) property for known pointers?
I feel a lot less comfortable with using stars and ampersands, because I keep
on forgetting which one does what
I keep on expecting .ptr to work on all types. What keeps this from being the
case?
And how about having a .value(.deref) property for known pointers?
I feel a lot less comfortable with using stars and ampersands, because I keep
on forgetting which one does what.
