Segfault when casting array of Interface types
via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Tue Sep 16 07:13:46 PDT 2014
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.)
More information about the Digitalmars-d-learn
mailing list