Does std::set have an efficient copy?

I want to assign one std::set object to another without worrying about
performance. Do implementations std::set use data sharing? Thanks.

"Jason Heyes" <jasonheyes@optusnet.com.au> wrote in message
news:41970fcd$0$27451$afc38c87@news.optusnet.com.a u...[color=blue]
>I want to assign one std::set object to another without worrying about
>performance. Do implementations std::set use data sharing? Thanks.[/color]

No they don't. Use a smart pointer.

john

"Jason Heyes" <jasonheyes@optusnet.com.au> skrev i en meddelelse
news:41970fcd$0$27451$afc38c87@news.optusnet.com.a u...[color=blue]
>I want to assign one std::set object to another without worrying about
>performance. Do implementations std::set use data sharing? Thanks.
>[/color]
Depends on the implementation, but most likely it will not. Why don't you
simply use a const reference? If you are changing one of the sets, you
should a "real" copy anyway.

/Peter

"John Harrison" <john_andronicus@hotmail.com> wrote in message
news:2vol8qF26qj93U1@uni-berlin.de...[color=blue]
>
> "Jason Heyes" <jasonheyes@optusnet.com.au> wrote in message
> news:41970fcd$0$27451$afc38c87@news.optusnet.com.a u...[color=green]
>>I want to assign one std::set object to another without worrying about
>>performance. Do implementations std::set use data sharing? Thanks.[/color]
>
> No they don't. Use a smart pointer.[/color]
Agreed.

A sometimes valid alternative is to use the swap() member
function of std::set (or any other container):
set1.swap( set2 );

This is guaranteed to be efficiently implemented, and might allow
you to do what you want.
For example, a common C++ idiom to avoid unnecessary copies
when adding items to a container is to replace:
myQueueOfSets.push_back( aNewSet )
with:
myQueueOfSets.push_back( std::set<ItemType>() ); // add empty set
myQueueOfSets.back().swap( aNewSet );


hth-Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Brainbench MVP for C++ <> http://www.brainbench.com

"Peter Koch Larsen" <pklspam@mailme.dk> wrote in message
news:EdFld.64853$Vf.3213383@news000.worldonline.dk ...[color=blue]
>
> "Jason Heyes" <jasonheyes@optusnet.com.au> skrev i en meddelelse
> news:41970fcd$0$27451$afc38c87@news.optusnet.com.a u...[color=green]
>>I want to assign one std::set object to another without worrying about
>>performance. Do implementations std::set use data sharing? Thanks.
>>[/color]
> Depends on the implementation, but most likely it will not. Why don't you
> simply use a const reference? If you are changing one of the sets, you
> should a "real" copy anyway.
>
> /Peter[/color]

You don't have to copy until the set changes. There is no need for const
references if you have data sharing.

"Jason Heyes" <jasonheyes@optusnet.com.au> skrev i en meddelelse
news:4197f011$0$2675$afc38c87@news.optusnet.com.au ...[color=blue]
> "Peter Koch Larsen" <pklspam@mailme.dk> wrote in message
> news:EdFld.64853$Vf.3213383@news000.worldonline.dk ...[color=green]
>>
>> "Jason Heyes" <jasonheyes@optusnet.com.au> skrev i en meddelelse
>> news:41970fcd$0$27451$afc38c87@news.optusnet.com.a u...[color=darkred]
>>>I want to assign one std::set object to another without worrying about
>>>performance. Do implementations std::set use data sharing? Thanks.
>>>[/color]
>> Depends on the implementation, but most likely it will not. Why don't you
>> simply use a const reference? If you are changing one of the sets, you
>> should a "real" copy anyway.
>>
>> /Peter[/color]
>
> You don't have to copy until the set changes. There is no need for const
> references if you have data sharing.
>[/color]
Of course. But all this fuss probably is not worthwhile, especially on
modern platforms where multithreading is part of the game.

/Peter

"Peter Koch Larsen" <pklspam@mailme.dk> wrote in message
news:hO4md.65079$Vf.3231893@news000.worldonline.dk ...[color=blue]
>
> "Jason Heyes" <jasonheyes@optusnet.com.au> skrev i en meddelelse
> news:4197f011$0$2675$afc38c87@news.optusnet.com.au ...[color=green]
>> "Peter Koch Larsen" <pklspam@mailme.dk> wrote in message
>> news:EdFld.64853$Vf.3213383@news000.worldonline.dk ...[color=darkred]
>>>
>>> "Jason Heyes" <jasonheyes@optusnet.com.au> skrev i en meddelelse
>>> news:41970fcd$0$27451$afc38c87@news.optusnet.com.a u...
>>>>I want to assign one std::set object to another without worrying about
>>>>performance. Do implementations std::set use data sharing? Thanks.
>>>>
>>> Depends on the implementation, but most likely it will not. Why don't
>>> you simply use a const reference? If you are changing one of the sets,
>>> you should a "real" copy anyway.
>>>
>>> /Peter[/color]
>>
>> You don't have to copy until the set changes. There is no need for const
>> references if you have data sharing.
>>[/color]
> Of course. But all this fuss probably is not worthwhile, especially on
> modern platforms where multithreading is part of the game.
>
> /Peter[/color]

Why is multithreading important to this discussion?

"Jason Heyes" <jasonheyes@optusnet.com.au> wrote in message news:<41996649$0$24379$afc38c87@news.optusnet.com. au>...[color=blue]
> "Peter Koch Larsen" <pklspam@mailme.dk> wrote in message
> news:hO4md.65079$Vf.3231893@news000.worldonline.dk ...[color=green]
> >
> > "Jason Heyes" <jasonheyes@optusnet.com.au> skrev i en meddelelse
> > news:4197f011$0$2675$afc38c87@news.optusnet.com.au ...[color=darkred]
> >> "Peter Koch Larsen" <pklspam@mailme.dk> wrote in message
> >> news:EdFld.64853$Vf.3213383@news000.worldonline.dk ...[/color][/color][/color]
[snip][color=blue][color=green][color=darkred]
> >> You don't have to copy until the set changes. There is no need for const
> >> references if you have data sharing.
> >>[/color]
> > Of course. But all this fuss probably is not worthwhile, especially on
> > modern platforms where multithreading is part of the game.
> >
> > /Peter[/color]
>
> Why is multithreading important to this discussion?[/color]

Because in MT environments, other threads could notice a change in the
set when a thread is doing a COW. See Herb Sutter's analysis of the
COW string class on gotw.ca or in his (M?)XC++ book.

Regards,
Michiel Salters