11.10.2014 07:47, Alex Crichton пишет:
The current design hasn't been written up into an RFC, but the current
thinking is documented in the last work week's minutes [1]. They're a
little messy, but they should be faithful to what we're thinking!
The general idea was that RC isn't actually an allocator per-se, but
rather a "boxer" which knows how to create an Rc<T> from a T. The
"boxer" could be parameterized over an actual allocator which would
dictate where memory comes from, but by the default allocator would
still be the jemalloc heap. We found that the distinction between an
allocator and a boxer gave you a bit more flexibility when it came to
allocators in terms of re-use between pointers such as Rc, Arc, and
Box.
[1]:
https://github.com/rust-lang/meeting-minutes/blob/master/workweek-2014-08-18/box-and-allocators.md
It would be great to have custom (C-style) allocators worked into a
redesign of CString.
Now it only works over malloc and free, except there is a constructor
flag that tells it not to own the C string, presumably a static. That
could be changed into:
CString::wrap(ptr as *mut libc::c_char, libc::ALLOC)
and perhaps
CString::wrap_static("A static C string\0".as_ptr() as *const
libc::c_char)
I could turn it into an RFC proposal if there is interest. There are
other potential problems with CString, such as being a full collection
with an O(1) length accessor, which makes the wrapping cost non-trivial.
There might be a case for a more lightweight wrapper which does not
implement Collection, Ord, Eq, and other convenient traits, but can be
promoted to a CString at the cost of a strlen, implements ToCStr, can
offer a CChars into itself, so it would be still quite usable on its
own. I've got this two-tiered design for my C string wrappers (the
strings are library-allocated and have an additional data domain
restriction of being in UTF-8, so it's a bit different from what
std::c_str needs):
https://github.com/mzabaluev/grust/blob/cb45bf7c5958a325658c50d57e524e24b7d7ccbc/src/utf8.rs#L33
Best regards,
Mikhail
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
