Comment #5 on issue 198 by ken...@google.com: Unnecessarily inefficient
calculation of utf-8 encoded lengt
http://code.google.com/p/protobuf/issues/detail?id=198
That's right... I think the places where protobuf-lite is used are
generally fine on CPU and really care about keeping code
Comment #6 on issue 198 by ken...@google.com: Unnecessarily inefficient
calculation of utf-8 encoded lengt
http://code.google.com/p/protobuf/issues/detail?id=198
BTW, I would not feel comfortable using code like suggested in this bug
report even if it were extended to handle surrogate
Comment #2 on issue 198 by ev...@mit.edu: Unnecessarily inefficient
calculation of utf-8 encoded lengt
http://code.google.com/p/protobuf/issues/detail?id=198
... although this slower code path is still used for LITE and SIZE
messages. It might be possible that a variant of this that
Comment #3 on issue 198 by ken...@google.com: Unnecessarily inefficient
calculation of utf-8 encoded lengt
http://code.google.com/p/protobuf/issues/detail?id=198
Hmm, why did we decide not to use the cache for LITE messages? It seems
like we should, but maybe I'm forgetting something?
Updates:
Status: Fixed
Labels: FixedIn-2.3.1
Comment #1 on issue 198 by ken...@google.com: Unnecessarily inefficient
calculation of utf-8 encoded lengt
http://code.google.com/p/protobuf/issues/detail?id=198
Unfortunately your code is incorrect in the case of code points
