Boost logo

Boost :

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2008-01-28 15:57:31


----- Mensaje original -----
De: Edd Dawson <lists_at_[hidden]>
Fecha: Lunes, Enero 28, 2008 8:29 pm
Asunto: Re: [boost] [review] Review of Flyweight library started
January 21 and stillrunning!
Para: boost_at_[hidden]

> I have a situation where I'd like to experiment with this library,
> but I do not have time to start it yet. Perhaps my mentioning it is
> half-way valuable, though, so here goes :)
>
> When I saw the announcement, I immediately thought about using the
> library to store and access Unicode text. Specifically, I am
imagining
> that it might allow me to create a string type that acts as a
randomly
> accessible sequence of glyphs. Each glyph would be a flyweight<>.
>
> Most glyphs can of course be represented directly by a 32 bit
> integer, as they're only composed of a single code-point. However,
> uncommon glyphs that would need more than one code-point (because
> of combining marks) may benefit from a flyweight approach.
>
> Is this a good use case? Would std::basic_string<flyweight<glyph>
> "work" (with appropriate character traits)? Could I also get
> boost's regular expressions to operate on these strings?

Hi Edd,

I think you'd have problems making this work, but for reasons
unrelated to flyweight: for std::basic_string<X> to work,
char_traits<X>
must have a nested ::int_type typedef with the property that
X is convertible to that int_type and back to X without loss of
information (http://tinyurl.com/2t3se7 ): If your glyphs contain more
than two code-points you'd need an integral type longer than 64 bits,
which is most likely unavailable, or else resort to some clever
codification of sequences of code-points into 64 bits ints.

Other than this, you can certainly use flyweight<> to store
glyphs so as to achieve a uniform 32 bits per Unicode character.
This can be all wrapped up by a string-like container class.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk