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