concurrent_unordered_map requires index to be default constructible

concurrent_unordered_map requires index to be default constructible

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:

tbb::concurrent_unordered_map< std::type_index, MyFunctor > m_translation_table;


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?


9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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

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


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.



Downloadtext/plain cu-fixed.diff.txt863 bytes

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

What is the U2 version of TBB? 

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

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


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? 

It have been released in current update 3


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.

Leave a Comment

Please sign in to add a comment. Not a member? Join today