what to do with postblit on the heap?

bearophile bearophileHUGS at lycos.com
Mon Jun 20 08:54:46 PDT 2011


Steven Schveighoffer:

> But my immediate question is -- is it better to half-fix the problem by  
> committing my changes, or leave the issue alone?

I suggest to leave the issue alone.


> Any solution that fixes the GC problem will have to store the typeinfo  
> somehow associated with the block.  I think we may have more traction for  
> this problem with a precise GC.
> 
> I don't think the right route is to store type info inside the struct  
> itself.  This added overhead is not necessary for when the struct is  
> stored on the stack.

> This is a possibility, making a struct only usable if it's inside another  
> such struct or inside a class, or on the stack.

Given that D is a system language, and the general usefulness and ubiquity of structs, a third possibility is to do both and add an attribute to help enforcing what can't be done on PODs, or add more runtime info _on request_ where the programmer wants more flexible structs. This solves the situation, but has the disadvantage of increasing D complexity a little.

Bye,
bearophile


More information about the Digitalmars-d mailing list