On Thu, Oct 11, 2012 at 9:20 PM, Niko Matsakis <[email protected]> wrote: > > You are correct that using a virtual table does incur some runtime cost. > > That's one of the reasons we chose to offer the option of using bounded > generics as an alternative, since (due to monomorphization) this implies no > vtable. For example: > > trait SomeTrait { fn method(); } > > // Uses a vtable: dynamic dispatch > fn foo(x: &SomeTrait) { x.method(); } > > // Does not use a vtable: static dispatch > fn foo<T: SomeTrait>(x: &T) { x.method(); } > > So in your inner loop, you may want to stick to bounded generics. (Of > course, it would be possible for a C++ or Rust compiler to emit code with > PICs. However, that implies a rather larger runtime, and we are generally > shooting for less runtime.)
And your VT will be an array which also has bound checking so performance will be worse than C++. This is not bad but clearly for Rust 90% of the time you want to use generics rather than OO . > > > I am not sure which "OO issues" you are referring to from that e-mail > precisely, but I do believe our design addresses many (if not all) of the > points that Shapiro raised. 1.Specifically the Instance Coherence problem The last (instance coherence) does not appear to admit any general solution, and it raises conceptual concerns about the use of type classes for method overload in my mind. 2.*The type class notion (more precisely: qualified types) is seductive, but absent a reasonable approach for instance coherence and lexical resolution it provides an unsatisfactory basis for operator overloading. There is a disturbingly close relationship between type class instances and object instances that needs further exploration by the PL community. The important distinction may be pragmatic rather than conceptual: type class instances are compile-time constants while object instances are run-time values. This has no major consequences for typing, but it leads to significant differences w.r.t. naming, binding, and [human] conceptualization.* * The human conceptualization is the difficult one. 3.And the VT Table ( which needs a this pointer) And introducing SelfType was an even bigger issue than introducing subtypes. It means moving out of System F<: entirely, and into the object type system of Cardelli *et al*. That wasn't just a matter of re-implementing the type checker to support a variant of the type system we already had. It meant re-formalizing the type system entirely, and learning how to think in a different model. 4.and the sections *Instance Coherence and Operator Overloading* *Conclusion about Type Classes and Overloading*: Ben Ben _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
