cxx/include
Howard Hinnant d305d3c1a2 Hyeon-Bin Jeong: 1. sync() should reset it’s external buffer pointers.
Remaining characters should be discarded once sync() called. If don’t, garbage
characters can be inserted to the front of external buffer in underflow().
Because underflow() copies remaining characters in external buffer to it’s
front. This results wrong characters insertion when seekpos() or seekoff() is
called.

this line should be inserted in sync() just before return:
__extbufnext_ = __extbufend_ = __extbuf_;

2. sync() should use length() rather than out() to calculate offset.
Reversing iterators and calling out() to calculate offset from behind is
working fine in stateless character encoding. However, in stateful encoding,
escape sequences could differ in length. As a result, out() could return wrong
length. 

For example, if we have internal buffer converted from this external sequence:
(capital letters mean escape sequence)
… a a a a B b b b b

out() produces this sequence. 
b b b b A a a a a

Because out() inserts escape sequence A rather than B, result sequence doesn't
match to external sequence. A and B could have different lengths, result offset
could be wrong value too.

length() method in codecvt is right for calculating offset, but it counts
offset from the beginning of buffer. So it requires another state member
variable to hold state before conversion.
Fixes http://llvm.org/bugs/show_bug.cgi?id=13667

git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@162601 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-24 21:20:56 +00:00
..
This commit establishes a new bucket_count policy in the unordered containers: The policy now allows a power-of-2 number of buckets to be requested (and that request honored) by the client. And if the number of buckets is set to a power of 2, then the constraint of the hash to the number of buckets uses & instead of %. If the client does not specify a number of buckets, then the policy remains unchanged: a prime number of buckets is selected. The growth policy is that the number of buckets is roughly doubled when needed. While growing, either the prime, or the power-of-2 strategy will be preserved. There is a small run time cost for putting in this switch. For very cheap hash functions, e.g. identity for int, the cost can be as high as 18%. However with more typical use cases, e.g. strings, the cost is in the noise level. I've measured cases with very cheap hash functions (int) that using a power-of-2 number of buckets can make look up about twice as fast. However I've also noted that a power-of-2 number of buckets is more susceptible to accidental catastrophic collisions. Though I've also noted that accidental catastrophic collisions are also possible when using a prime number of buckets (but seems far less likely). In short, this patch adds an extra tuning knob for those clients trying to get the last bit of performance squeezed out of their hash containers. Casual users of the hash containers will not notice the introduction of this tuning knob. Those clients who swear by power-of-2 hash containers can now opt-in to that strategy. Clients who prefer a prime number of buckets can continue as they have.
2012-07-06 17:31:14 +00:00
2011-12-01 20:21:04 +00:00
2011-10-17 20:05:10 +00:00
2012-08-03 18:01:20 +00:00
2012-07-20 19:20:49 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2012-07-13 19:17:27 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2012-07-20 22:18:27 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
ios
2012-07-21 01:03:40 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2012-07-20 19:36:34 +00:00
2011-10-17 20:05:10 +00:00
2012-07-20 21:44:27 +00:00
set
2011-10-17 20:05:10 +00:00
2011-11-29 16:45:27 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-12-01 20:21:04 +00:00
2012-07-20 19:09:12 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2011-10-17 20:05:10 +00:00
2012-07-21 00:51:28 +00:00