Why no clang for Windows?
I think Herb is wrong. Const implies thread-safe, but thread-safe does not imply const, so the two are not equal/equivalent.
Concurrent containers etc will certainly be thread-safe but not all functions will be const.
May 02, 2012 at 12:03 PM
What platforms does this API support?
C++ needs cross-platform libs.
They're node-based. reserve() doesn't make sense for them."
Can you explain why.
The allocator could allocate a pool and serve requests from that to avoid calling malloc.
XTF> hexify's parameter type is const vector<unsigned char>&. boost::iterator_range<unsigned char> might've been better.
That would be an improvement (I haven't used iterator_range yet).
True, just wanted to point out that using const vector<unsigned char>& isn't very generic. And that I miss a ptr pair wrapper in the STL.
XTF> Can't you use hash_file.right.count(f) here?
count() is less efficient for multi-containers. I always use find().
I'm not familiar with bimap, but I assume it's not a multi-container.
You could write a simple class if performance really, really mattered.
I like the you don't pay for what you don't use principle in C++, but using vectors for buffers violates that. I'd also prefer not to write my own class for such basic functionality.
@STL: Are you aware of Step Into Specific? It's a context menu option that allows you to avoid repeatedly stepping into and out of functions until you hit the right one.
hexify's parameter type is const vector<unsigned char>&. boost::iterator_range<unsigned char> might've been better. STL lacks a ptr pair wrapper (for contiguous memory).
> hash_file.right.find(f) != hash_file.right.end()
Can't you use hash_file.right.count(f) here?
> const bimap<string, string>::left_const_iterator j = hash_file.left.find(h);
Can't you just insert and check the return value to avoid a second lookup?
Before you said vector<unsigned char> should be used for buffers. However, it initializes the buffer to 0, which is unnecessary overhead. Isn't there a better solution?