On Tue, 18 Jan 2011 09:51:12 -0500, Chad Nelson wrote:
On Tue, 18 Jan 2011 02:47:54 +0000 Alexander Lamaison <awl03@doc.ic.ac.uk> wrote:
On Mon, 17 Jan 2011 18:47:04 -0500, Chad Nelson wrote:
I really wanted to avoid a dependency on the ICU library or anything similar if at all possible, but it looks like it might be inevitable. :-(
You may well find that you can ;) Artyom's latest work on Boost.Locale allows you to select from a range of different backends giving varying levels of locale support. ICU gives the 'best' results but for my project Swish, for instance, I didn't need any of these advanced features so I just use the Win32 backend. This uses the Windows API to do the conversions etc. and freed me from the beast that is ICU.
Oh! I didn't realize that, thanks for the information!
In that case, what would people say to not having any conversion code in the Unicode strings stuff at all (other than between the different UTF-* codings, and maybe to and from ASCII for convenience), and relying on Boost.Locale for that? Then the trade-offs are up to the developer using each.
I don't think the string classes should implement _any_ of the conversions themselves but should delegate them all to Boost.Locale. However, they should look like they're doing the conversions by hiding the Boost.Locale aspect from the caller as much as possible. Alex -- Easy SFTP for Windows Explorer (http://www.swish-sftp.org)