Closed ruoso closed 7 years ago
Can you elaborate on this issue? Text_view doesn't introduce new storage types. The basic_text_view class template is parametrized on a non-owning view of storage that is managed elsewhere. The requirements of the view are very light - it just needs to be iterable. string_view will work fine. Text_view provides its own basic_view class template to wrap an iterator and sentinel pair (since the standard doesn't yet provide one) that allows the underlying storage to be an array, std::array, std::string, std::vector, or any other container that supports standard iteration. Providing a view adapter for the myriad other string classes in existence is generally trivial.
Let me take a second read at the code then, I may have misunderstood some bits.
Em sáb, 24 de set de 2016 22:17, Tom Honermann notifications@github.com escreveu:
Can you elaborate on this issue? Text_view doesn't introduce new storage types. The basic_text_view class template is parametrized on a non-owning view of storage that is managed elsewhere. The requirements of the view are very light - it just needs to be iterable. string_view will work fine. Text_view provides its own basic_view class template to wrap an iterator and sentinel pair (since the standard doesn't yet provide one) that allows the underlying storage to be an array, std::array, std::string, std::vector, or any other container that supports standard iteration. Providing a view adapter for the myriad other string classes in existence is generally trivial.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tahonermann/text_view/issues/23#issuecomment-249398418, or mute the thread https://github.com/notifications/unsubscribe-auth/AAE9K8gfjPT3oS41h8lZvdo4ZffiBeDHks5qtdnXgaJpZM4KFN3K .
Closing this issue as it appears to have been reported based on a misunderstanding.
In my experiments ( https://github.com/ruoso/u5e ), I managed to build a similar class and template hierarchy, but always doing that on top of an underlying string-like type (e.g.: string or string_view, or just plain const char*).
IMHO, this would allow better reusability, because it wouldn't be introducing alternative types, and you would be able to simply compose the unicode support on top of any string-like type.