On 5/4/14, Marco Leise via Digitalmars-d digitalmars-d@puremagic.com wrote:
Would that affect all arrays, only arrays containing structs
or only affect arrays containing structs with dtors?
printf(hello\n.ptr);
should still work after all.
That should work independent of what the GC
Am Wed, 30 Apr 2014 08:33:25 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
I'm mulling over a couple of design considerations for allocators, and
was thinking of the following restriction:
1. No out-of-bounds tricks and no pointer arithmetic. Consider:
int[] a = new
On Wed, 30 Apr 2014 20:08:03 -0400
Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Wed, 30 Apr 2014 14:15:03 -0400, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
IIRC they do, it's only arrays of such that doesn't. Anyhow having
such a dangerous construct
I'm mulling over a couple of design considerations for allocators, and
was thinking of the following restriction:
1. No out-of-bounds tricks and no pointer arithmetic. Consider:
int[] a = new int[1000];
a = a[250 .. 750];
int* p = a[500 .. $].ptr;
Subsequently the GC should be within its
On 4/30/14, 8:33 AM, Andrei Alexandrescu wrote:
int[] a = new int[1000];
a = a[250 .. 750];
int* p = a[500 .. $].ptr;
Here I meant:
int[] a = new int[1000];
int* p = a[500 .. $].ptr;
a = a[250 .. 750];
Andrei
On Wednesday, 30 April 2014 at 15:33:29 UTC, Andrei Alexandrescu
wrote:
4. Currently, struct objects created with new do NOT have their
destructors called during collection. I think this may
continue, meaning that structs created with new are somewhat
low-level and are meant to be destroyed
Andrei Alexandrescu:
Subsequently the GC should be within its rights to deallocate
any memory within the first and last 250 integers allocated,
even though in theory the user may get to them by using pointer
arithmetic.
Such use of point arithmetic is not uncommon.
I think the current GC
On Wednesday, 30 April 2014 at 15:33:29 UTC, Andrei Alexandrescu
wrote:
I think the current GC already does that.
I don't think the current GC can either recognize slices or
deallocate parts of an object.
30-Apr-2014 19:33, Andrei Alexandrescu пишет:
I'm mulling over a couple of design considerations for allocators, and
was thinking of the following restriction:
1. No out-of-bounds tricks and no pointer arithmetic. Consider:
int[] a = new int[1000];
a = a[250 .. 750];
int* p = a[500 .. $].ptr;
On 4/30/14, 11:15 AM, Dmitry Olshansky wrote:
It doesn't and CAN'T. As long as there is a pointer into the block it
stays. There are plenty of ways to shoot yourself in the foot if this
rule is not respected. Anyhow, for starters, a conservative GC doesn't
know what is a slice when ptr/length
On Wednesday, 30 April 2014 at 20:29:37 UTC, Andrei Alexandrescu
wrote:
On 4/30/14, 11:15 AM, Dmitry Olshansky wrote:
It doesn't and CAN'T. As long as there is a pointer into the
block it
stays. There are plenty of ways to shoot yourself in the foot
if this
rule is not respected. Anyhow, for
On 4/30/14, 1:34 PM, Vladimir Panteleev wrote:
On Wednesday, 30 April 2014 at 20:29:37 UTC, Andrei Alexandrescu wrote:
On 4/30/14, 11:15 AM, Dmitry Olshansky wrote:
It doesn't and CAN'T. As long as there is a pointer into the block it
stays. There are plenty of ways to shoot yourself in the
On Wed, 30 Apr 2014 16:29:38 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 4/30/14, 11:15 AM, Dmitry Olshansky wrote:
It doesn't and CAN'T. As long as there is a pointer into the block it
stays. There are plenty of ways to shoot yourself in the foot if this
rule is not
On Wed, 30 Apr 2014 14:15:03 -0400, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
30-Apr-2014 19:33, Andrei Alexandrescu пишет:
4. Currently, struct objects created with new do NOT have their
destructors called during collection. I think this may continue, meaning
that structs created with
14 matches
Mail list logo
