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