The cost isn't an extra byte of storage. The cost is that every slice will have to be a copy+append.
Both D and Go have special slice types to store pointers and offsets to the underlying arrays/strings, so slice operations can avoid that hit, IIRC. -- Kevin Cantu On Fri, Apr 20, 2012 at 6:20 PM, David Piepgrass <[email protected]> wrote: >> My preference is to remove null termination: >> >> * I'm guessing most strings aren't passed to C. (What are the most >> common C string calls in rustc?) > > > It isn't just C, I'm afraid. It's pretty much every other language and OS, > too, because every language and OS is designed for C as the > lowest-common-denominator. > >> * Each C function has its own expectations about character encoding >> >> and allowed characters, so calls to C involve extra state-tracking or >> checks anyway. > > > I can't really agree. Some C functions have 'expectations about character > encoding and allowed characters' but many don't, and those that do don't > necessarily require 'extra state-tracking or checks' at run-time. > > It would be best if rust could hide the 'implementation detail' of > null-termination, but for the foreseeable future, the potential interop > performance advantages probably outweigh a byte of wasted storage here and > there (after all, if one byte were important, we wouldn't want to use a > whole 4 bytes to hold the string length.) > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
