Major performance problem with std.array.front()
Marco Leise
Marco.Leise at gmx.de
Wed Mar 19 02:14:56 PDT 2014
Am Sat, 08 Mar 2014 22:07:09 +0000
schrieb "Sean Kelly" <sean at invisibleduck.org>:
> On Saturday, 8 March 2014 at 20:50:49 UTC, Andrei Alexandrescu
> wrote:
> >
> > Pretty much everyone using ICU hates it.
>
> I think the biggest problem with ICU is documentation. It can
> take a long time to figure out how to do something if you've
> never done it before. Also, the C interface in ICU seems better
> than the C++ interface. And I'll grant that a few things are
> just far harder than they need to be. I wanted a transcoding
> iterator and ICU almost has this but not quite, so I've got to
> write my own. In fact, iterating across an arbitrary encoding in
> general is at least not intuitive and perhaps not possible. I
> kinda gave up on that. Um, and using UTF-16 as the standard
> encoding, requiring many transcoding operations to require two
> conversions. Okay, I guess there are a lot of problems with ICU,
> but it handles nearly every requirement I have, which is in
> itself quite a lot.
You find the answer here:
http://userguide.icu-project.org/icufaq#TOC-What-is-the-performance-difference-between-UTF-8-and-UTF-16-
In addition it is infeasible to maintain code for direct
conversions with all the encodings they support. The project
doesn't aim at providing a specific transcoding but all of
them equally. What can you do. For Java it is easier to accept
since they use UTF-16 internally.
--
Marco
More information about the Digitalmars-d
mailing list