News for hackers. Stuff that matters.
Re:Choosing a more optimal `String` type by nmilo on Friday September 22, 2023 @09:15PM (#37619767)
There should be a from_raw_parts-like interface for Arc that can construct one out of a pointer to a T + control block. That way you can shift the string data over and stick the control block inline (which is how I assume it's laid out in memory) and convert String to Arc<str> for free (well not free, shifting takes O(n), but so does the copying in Arc::new, so in the end you do end up avoiding an allocation for free)
Re:Choosing a more optimal `String` type by LegionMammal978 on Saturday September 23, 2023 @12:35AM (#37620603)
Unfortunately, this can't really be done with how allocation works in Rust. A String is always allocated with alignment 1, but an Arc's control block requires usize alignment. An allocated pointer can't be deallocated with a different alignment, nor can its alognment be changed when reallocating. Thus, the from_raw_parts() idea would be unusable for all types with less than usize alignment.

(And the need for atomic operations on the control block precludes the idea of simply letting it be unaligned.)

Re:Choosing a more optimal `String` type by Gibbon1 on Saturday September 23, 2023 @01:00AM (#37620682)
> A String is always allocated with alignment 1, but an Arc's control block requires usize alignment.

I'll add this to my list of reasons why alignment is terrible.

Re:Choosing a more optimal `String` type by nmilo on Saturday September 23, 2023 @01:42PM (#37625502)
Wow that is annoying, especially since any malloc is going to give you 8-byte aligned allocations anyways.