On 10/31/21 9:54 AM, Ali Çehreli wrote:
Or other smart ways where I store the pointer in two parts as
page+offset?
Ok, that was silly. There would be no reference to the GC memory if I
chopped off a pointer. :/
Ali
On Sun, Oct 31, 2021 at 09:54:23AM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
> On 10/31/21 9:49 AM, H. S. Teoh wrote:
>
> > The current spec explicitly states that masking pointers this way is UB.
>
> Ok. :) What about unions?
>
> union U {
> ulong u;
> void* p;
> }
>
> Can the GC
On 10/31/21 9:49 AM, H. S. Teoh wrote:
> The current spec explicitly states that masking pointers this way is UB.
Ok. :) What about unions?
union U {
ulong u;
void* p;
}
Can the GC deal with that?
Or other smart ways where I store the pointer in two parts as
page+offset? (Perhaps that's
On Sat, Oct 30, 2021 at 07:56:35PM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
> On 10/30/21 3:47 PM, Elronnd wrote:
>
> > If the GC were moving, it would also have to move the pointers you
> > took to AA elements.
>
> I doubt D's GC can ever change pointer values because the values may
>
On Sunday, 31 October 2021 at 02:56:35 UTC, Ali Çehreli wrote:
On 10/30/21 3:47 PM, Elronnd wrote:
> If the GC were moving, it would also have to move the
pointers you took
> to AA elements.
I doubt D's GC can ever change pointer values because the
values may be hiding inside e.g. ulong
On 10/30/21 3:47 PM, Elronnd wrote:
> If the GC were moving, it would also have to move the pointers you took
> to AA elements.
I doubt D's GC can ever change pointer values because the values may be
hiding inside e.g. ulong variables. And we would definitely not want the
GC to change ulong
On Saturday, 30 October 2021 at 22:47:57 UTC, Elronnd wrote:
If the GC were moving, it would also have to move the pointers
you took to AA elements. You would never get stale pointers in
any event.
Who said you would?..
On Saturday, 30 October 2021 at 21:20:15 UTC, Stanislav Blinov
wrote:
On Saturday, 30 October 2021 at 20:19:58 UTC, Imperatorn wrote:
https://dlang.org/spec/garbage.html#pointers_and_gc
What test could be written to verify the behaviour?
Assuming the GC was moving?
If the GC were moving,
On 10/30/21 2:31 PM, Andrey Zherikov wrote:
On Saturday, 30 October 2021 at 00:52:23 UTC, Imperatorn wrote:
On Saturday, 30 October 2021 at 00:49:04 UTC, Stanislav Blinov wrote:
On Friday, 29 October 2021 at 21:00:48 UTC, Steven Schveighoffer wrote:
This is incorrect, the buckets are each
On Saturday, 30 October 2021 at 20:19:58 UTC, Imperatorn wrote:
https://dlang.org/spec/garbage.html#pointers_and_gc
What test could be written to verify the behaviour?
Assuming the GC was moving?
You'd need a loop allocating different sizes, storing the
addresses somewhere the GC won't
On Saturday, 30 October 2021 at 20:05:17 UTC, Stanislav Blinov
wrote:
On Saturday, 30 October 2021 at 18:31:16 UTC, Andrey Zherikov
wrote:
I did small test and it printed the same values three times so
even rehash doesn't change the address of the value:
So it seems pretty safe to store a
On Saturday, 30 October 2021 at 18:31:16 UTC, Andrey Zherikov
wrote:
I did small test and it printed the same values three times so
even rehash doesn't change the address of the value:
So it seems pretty safe to store a pointer to a value in AA.
And I agree that this should definitely be
On Saturday, 30 October 2021 at 00:52:23 UTC, Imperatorn wrote:
On Saturday, 30 October 2021 at 00:49:04 UTC, Stanislav Blinov
wrote:
On Friday, 29 October 2021 at 21:00:48 UTC, Steven
Schveighoffer wrote:
This is incorrect, the buckets are each heap allocated. Just
the array of bucket
On Saturday, 30 October 2021 at 17:45:57 UTC, Steven
Schveighoffer wrote:
You said "deallocating unreferenced elements". I thought you
meant elements unreferenced by the AA.
Yup, I misunderstood you :)
What I mean is, the AA isn't going to change implementations
where it now deallocates
On 10/30/21 1:38 PM, Stanislav Blinov wrote:
On Saturday, 30 October 2021 at 16:55:03 UTC, Steven Schveighoffer wrote:
auto v = k in aa;
aa.remove(k);
How can the GC/compiler work out that there is still a reference?
??? The same way it does for all other references.
I think either you
On Saturday, 30 October 2021 at 16:55:03 UTC, Steven
Schveighoffer wrote:
auto v = k in aa;
aa.remove(k);
How can the GC/compiler work out that there is still a
reference?
??? The same way it does for all other references.
I think either you misunderstood me, or I misunderstood you.
On 10/30/21 10:51 AM, Stanislav Blinov wrote:
On Saturday, 30 October 2021 at 11:59:15 UTC, Steven Schveighoffer wrote:
It should be documented. There isn't a valid way to remove these
requirements, even if they are currently just an implementation detail
-- code already depends on these
On Saturday, 30 October 2021 at 11:59:15 UTC, Steven
Schveighoffer wrote:
It should be documented. There isn't a valid way to remove
these requirements, even if they are currently just an
implementation detail -- code already depends on these
properties.
And D is a GC-based language,
On 10/29/21 8:49 PM, Stanislav Blinov wrote:
On Friday, 29 October 2021 at 21:00:48 UTC, Steven Schveighoffer wrote:
This is incorrect, the buckets are each heap allocated. Just the array
of bucket pointers would change.
In addition, AAs do not deallocate the key/value pairs ever. You are
On Saturday, 30 October 2021 at 00:49:04 UTC, Stanislav Blinov
wrote:
On Friday, 29 October 2021 at 21:00:48 UTC, Steven
Schveighoffer wrote:
This is incorrect, the buckets are each heap allocated. Just
the array of bucket pointers would change.
In addition, AAs do not deallocate the
On Friday, 29 October 2021 at 21:00:48 UTC, Steven Schveighoffer
wrote:
This is incorrect, the buckets are each heap allocated. Just
the array of bucket pointers would change.
In addition, AAs do not deallocate the key/value pairs ever.
You are safe to obtain a pointer to a value and it
On 10/29/21 1:58 PM, Paul Backus wrote:
On Friday, 29 October 2021 at 17:40:38 UTC, Andrey Zherikov wrote:
I want to have a pointer to a value in an associative array. Does AA
guarantee that the value will remain at the same address all the time
unless I remove the corresponding key? I
On Friday, 29 October 2021 at 17:58:24 UTC, Paul Backus wrote:
No, the AA does not guarantee that the value will remain in the
same location. Inserting or removing *any* keys could cause the
AA to resize, which may change the locations of all of its
values.
However, you do not have to worry
On Fri, Oct 29, 2021 at 05:58:24PM +, Paul Backus via Digitalmars-d-learn
wrote:
> On Friday, 29 October 2021 at 17:40:38 UTC, Andrey Zherikov wrote:
> > I want to have a pointer to a value in an associative array. Does AA
> > guarantee that the value will remain at the same address all the
>
On Friday, 29 October 2021 at 17:40:38 UTC, Andrey Zherikov wrote:
I want to have a pointer to a value in an associative array.
Does AA guarantee that the value will remain at the same
address all the time unless I remove the corresponding key? I
couldn't find any guarantees similar to C++
I want to have a pointer to a value in an associative array. Does
AA guarantee that the value will remain at the same address all
the time unless I remove the corresponding key? I couldn't find
any guarantees similar to C++ iterator invalidation in D Language
Reference.
26 matches
Mail list logo
