November 2011 - Boost-users - lists.preview.boost.org

FW: pbgl install
by Neiderer, Andrew M USA CIV (US) 09 Nov '11

09 Nov '11

________________________________ From: Neiderer, Andrew M USA CIV (US) Sent: Wednesday, November 09, 2011 6:13 AM To: boost-users(a)lists.boost.org Cc: Neiderer, Andrew M USA CIV (US) Subject: pbgl install I have BGL 1.47.0 installed and want to start using parallel BGL. Can someone point me to a URL for describing installation of parallel-bgl-0.7.0. I assume I do the "tar xvf" in the above directory and new files will overwrite. Thank you. Andrew M. Neiderer US Army Research Laboratory

2 1

Limits in MPL and Fusion - bad doc, not checked, could be extended
by Hite, Christopher 09 Nov '11

09 Nov '11

> > 1) I think both test libraries should #error if you go over the limit. > > > > 2) Why don't we extend the limits? > > I may wind up doing this real quick to keep my code working (needs 71). Can I merge the changes into trunk when I'm done and after 1.48 is finished? It took a while, but I found this thread: http://lists.boost.org/boost-users/2006/11/23285.php > I believe that for most libraries, there's a non-trivial increase in > compile-time for any user of the library when you increase the arity of > things. It's config switch. The library user sets BOOST_MPL_LIMIT_VECTOR_SIZE to whatever he needs and sets BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS. The silly thing is there's an undocumented limit which doesn't warn it just complains when it can't include map60. It would be easy to have map50, just use the limit instead of a hard coded 50. That would allow someone who needs just a it to do it. > Bumping up the default could have rather adverse effects on the compile > time of people who doesn't want to pay for it. No, the library is header only. If you leave the limits at 20 you'll include file10 and file20, but no more. I've currently got the hack in my code. It only works if you do it before including any of the standard headers and it's uggly because BOOST_MPL_LIMIT_MAP_SIZE is redefined 50->70. #define ULTIMATE_N 70 #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #include <boost/mpl/map.hpp> #include <boost/mpl/map/map50.hpp> #include <boost/preprocessor/iterate.hpp> namespace boost { namespace mpl { # define BOOST_PP_ITERATION_PARAMS_1 \ (3,(51, ULTIMATE_N, <boost/mpl/map/aux_/numbered.hpp>)) # include BOOST_PP_ITERATE() }} #define BOOST_MPL_LIMIT_MAP_SIZE ULTIMATE_N // do this for each mpl::map, mpl::list, fusion::vector, fusion::map Chris

1 0

phoenix ostream<< result type wrong
by Hite, Christopher 09 Nov '11

09 Nov '11

I'm using Boost version 1.43, perhaps this has been fixed. std::stringstream ss; (boost::phoenix::arg_names::arg1<<1<<2<<3)(ss); BOOST_CHECK_EQUAL(ss.str(),"123"); // check ss.str() == "123" failed [1 != 123] I think what's going on is that the shift operator is returning the int and not the stream. This shouldn't compile, but does: int o=(boost::phoenix::arg_names::arg1<<1<<2<<3)(ss); My use case is a log library which does the actual streaming in non-critical space. Chris

1 0

[Move] unique_ptr
by Szymon Gatner 09 Nov '11

09 Nov '11

Hi, with now accepted Move library, is implementation of unique_ptr<> planned for boost? I used to use Howard Hinnant's implementation so far but got compilation problems as soon as I added Move library to my toolbox. Also, Hinnant's page says: "The following is a dated C++03 emulation of unique_ptr. You may find a better unique_ptr emulation at boost." Does he mean the one in Boost.Interprocess? Regards, Simon

3 10

[operators] operators: +,+= and commutativity
by Ovanes Markarian 09 Nov '11

09 Nov '11

Hello *, I was just considering the operators library to ease implementation effort of += and + operator overloads. Unfortunately, as I found out operator+ is implemented in the library for types with commutative property only. In the docs I see that there are implementations of operators for subtractable_left, dividable_left and modable_left, but not addable_left. In my simple case I would like to use the += operator for string based type to work with my type and string types. What was the design rationale to not provide the addable_left form? Many thanks, Ovanes

1 0

boost 1.43 bimap updating question
by Damian 09 Nov '11

09 Nov '11

Hello. I'm trying to update the data of a left bimap and I keep getting this error message: error: assignment of read-only data-member ‘boost::bimaps::relation::detail::normal_storage<boost::bimaps::tags::tagged<const int, boost::bimaps::relation::member_at::left>, boost::bimaps::tags::tagged<const double, boost::bimaps::relation::member_at::right> >::second’ Here is what I'm doing: int idx = 0; double score = 0.0; typedef boost::bimap<int, double> bm_type; // define the bimap type we will use bm_type bm; bm_type::right_iterator r_iter; bm_type::left_iterator l_iter; bm.insert( bm_type::value_type( 1, 93.9) ); bm.insert( bm_type::value_type( 2, 18.3) ); bm.insert( bm_type::value_type( 3, 4.54) ); bm.insert( bm_type::value_type( 4, 0.343) ); score = 60000.0343; idx = 3; l_iter = bm.left.find(idx); if(l_iter == bm.left.end()) { // this is a new entry so add it bm.insert( bm_type::value_type( idx, score) ); } else { // we have this idx value in the bimap // update the bimap score value only if the current value // of score is greater than what is currently in the bimap // for the same index (idx) value. if( l_iter->second < score ) { l_iter->second = score; } } Can someone tell me what I'm doing wrong? The double value in the map is the only part that needs to be updated and only if a new (higher) score is observed. Thanks, Damian -- ------------------------------------------------------------------------------ Damian Fermin, Ph.D. Pathology Department University of Michigan 4237 Medical Science I 1301 Catherine Ann Arbor, MI 48109-0602 734.615.0302 "There is No Gene for the Human Spirit" -- GATTACA ------------------------------------------------------------------------------

2 1

Limits in MPL and Fusion - bad doc, not checked, could be extended
by Hite, Christopher 09 Nov '11

09 Nov '11

/fs/tools/L3/boost_1_43_0/boost/mpl/list.hpp:36:69: fatal error: boost/mpl/list/list80.hpp: No such file or directory BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS doesn't seem to work if you read the documentation. The doc should say "we have a hard coded limit of 50". /fs/tools/L3/boost_1_43_0/boost/fusion/container/vector/detail/vector_n_chooser.hpp:45:1: error: 'vector80' does not name a type fusion is even worse. It could easily checks FUSION_MAX_VECTOR_SIZE in vector_n_chooser.hpp, but doesn't detect a value that's too big. 1) I think both test libraries should #error if you go over the limit. 2) Why don't we extend the limits? I may wind up doing this real quick to keep my code working (needs 71). Can I merge the changes into trunk when I'm done and after 1.48 is finished? Chris

2 1

pimpl idiom implementation?
by Chris Cleeland 08 Nov '11

08 Nov '11

In wanting to implement a few things using PIMPL I looked in boost for necessary structure. I found several things that use the idiom, but no formal unified implementation. I then stumbled across a Dr. Dobbs article, and the code at https://github.com/sean-/boost-pimpl Anybody know the status of that code and its potential for inclusion in boost? -- Chris Cleeland

3 3

[shared_ptr] Can the custom deleter be a simple function?
by Robert Jones 08 Nov '11

08 Nov '11

The shared_ptr docs suggest that a smart pointer employing a null deleter can be implemented using a functor. Why prefer a functor to a function? Thx, - Rob.

4 6

Re: [Boost-users] [locale] Quick questions
by Jookia 08 Nov '11

08 Nov '11

Ah, thanks. I'm kind of wary of using translate() as it doesn't implictly convert to const char*, so it kind of screws program options up: error: no match for call to ‘(boost::program_options::options_description_easy_init) (const char [7], boost::locale::basic_message<char>)’ Would there be a way to fix this?

1 0