Proposed improvements to the separate compilation model

bearophile bearophileHUGS at lycos.com
Fri Jul 22 17:08:50 PDT 2011


Andrei:

> Currently, in order for a program with separately-implemented methods to 
> work properly, there must be TWO different files for the same class, and 
> the .di file and the .d file MUST specify the same exact field layout. 
> Ironically, the .d file is forbidden from including the .di file, which 
> makes any checks and balances impossible. Any change in the layout (e.g. 
> swapping, inserting, or removing fields) is undetectable and has 
> undefined behavior.

Aren't .di files automatically generated? So isn't the job of tools like IDEs too keep .di files in sync with their .d file? .di files are better left as computer-generated things.

And if you really want to be sure, why you don't add something like this, that asks the compiler to verify they are in sync (most times a 128 bit hash of the .d module copied inside the .di file is enough to be sure the .d is in sync with its .di file:
pragma(di_sync); 
There's also the possibility of a more fine grained hashing, usable to assert that the things you care for in a struct/class (like its layout) have not changed compared to the .di file.

Bye,
bearophile


More information about the Digitalmars-d mailing list