The underlying std::string is freed?

Posted Jul 9, 2024 17:52 UTC (Tue) by NYKevin (subscriber, #129325)
In reply to: The underlying std::string is freed? by mathstuf
Parent article: New features in C++26

If I were doing that, I would just use strings for the individual components, cache/intern them aggressively with e.g. an std::unordered_map or the like, and then have functions for looking these up which hand out string_views everywhere. Then you're using no more than twice the file size of the input CMake file, which is probably on the order of kilobytes (I don't use CMake, but surely its files are not huge?). In fact, probably much less than that because I would tend to assume the average CMake file is not 100% made up of stringly-typed lists (but again, I don't use CMake).

The main problem with this approach is that cache invalidation is hard. But I'm not sure how many CMake files you're going to parse in one run of your program, so I don't know if that's actually a problem or not. Probably you can have a per-file cache if needed.

The underlying std::string is freed?

Posted Jul 12, 2024 14:53 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

The thing is that "lists" in CMake are just *interpretations* of the actual values. There's no such actual thing. Some APIs just interpret the values as `;`-separated lists. So interning values over something like:

```
foreach (item IN LISTS some_glob_result)
list(APPEND absolute_sources "${CMAKE_CURRENT_SOURCE_DIR}/${item}")
endforeach ()
```

would end up interning O(N²) string data to store the "real" value of `absolute_sources` across the loop.

CMake's inspirations came from Tcl (which is why it is stringly-typed) and the backwards compatibility guarantees make it very hard to actually break away from that.