XTF

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.

What platforms does this API support?

Just Windows?

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.

Apr 29, 2011 at 5:23 PM, STL wrote

Michael Kilburn: Only map/multimap (and their unordered versions) have perfect forwarding inserts in VC11, not set/multiset. (This conforms to the FDIS.)

Why do other containers not have them?

@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?

Greetings,

Olaf