Re: [boost] [unicode] Interest Check / Proof of Concept

Subject: Re: [boost] [unicode] Interest Check / Proof of Concept
From: James Porter (porterj_at_[hidden])
Date: 2008-11-22 04:26:41

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