headers
zap.foster | 1 Sep 2009 01:04
Picon

Re: Correct use of unordered_map

I believe one solution would look something like:

	const my_map_t::iterator end= my_map.end();
	for (my_map_t::iterator it= my_map.begin(); it != end;  )
	{
	  if (is_to_be_removed(it->first))
	    it = global_map.erase (it);
	  else
	    ++it;
	}

-z

John Dlugosz wrote:
> Consider this loop:
> 
> 	const my_map_t::iterator end= my_map.end();
> 	 for (my_map_t::iterator it= my_map.begin(); it != end;  ++it) {
> 	    if (is_to_be_removed(it->first))  global_map.erase (it);
> 	    }
> 
> The documentation I've seen for unordered_map says that removing doesn't invalidate iterators except
those referring to the element being deleted.  But that's the case for it itself!  Also, what does removing
one element do to the ordering of the elements -- is there any guarantee that the iterator will visit
exactly the ones that were not visited before?
> 
> What is the correct, standards-conforming, way to perform this?
> 
> Thanks,
> --John
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Hadsell | 1 Sep 2009 01:12

Re: Correct use of unordered_map

John Dlugosz wrote:
> Consider this loop:
>
> 	const my_map_t::iterator end= my_map.end();
> 	 for (my_map_t::iterator it= my_map.begin(); it != end;  ++it) {
> 	    if (is_to_be_removed(it->first))  global_map.erase (it);
> 	    }
>
> The documentation I've seen for unordered_map says that removing doesn't invalidate iterators except
those referring to the element being deleted.  But that's the case for it itself!  Also, what does removing
one element do to the ordering of the elements -- is there any guarantee that the iterator will visit
exactly the ones that were not visited before?
>
> What is the correct, standards-conforming, way to perform this?
>   
I use one of these 2 ways:

 for (my_map_t::iterator it= my_map.begin(); it != end; ) {
  if (is_to_be_removed(it->first))
   it = global_map.erase (it);
  else
   ++it;
 }

 for (my_map_t::iterator it= my_map.begin(); it != end; ) {
  my_map_t::iterator itx = it++;
  if (is_to_be_removed(itx->first))
   global_map.erase (itx);
 }
(Continue reading)

Permalink | Reply | 11 comments |
headers
er | 1 Sep 2009 01:11
Picon

Re: cycle iterators

I'm not sure if I already asked in a private conversion, but even if I 
did, this the occasion to ask again : why not have an assignment 
operator for cycle_iterator? I think the base iterator could be replaced 
by that which is contained in super_t.
Permalink | Reply | 10 comments |
headers
Richard Hadsell | 1 Sep 2009 01:16

Re: Correct use of unordered_map

Richard Hadsell wrote:
> I use one of these 2 ways:
>
> for (my_map_t::iterator it= my_map.begin(); it != end; ) {
>  if (is_to_be_removed(it->first))
>   it = global_map.erase (it);
>  else
>   ++it;
> }
>
>
> for (my_map_t::iterator it= my_map.begin(); it != end; ) {
>  my_map_t::iterator itx = it++;
>  if (is_to_be_removed(itx->first))
>   global_map.erase (itx);
> }
I should add that the second way is useful, when you are not executing 
'erase' but rather some arbitrary code that may or may not actually 
erase the element from the container.

--

-- 
Dick Hadsell			203-992-6320  Fax: 203-992-6001
Reply-to:			hadsell <at> blueskystudios.com
Blue Sky Studios                http://www.blueskystudios.com
1 American Lane, Greenwich, CT 06831-2560
Permalink | Reply | 1 comment |
headers
Andrew Sutton | 1 Sep 2009 02:16
Picon

Re: [BGL] backward warning

 
When compiling with gcc4.3 I get a backward warning from
adjacency_list.hpp because it includes hash_set instead of unordered_set
(Boost 1.39.0). Will this be fixed soon?

Hopefully I'll figure out a good approach for 1.41. For the time being you can define the macro BOOST_NO_HASH to suppress the warning.

Andrew Sutton
andrew.n.sutton <at> gmail.com
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Permalink | Reply | 1 comment |
headers
Andrew Sutton | 1 Sep 2009 02:19
Picon

Re: [BGL] backward warning


Hopefully I'll figure out a good approach for 1.41. For the time being you can define the macro BOOST_NO_HASH to suppress the warning.

Just a quick follow up. Defining this macro will not allow you to use the hash_setS or hash_mapS container selectors. They are not, to my knowledge, widely used so hopefully it won't be an issue.
 
Andrew Sutton
andrew.n.sutton <at> gmail.com
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Permalink | Reply | 0 comments |
headers
Rajeev Rao | 1 Sep 2009 02:32
Picon
Favicon

shared_ptr and weak_ptr concurrency

This is the first time I'm using boost in a multi-threaded env (linux x86_64,gcc 4).

 This question may have been asked in other forms. However, from what I've been able to search (google) up, I could not get a crystal clear answer.  I'm essentially trying to use the solution provided in this page. 

http://onlamp.com/pub/a/onlamp/2006/05/04/smart-pointers.html?page=5. 

From the boost documentation, it appears that this could be an  undefined operation as the global shared pointer is being read and written to by multiple threads. Is that correct ? 

In case the link fails  or someone wants more details, please read on. 

I've got a n reader threads and 1 writer thread. 

initializion Thread : 
shared_ptr< MyClass > global_ptr(createNewObject()) ;

WriterThread :
global_ptr.reset( createNewObject())


ReaderThreads:
weak_ptr<MyClass> local_weak_ptr (globally_ptr) ;
...

if(shared_ptr< MyClass > local_shared_ptr = local_weak_ptr.lock() ) {
 // using local_shared_ptr.
} else {
    // recreate weak ptr from global ?
}



thanks.

Rajeev

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Permalink | Reply | 16 comments |
headers
ajb | 1 Sep 2009 02:42
Favicon
Gravatar

Re: [Math] Fractional binomial_coefficient

G'day Ralf.

Quoting "Ralf M." <rm <at> amitrader.com>:

> the binomial coefficients are usually used with integers,
> but it is also possible to get the binomial coefficient
> of real values (cf. http://en.wikipedia.org/wiki/Binomial_coefficient ).
>
> Maybe this could be added to the boost math library.
> Here's a sample implementation using standard g++:
>
> template <class T> T Choose(T n, T k)
> {
>  return exp(lgamma(n + 1.0) - lgamma(k + 1.0) - lgamma(n - k + 1.0));
> }

Boost.Math almost has it:

#include <boost/math/special_functions/beta.hpp>

template<typename RealType>
RealType
binomial(RealType n, RealType k)
{
     return 1.0 / ((n+1) * boost::math::beta(n - k + 1, k + 1));
}

There is also binomial_distribution and beta_distribution if that's
what you're really after.

Cheers,
Andrew Bromage
Permalink | Reply | 0 comments |
headers
Nat Goodspeed | 1 Sep 2009 02:56
Favicon

Re: Correct use of unordered_map

Richard Hadsell wrote:

>> I use one of these 2 ways:
>>
>> for (my_map_t::iterator it= my_map.begin(); it != end; ) {
>>  if (is_to_be_removed(it->first))
>>   it = global_map.erase (it);
>>  else
>>   ++it;
>> }
>>
>> for (my_map_t::iterator it= my_map.begin(); it != end; ) {
>>  my_map_t::iterator itx = it++;
>>  if (is_to_be_removed(itx->first))
>>   global_map.erase (itx);
>> }

> I should add that the second way is useful, when you are not executing 
> 'erase' but rather some arbitrary code that may or may not actually 
> erase the element from the container.

nod

I can't resist pointing out Scott Meyers's "Effective STL," Item 9, p. 
43: "Choose carefully among erasing options."  :-)
Permalink | Reply | 0 comments |
headers
Neal Becker | 1 Sep 2009 02:59
Picon

Re: cycle iterators

er wrote:

> I'm not sure if I already asked in a private conversion, but even if I
> did, this the occasion to ask again : why not have an assignment
> operator for cycle_iterator? I think the base iterator could be replaced
> by that which is contained in super_t.

Would not the default compiler-generated assignment operator work?
Permalink | Reply | 9 comments |

Gmane