undefined | Better HN

0 pointsmasklinn7y ago0 comments

> You can represent it as a struct of (length, char[]) which isn't awful.

It kinda is still: if you're storing it on the stack you're dealing with an unsized on-stack structure which is painful, and if you're not you're paying a deref for accessing the length which you don't need to. If by `char[]` you mean `char*` then it's a record string, not a p-string.

0 comments

Dylan168077y ago

I mean a variable-length array, all stored together.

Presumably you'd allocate it on the heap in general. But a record string also requires a heap allocation.

Most of the time you're touching the length you're probably touching the string data too, so that dereference isn't going to cost very much. And it comes with a tradeoff of more compact local data. So I stand by it being not awful! It may not be perfect, but it's a solid option.

Thiez7y ago

When you have record strings you get slicing for free though. Without the indirection of a pointer you have to copy data when you slice (or you must have a separate 'sliced string' type).

Dylan168077y ago

"free" if you ignore the cost of doing lifetime management. So beneficial in some use cases but not others.

j / k navigate · click thread line to collapse

0 pointsmasklinn7y ago0 comments

> You can represent it as a struct of (length, char[]) which isn't awful.

0 comments

Dylan168077y ago

I mean a variable-length array, all stored together.

Presumably you'd allocate it on the heap in general. But a record string also requires a heap allocation.

Thiez7y ago

When you have record strings you get slicing for free though. Without the indirection of a pointer you have to copy data when you slice (or you must have a separate 'sliced string' type).

Dylan168077y ago

"free" if you ignore the cost of doing lifetime management. So beneficial in some use cases but not others.

j / k navigate · click thread line to collapse