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