On Tuesday, 16 September 2014 at 11:26:05 UTC, rcor wrote:
On Tuesday, 16 September 2014 at 08:49:04 UTC, Marc Schütz
wrote:
On Tuesday, 16 September 2014 at 08:39:43 UTC, Marc Schütz
wrote:
Whether the compiler should accept that or not is a different
question. I guess it should, because if it doesn't, there
wouldn't be an easy way to achieve a reinterpret cast (only
via an intermediate cast to `void*`, which is clumsy).
Anyway, using `std.conv.to` is the way to go here (if you
don't require that last bit of performance), because it is
safer in general (also checks for overflows and the like, for
example).
Thanks, didn't think of trying std.conv.to. Can someone expand
a bit on what to! is doing in this situation that cast isn't? I
looked up 'reinterpret cast' but didn't see the connection to
this.
Reinterpret cast means that the compiler should treat whatever is
at the memory location as the given type, and not modify it in
any way. `std.conv.to` can do more work, for example it can also
parse strings into integers:
assert("42".to!int == 42);
AFAIK casting between interfaces and classes needs to adjust
the underlying pointer. Therefore, when casting an array, the
compiler would have to do that with the entire array, which
cannot be copied without allocating memory (and mustn't be
modified in-place for consistency reasons). This means that
the cast is instead a pure reinterpret cast (repainting).
Is to! creating a new array of pointers while cast isn't? This
isn't a performance critical section and it's not a huge array,
so I ask mostly out of curiosity.
Yes, it is. (Probably. I don't have the time to test it now, but
it's likely if my theory about the pointer adjustment is correct.)
