Re: [Boost-users] shared_lock ( ) causes Segmentation Fault in CentOS 5.5 x64?

On Thu, 17 Mar 2011 15:48:37 +0100, Zap wrote:

Frank Mori Hess writes:

...

operator[] on maps can modify the map. Maybe you want to use find() instead?

Hi Frank,

I'll try it later, thanks for your answer,

Is there any difference of performance between using operator[] and .find()?

Performance difference?!? Do you realize how much new/delete operations you trigger by constructing pair from two const char* literals and by simple assignment of two keys? To the matter of question - I would not expect any performance difference, especially if compiled with optimization, but I cannot speak for boost implementation.

especially in frequently finding key/value of pair in boost::unordered_map, boost::unordered_set<int> >.

and another question is, could I use container in container such as what I wrote(unordered_set as value in unorder_map)? is this kind of structur undefine-behaviour or it's acceptable?

if it's acceptable, did this kind of structure will cause decrasing of performance or won't?

You may use these constructs, but you must be very carefully not to trigger occasionally deep copy when not intended to.

if it will, what kind of instead structure could I use to satisfy what I need to do?

It all depends on your project and associated performance requirements. Variants include using indices instead of string pairs (think of atoms in xlib), I would definetely use pointers/smart_pointers as values in the map instead complex values itself or some kind of indices to other tables if pointers are not suitable. Btw the integer set, which you use as the map value, may be implemented much more effeciently as bitset if the range for your integers is small. // Have you noticed how gently have we drifted away from the topic theme ;) -- Slava