3 ms·
There is always overhead when adding abstractions--the only question is whether you pay at runtime or at compile time. C++ (and presumably Rust) choose the latt
by bkeroack 11y ago
There is always overhead when adding abstractions--the only question is whether you pay at runtime or at compile time. C++ (and presumably Rust) choose the latter, Python and Go choose the former.
- steveklabnik 11y agoYes, in these discussions, the overhead being referred to is runtime overhead. There's also overhead in the sense of complexity for the programmer, which isn't really either of those two.
- humanrebar 11y ago> There's also overhead in the sense of complexity for the programmer Well, from the programmers' perspectives there are both read-time and write-time overheads. In C++-land, the discussion about the new (to C++) 'auto' keyword is about the trade-offs between the two.
- SamReidHughes 11y agoC++ chooses both kinds, with templates and virtual functions. Rust does too.
- Dewie3 11y agoIf you want to be really pedantic, there is also the choice between "runtime overhead" and "code overhead" (code specialization). And why not mention the overhead of the programmer foregoing these "short cuts" and hand-coding it herself.
- comex 11y agoThat first one ain't pedantic; C++ code on the whole tends to generate a lot of assembly bloat with inlined methods and template instantiations, and while executable size probably isn't that important for most use cases, it is for quite a few.
- Dewie3 11y agoIt is pedantic in the sense that "overhead" in a programming context will most of the time mean some kind of runtime overhead, unless noted otherwise.
- halayli 11y agoC++ traits, templates, and non-virtual classes have no overhead.
- Manishearth 11y agoTechnically Rust (and C++, IIRC) choose both, but the mindsets of most Rust(/C++) programmers/libraries is to use lower cost abstractions wherever possible. Rust provides features and libraries that provide a dynamic alternative to many different statically checked things; eg trait objects, cell types (internal mutability), shared pointers, etc. The difference is in the mindset: Most Rust programmers will hem and haw at having to use Box<Trait> until we don't have any other viable alternative (with Rust and its enums, there usually are many better ways to do it with lower cost). Java/Go libraries are completely okay with using dynamic dispatch everywhere. While writing Java code I won't be concerned about using an interface type or `Object` or whatever because zero-cost abstractions are not Java's thing. Of course, if there is a static alternative I will still prefer it, but I won't be too bothered if I just stick with `Object`.