In std::priority_queue, you can specify the comparator of the queue in runtime, as in example "sixth" from the following code example: http://www.cplusplus.com/reference/queue/priority_queue/priority_queue/
However, it does not seem like tbb:concurrent_priority_queue lets me to specify the comparator in runtime, since there is no constructor which takes comparator as an argument: I can only specify the type of the comparator as template. Would any of you please verify whether this is correct, and let me know whether there is a workaround available?
Do you know the type prior to runtime? It is hard to concieve that you do not know the the type. However, this could be an opaque object.
In this case, you might then require that the unknown class object contains a virtual member function "mycomparison". This will also require that your priority_queue be a queue of references/poiners to the unknown class. The other option is to create a member function to overload the functor to the mycomparison. (mypq_type.setCompare(fooFooCompare);)
Jim, you seem to be describing some form of type erasure, but I think it is a valid request to allow Compare instances with individual state, to be able, e.g., to prioritise objects by proximity to object x. Of course that doesn't mean that the relative priority of elements in the queue would be able to change once they have been inserted, but it should be possible to construct different queues for different reference objects. It's a strange oversight that this is not currently possible.
(Added) This seems easy enough: it only requires changing the constructors. I would model the order of the parameters as much as possible on std::priority_queue (with initial capacity in the place of container). If you would you like to try out a patch (before I contribute it), I can have one by tomorrow.
Another matter is the memory allocator. In C++11 there are allocator traits to decide whether the operand's allocator should be propagated to the destination, and the default is false, yet concurrent_prioirity_queue will always propagate the allocator. Something to fix as well?