memcpy() comparison: C, Rust, and D

Chris Wright via Digitalmars-d digitalmars-d at puremagic.com
Wed Feb 1 08:12:45 PST 2017


On Wed, 01 Feb 2017 10:20:45 +0000, Patrick Schluter wrote:
> You have to define the mymemcpy() in another source file and only put
> the prototype in this module. If the compiler sees the code it can do
> the complete data flow analyses. With only the declaration it can't and
> that is Walter's point. The annotations allow to give to the declaration
> the information the compiler can not deduce itself from the code,
> because the code is in another module (object file, library).

OTOH I haven't seen anyone distribute a D library with .di files, and even 
extern(D) is pretty rare. That means whole program analysis is a lot more 
feasible.

The exception is virtual dispatch and functional programming, which is 
leaky enough compiling the whole program at once and intractable with any 
level of incremental compilation. The most obvious form is dub compiling 
each package you depend on into a static library.

But all whole-program analysis problems can be solved with a custom linker 
and object format, right?


More information about the Digitalmars-d mailing list