Zach Laine wrote:
Yes, that's what I was thinking as well. In fact, if you look at the Boost.GIL any_image<> and any_image_view<> templates, you'll see that they allow the user to specify a limit number of variants (a la Boost.Variant).
I'll have to take a look at how GIL handles this, since it would make sense to use a similar interface, since I assume GIL's any_image<> allows you to do things with an image represented in any file format that GIL knows about.
Looks good, but is this function an assignment, or an append?
In my mind, it's an assignment, so I guess it's not exactly the same as std::copy, but all that can be adjusted as we develop the library.
Yes. Views are notably absent in my original post. I think views are essential for encodings that are variable in length (e.g. UTF-8). Getting the character-location of code point N, or vice versa, and doing it efficiently, is a must-have.
Views have the additional benefit of providing a unified interface no matter what base string type you use (provided the base type behaves somewhat like std::string, i.e. has begin() and end() and maybe some other requirements). And it lets us neatly sidestep the issue of "what's the best data structure to store arbitrarily-encoded text?". :) There are obviously a whole host of specific issues that we should address, especially in regards to optimizations (e.g. ASCII -> UTF-8 can be a memcpy instead of a transcoding) and validation, but it seems like we have some consensus of what the interface should look like for day-to-day use, which is farther than a lot of Boost.Unicode attempts have gotten. - Jim