Live data from Hacker News

Choosing a more optimal `String` type

swatinem.de

21–24 of 24 posts

Re: Choosing a more optimal `String` type

#21
post #9
post #7

Earlier quoted context omitted.

From 1983: Although "optimum" is an absolute term, like "unique", it became common verbal practice to make it relative: "not quite optimum" or "less optimum" or "not very optimum". Mel called the maximum time-delay locations the "most pessimum". https://users.cs.utah.edu/~elb/folklore/mel-annotated/node1....

Even worse! ‘Optimum’ in English is a noun, not an adjective.

[deleted]

Re: Choosing a more optimal `String` type

#23
post #12

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 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)

Unfortunately, this can't really be done efficiently 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 than it was allocated with, nor can its alignment be changed when it is reallocated. Thus, the from_raw_parts() idea would be unusable for any types with less than…

Wow that is annoying, especially since any malloc is going to give you 8-byte aligned allocations anyways.
Post reply on HN