Thanks for the explanation! So virtual function calls are kept to the absolute theoretical minimum, that's very good to know.
In my case I have one crate for some "infrastructure" and another crate for the "application" using it (there would be several of these). I guess having two copies isn't that bad. On Fri, Nov 15, 2013 at 2:30 PM, Daniel Micay <danielmi...@gmail.com> wrote: > On Fri, Nov 15, 2013 at 6:54 AM, Oren Ben-Kiki <o...@ben-kiki.org> wrote: > > > > That would be awesome, if it were true; it is quite a trick to pull that > off > > when the default methods are implemented in a different crate. Can > someone > > provide an authoritative answer on this? > > > > Also, C++ faces the problem of providing a single copy of monomorphised > > functions (for templates). This is done during the link phase and AFAIK > is > > one of the causes of C++ links taking a painfully long time. Will Rust > > suffer from the same problem? > > Rust serializes any generic or inline functions to an AST stored in > the crate metadata and will re-compile them as-needed per-crate. > > In both Rust and C++, you end up with one copy of these at runtime for > each dynamically linked shared object. With C++ templates, the linker > or link-time optimization discards duplicate instantiations across > compilation units. > > Rust doesn't have compilation units smaller than a crate so there is > no equivalent functionality. If you use crates as compilation units to > make compiles incremental/parallel, the situation is much worse than > C++ as you'll have many duplicates and they won't even go away with > link-time optimization until `mergefunc` works. > > There's almost no point in doing anything but a massive crate at this > point... >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
