Thank you for your detailed explanation! :D I'm so excited to see new string slices!
2012/6/21 Graydon Hoare <[email protected]>: > On 20/06/2012 10:05 AM, Graydon Hoare wrote: >> >> On 19/06/2012 4:12 AM, Shohei Wada wrote: >> >>> Is there any good datatype to copy out and keep the c-string? >>> Of course str is useless in this case, and it seems [c_char] has same >>> problem. >>> (vec::as_buf's signature is as_buf<E, T>(v: [const E], f: fn(*E) -> T) >>> -> T, >>> I may not allowed to return *E from the closure) >>> So I think I should use libc::malloc/memcpy/free and std::c_vec to >>> make sure the c-string survive. Is this right? > > ... > >> I.e. if you write your code so it keeps the strings alive for the >> duration of your needs, presently, you will only have a slight >> additional bit of code to write, to keep an arena alive as well, when we >> finish the upgrade to slices. > > > Er, of course, you can also insulate yourself against this change entirely > if you want to use c_vec, malloc/memcpy/free, as you note. I'm just pointing > out where we're going, longer-term. That longer-term interface should be > slightly less error-prone (we'll do all the null sniffing and termination > automatically, for example). > > > -Graydon > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev -- #################################### 和田 祥平 Shohei Wada Mail(PC): [email protected] _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
