concurrent_unordered_map requires index to be default constructible

[klaim]

I'm using ITBB 4.1 and I have this problem that concurrent_unordered_map can't compile without the index type being default constructible.
However this don't follow C++ containers requirements (in C++11 at least).

Most of the time this wouldn't be a big problem, but it prenvents me to do this for example:

[cpp]
tbb::concurrent_unordered_map< std::type_index, MyFunctor > m_translation_table;
[/cpp]

See http://en.cppreference.com/w/cpp/types/type_index

I think I'll use a type_info pointer instead but this is not supposed to be portable AFAIK.

So, are there plans to fix this? Or does the concurrency feature prevent accepting non-default-constructible indice?

[Anton_P_Intel]

klaim, Thanks for reporting it. Interesting use case. TBB team will consider if it possible/feasible to implement.

[klaim]

Anton, did you have time to check if this can be fixed?

[Christophe_H_Intel]

Hello,

Sorry for the delay; I have a patch file that you can apply to include/tbb/internal/_concurrent_unordered_impl.h to remove the requirement that a default constructor be available.  (The fix is for the TBB U2 version.)

Thanks for the report.

Chris

[klaim]

Thanks, I will be able to try it next week.

What is the U2 version of TBB? 

[Christophe_H_Intel]

It is the newest update for TBB 4.1.  It's available now on threadingbuildingblocks.org.

Thanks again, and I appreciate the container is useful to you.

Regards,
Chris

[klaim]

I just tried to use this patch, had to do it by hand but it's not very complicated.

It seem to compile but I can't test runtime yet, I'll report if there are problems or not.

Question: will this change be implemented in the next TBB versions? 

[Vladimir_P_1234567890]

It have been released in current update 3

--Vladimir

[klaim]

Nice! I'm upgrading my TBB version right now. Thanks guys!

Unfortunately these containers also have a big problem which is they don't allow move-only values like std::unique_ptr. I don't know yet how to get around this problem in my case, maybe just using std::shared_ptr instead but it looks like a waste of speed.