On Wed, Apr 2, 2014 at 9:21 PM, Daniel Micay <danielmi...@gmail.com> wrote: > I used a sentinel value in my fix along with providing a guarantee that > `free` is never called on zero-size allocation. That's the end of any > no-op `Vec<T>` -> `~[T]` conversions since it will need to free a zero > size allocation. It's not far from just calling `shrink_to_fit`, and > allowing for passing a size to `free`. > > https://github.com/mozilla/rust/pull/13267
I see the benefit of free knowing the size in this case, although it seems that it would strongly call for type-level integers to avoid needing a special case in the compiler. I don't think this issue necessarily guarantees Vec<T> can't be freely converted to ~[T]. You could hypothetically special case allocations for zero-sized types, while keeping all other allocations real (including zero sized, since the impact would be minimal). > You're talking about allocators designed around the limitation of an > API. The design no longer needs to make the same compromises if you're > going to know the size. The difference between no cache miss and a cache > miss is not insignificant... I explained why I think a chunk header is necessary in any case. Maybe it is still a significant win. The C++14 proposal claims Google found one with GCC and tcmalloc, although tcmalloc is rather inefficient to start with... I would like to see numbers. Then again, I agree with the other reasons that using ~[T] is a bad idea, so I have no particular reason to disagree with having the size parameter either. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
