On 11/1/14 10:44 AM, Iain Buclaw via Digitalmars-d wrote:
On 1 November 2014 14:19, ketmar via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
On Sat, 1 Nov 2014 13:56:49 +0000
Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
if such assigns will be forbidden for any arrays... this is even worse.
"what? your shiny language can't do what even the simpliest C compiler
can do? now try to convince me that D is not a toy."
That - for sure - is where you're wrong. :-)
i was talking about C, not that abomination. but if D will compete with
C++ for the quirks... than C++ is a winner. ;-)
besides, i clearly see 'list.ptr' there. i don't see 'dynArray.ptr' in
D code. if i was using '.ptr' directly and it changes by the way... ok,
it was my fault. but i never used '.ptr' in my sample!
You can clearly see the 'list.length' though. You can't possibly go
off the assumption that if you grow the size of a dynamic array, it's
area in memory won't be relocated.
I think his assumption is that an array reference should not *re-alias*
into another array.
This is the problem with calling them dynamic arrays -- they are slices
of dynamic arrays. And altering the length of a slice can make it point
at an entirely new dynamic array, with the original array (and in fact
the original slice) still intact.
If, for example, the array was an object, and it's *private* underlying
storage moved, well then the opIndexAssign would use the new storage,
and the array reference doesn't actually change. I don't think it's
unreasonable to expect this, but that's based on an incorrect
understanding of how D dynamic arrays work.
There is a reason we get at least 1 question a week on how D arrays work.
-Steve
