On Fri, 18 Mar 2005 16:34:24 -0300, Felipe Magno de Almeida <felipe.almeida@ic.unicamp.br> 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