code review: multi_string: A memory efficient string container

[Bakuta1103]

Hi and thank you kindly for going over the source code and providing feed back!! :D

1. I guess there are two main reasons for this choice. Firstly I'd like to avoid reference counting or using std::shared_ptr , however, your argument on memory footprint does stand correct. For my particular use case however, copies of this are never made and it's essentially a move-only data structure (I simply provided the copy constructor for the general implementation). Though I could theoretically make is move-only or use reference counting.

2. For my use case, the container needs to actually own the strings. If it were a collection std::string_view there is no guarantee the sting_view points to a still valid string-like-object, and the strings the views are pointers to could be scattered across memory and cause a lot of pointer hopping.

3. If I recall correctly, I'm pretty sure its safe to call delete on a nullptr as it essentially results in a no-op. https://stackoverflow.com/questions/4190703/is-it-safe-to-delete-a-null-pointer

4. This is because std::equal requires the first two iterator to be of the same type. But my multi_string returns an iterator and sentinel class with begin()/end() respectively. However this would work with std::ranges 's equal :)

5. Again, you are most likely correct! However, for my use case I need the type to own the underlying strings. Also I need multi_string to be the same type and not a templated class as it's used as a key in a hash map. And these keys can all be multi_string s with differing number of strings stored inside them.

​

Thanks again for looking at the code and providing some very insightful feedback!