Bug 6182 – _d_arraycopy should take TypeInfo as final argument instead of simply element size

Status
RESOLVED
Resolution
DUPLICATE
Severity
major
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2011-06-20T08:19:00Z
Last change time
2013-06-13T07:29:05Z
Keywords
wrong-code
Assigned to
nobody
Creator
schveiguy

Comments

Comment #0 by schveiguy — 2011-06-20T08:19:39Z
This allows implementation of postblit (and possibly other runtime tasks) when array copying is done. For example, a[] = b[] will not call any postblits on the data copied. Once the compiler is fixed, I can generate a pull request to fix the runtime.
Comment #1 by timon.gehr — 2012-02-10T12:09:34Z
This is not an enhancement. postblits not being called is a clear bug.
Comment #2 by k.hara.pg — 2013-06-13T03:38:24Z
I checked this with 2.064a(fbd6c9f) struct S { static int cnt; this(this) { ++cnt; } } void main() { S[3] sa1; S[3] sa2; sa1[] = sa2[]; printf("S.cnt = %d\n", S.cnt); // prints 3 auto da1 = new S[](3); auto da2 = new S[](3); da1[] = da2[]; printf("S.cnt = %d \n", S.cnt); // prints 6 } Is this already fixed?
Comment #3 by peter.alexander.au — 2013-06-13T03:56:44Z
(In reply to comment #2) > Is this already fixed? It appears to have been fixed in 2.060 by yourself. It was fixed against Issue 6470.
Comment #4 by code — 2013-06-13T06:55:06Z
(In reply to comment #2) > > Is this already fixed? I just debugged it with dmd 2.063 where it is already fixed. It seems that the compiler now generates a call to _d_arrayassign as soon as the array is made of structs that have a postblit constructor or destructor. I didn't know _d_arrayassign did exist, so this bug is both fixed and invalid. _d_arraycopy was never intended to be used for complex types. _d_arrayassign exists for this purpose as far as I understand it.
Comment #5 by schveiguy — 2013-06-13T07:29:05Z
This was a LOOONG time ago :) Certainly possible it was fixed, and in a different way than I asked for. I'll close it, it seems issue 6470 was a better solution. *** This issue has been marked as a duplicate of issue 6470 ***