Boost logo

Boost :

From: Sundell Software (sundell.software_at_[hidden])
Date: 2005-03-18 15:55:16


On Fri, 18 Mar 2005 16:34:24 -0300, Felipe Magno de Almeida
<felipe.almeida_at_[hidden]> wrote:
> reference counting optimization and maybe others, where there is.

And that it is already a part of the standard. Less code duplication
and the existance of a stable implementation. Dunno if the best thing
would be to make a unicode string class privatly inherit from
basic_string or perhaps do everything through iterators.

Each UTF-8/16/32 has its own iterator type, but all output UTF-32 when
accessed. Look at std::istream_iterator/std::ostream_iterator for
design. There would propably be helper functions for the most common
tasks and i think you should be able to do all the nessesary tasks
with just iterators.

typedef basic_string<utf_8> ustring8;
typedef basic_string<utf_16> ustring16;

ustring8 u8;
ustring16 u16;

// Would propably make .begin() default.
unicode_iterator i8(u8, u8.begin());

// This would be a slow way of doing operator[]. the assignment would
// insert/remove elements from the basic_string if nessesary.
*std::advance(unicode_iterator(u16, u16.begin()), 5) = *(i8++);

Note that the client is responible for giving a valid iterator to
unicode_iterator.

BTW, is using UTF-8/16 in the container really overall cheaper than
UTF-32. Since if the client changes a character, and it happens to be
larger/smaller then all the elements behind it would need to be moved.
Does that happen rarely enough? Though the client should propably know
that themselves.

Rakshasa


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