AaronBallman wrote:
> We could keep `CXString` as it was before, but `const void *data` could
> actually point to a dynamically allocated struct that has roughly this
> definition:
>
> ```c
> struct Data {
> size_t length;
> char data[1];
> };
> ```
>
> This wouldn't change the current API, and it would still be only one
> allocation. What do you think?
It means all such string accesses would require two indirections to get to the
string data, but that may be acceptable overhead (we probably should measure
though, given how much string processing happens in tooling). I also wonder if
we want to be slightly less memory efficient and add a `version` field in case
we need to make changes again in the future (the only revision I can think of
right now has to do with encodings, but we always use a single charset
internally (UTF-8) so I don't know that we'd ever start returning multiple
different encodings within the same program such that we'd need to track it on
the string).
CC @cor3ntin who thinks about strings more than most folks do, so he may have
opinions or ideas
https://github.com/llvm/llvm-project/pull/134551
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
