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