Speeding up importing Phobos files

Mike Franklin slavo5150 at yahoo.com
Fri Jun 7 15:34:22 UTC 2019


On Friday, 7 June 2019 at 14:45:34 UTC, H. S. Teoh wrote:

> The flip side of this coin is that having one file per module 
> helps with code organization in typical use cases. As opposed 
> to the chaotic situation in C/C++ where you can have one .h 
> file with arbitrary numbers of .c/.cc files that implement the 
> function prototypes, with no obvious mapping between them, or 
> multiple .h files with a single amorphous messy .c/.cc file 
> that implements everything. Or where there are arbitrary 
> numbers of modules nested inside any number of .c/.cc files 
> with no clear separation between them, and where filenames bear 
> no relation with contents, making code maintenance challenging 
> at best, outright nightmarish at worst.

What I'm proposing is that a library's organization can be one 
file per module while it is being developed, but once it is 
published for consumption by others all packages/modules are 
concatenated into one file so it's faster for users to import.  
Or you could even concatenate some packages/modules, but not 
others depending on how users typically interact with the library.

There may be use cases (like mine with the memory-mapped IO 
registers) where users may want to actually develop with more 
than one module per file.  Or when one wants to share 
multi-package/module cut-and-pastable code examples. But those 
are special cases.

What's nice is that it changes nothing for users today.  It just 
removes an arbitrary limitation to help improve import speed 
while enabling some more flexibility for those who may it.

Mike



More information about the Digitalmars-d mailing list