Add GrSet class built on top of RedBlackTree

Add GrSet class built on top of RedBlackTree

BUG=skia:

Committed: http://code.google.com/p/skia/source/detail?r=13616

[mtklein, 2014-02-26 21:24:06]

On 2014/02/26 21:22:13, egdaniel wrote:

If the things you're using this with are hashable, you might want to try
building on SkTDynamicHash for sweet sweet amortized O(1) operations.

[bsalomon, 2014-02-26 21:56:09]

https://codereview.chromium.org/176903003/diff/80001/bench/GrSetBench.cpp
File bench/GrSetBench.cpp (right):

https://codereview.chromium.org/176903003/diff/80001/bench/GrSetBench.cpp#new...
bench/GrSetBench.cpp:20: fName.append("grSet_build");
For the names maybe we should use "set_<foo>" rather than "grSet". If this
graduates to sk then we'd either have to have an anachronistic name or cause a
discontinuity in the bench history.

Also, maybe set_build_and_destroy for this one? It wouldn't shock if free() from
the ~ was really significant.

https://codereview.chromium.org/176903003/diff/80001/src/gpu/GrRedBlackTree.h
File src/gpu/GrRedBlackTree.h (right):

https://codereview.chromium.org/176903003/diff/80001/src/gpu/GrRedBlackTree.h...
src/gpu/GrRedBlackTree.h:14: #include <cstring>
I notice in other places we #include string.h and use strcmp rather than
std::strcmp. Maybe that's not the best practice, but we should probably at least
be consistent.

https://codereview.chromium.org/176903003/diff/80001/src/gpu/GrSet.h
File src/gpu/GrSet.h (right):

https://codereview.chromium.org/176903003/diff/80001/src/gpu/GrSet.h#newcode20
src/gpu/GrSet.h:20: virtual ~GrSet() {}
If this guy has no other virtual functions we should probably not force a vtable
on him.

https://codereview.chromium.org/176903003/diff/80001/src/gpu/GrSet.h#newcode27
src/gpu/GrSet.h:27: bool empty() const {return fRBTree.empty();}
I think we usually do have spaces inside the braces, { return fRBTree.empty() }

https://codereview.chromium.org/176903003/diff/80001/src/gpu/GrSet.h#newcode93
src/gpu/GrSet.h:93: T& operator *() const { return *fTreeIter; }
Any thoughts on the danger of allowing the user of the iterator to modify the T
object and thereby break the sorted order?

[bsalomon, 2014-02-27 15:01:37]

lgtm

[egdaniel, 2014-02-27 20:08:19]

The CQ bit was checked by egdaniel@google.com

[commit-bot: I haz the power, 2014-02-27 20:08:25]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/egdaniel@google.com/176903003/160001

[commit-bot: I haz the power, 2014-02-27 20:23:26]

Change committed as 13616