I know that struct hasn't existed forever, still, I want to know if code like this was common before it was created, or common when you use f2c to translate FORTRAN code to C...

double dm5buf[ 32 ];                                          
byte   *const m5buf          = (byte*)dm5buf;                 
double *const SettlePrice    = (double*)((char*)m5buf      ); 
double *const PoolValue      = (double*)((char*)m5buf +   8); 
double *const DKFee          = (double*)((char*)m5buf +  16); 
double *const OtherFee       = (double*)((char*)m5buf +  24); 
double *const DKDays         = (double*)((char*)m5buf +  32); 

just checking :)

I've seen this used, but with sizeof() instead of hard-wired integer offsets...

Structures predate f2c. According to Dennis Ritchie, structures were in place by 1973, and were pretty complete by the release of K&R in 1978.

 Seems like a fairly reasonable way to emulate a Fortran named COMMON block.  If I was porting Fortran code to C I would use a struct, but this is closer to the Fortran syntax. Wow, I do not miss those days of chasing variables into common blocks, only to find that another module used the same block, but with the variables named differently.

 The only time I have seen new code even remotely similar to that was with cross-platform code where devlopers were concerned about platform specific variations in the way structures were packed (and were not familiar enough with all the compilers involved to get the packing pragmas right).

- dave 

Doesn't surprise me, since "As all Real Programmers know, the only useful data structure is the Array. Strings, Lists, Structures, Sets-- these are all special cases of arrays and can be treated that way just as easily without messing up your programming language with all sorts of complications." ( http://www.pbm.com/~lindahl/real.programmers.html ). ;)

dmearns:

 The only time I have seen new code even remotely similar to that was with cross-platform code where devlopers were concerned about platform specific variations in the way structures were packed (and were not familiar enough with all the compilers involved to get the packing pragmas right).

Concur. I use something similar in distributed embedded systems, not because I don't understand the packing pragmas, but because at least one of my compilers doesn't have any !.

This code is also written by someone that has figured out that pointer arithmatic means that adding a number to a pointer gives different results depending on the type of the pointer (hence they have done a stupid cast to byte then to char then add) but they haven't realised that this will actually make thier code much easier!

double dm5buf[ 32 ];                                          
byte   *const m5buf          = (byte*)dm5buf;                 
double *const SettlePrice    = dm5buf; 
double *const PoolValue      = dm5buf + 1; 
double *const DKFee          = dm5buf + 2; 
double *const OtherFee       = dm5buf + 3; 
double *const DKDays         = dm5buf + 4; 

SenTree:

dmearns:

 The only time I have seen new code even remotely similar to that was with cross-platform code where devlopers were concerned about platform specific variations in the way structures were packed (and were not familiar enough with all the compilers involved to get the packing pragmas right).

Concur. I use something similar in distributed embedded systems, not because I don't understand the packing pragmas, but because at least one of my compilers doesn't have any !.

 

 

If you're worried about cross-platform structure packing (e.g. for comms in a distributed system) then shouldn't you also be worried about things like endianness, which this approach doesn't address?

Hatshepsut:

SenTree:

I use something similar in distributed embedded systems, not because I don't understand the packing pragmas, but because at least one of my compilers doesn't have any !.

 

If you're worried about cross-platform structure packing (e.g. for comms in a distributed system) then shouldn't you also be worried about things like endianness, which this approach doesn't address?

Absolutely. That's why I said 'something like', meaning the explicit indexing. My code does also address endianness, basically by assembling words from explicitly indexed bytes. No, it's not elegant, but I don't believe there is an elegant solution given the legacy constraints.