struct / cast / ? design problem
Charles Hixson via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Mon Mar 16 09:16:50 PDT 2015
On 03/15/2015 04:51 PM, ketmar via Digitalmars-d-learn wrote:
> On Sun, 15 Mar 2015 16:34:14 -0700, Charles Hixson via Digitalmars-d-learn
> wrote:
>
> if you know the exact layouts of `spare`, you can use union for that:
>
> struct S {
> // ...
> union {
> ulong[61] spare;
> struct { int vala; ubyte valb; }
> // etc.
> }
> }
>
> and then you can use it like this:
>
> auto s = S();
> s.vala = 42;
> assert(s.spare[0] == 42);
>
> you can also write a CTFE function that builds struct to cast where
> `spare` is changed to something else, using `S` as a source, but this
> solution will not be pretty. ;-)
The original method had no knowledge of the layout that the using module
will need, merely that it will need to store some information. (In this
particular case I *could* just modify the header in the original file,
but that isn't solving the design problem, and means that working code
needs to be modified to accommodate new code in a different file.)
IOW, if I could write the union, I wouldn't have needed to label the
unused header memory "spare". That solution *would* allow for multiple
secondary users, with different union values, but it would again mean
that new code would require the modifying of the file containing
existing code. This is normally considered bad practice.
More information about the Digitalmars-d-learn
mailing list