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.

Reply via email to