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

Subject: Re: [Boost-users] shared_lock ( ) causes Segmentation Fault in CentOS 5.5 x64?
From: Viatcheslav.Sysoltsev_at_[hidden]
Date: 2011-03-17 11:45:33

On Thu, 17 Mar 2011 15:48:37 +0100, Zap <zippo.fire_at_[hidden]> wrote:

> Frank Mori Hess <frank.hess <at> nist.gov> 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<string,string> 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<string, string> in
> boost::unordered_map<pair<string, string>, 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