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

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

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

08 Nov '11

I made some kind of limited test case: http://www.mediafire.com/?g5axcnch8q20ixo

2 1

[variant] a question about recursive typedef
by gongyiling 08 Nov '11

08 Nov '11

Hello, everyone: I want write a general linked list(any element in the list may be a node or nested general linked list, so recursive). I think general linked list could by defined as following(see spirit's tutorial mini_xml): glist = *glist_node glist_node = node | glist so here is the typedef according to the above rules: struct node { int data; }; typedef boost::variant<node, boost::recursive_wrapper<glist> > glist_node; //typedef 1 typedef std::list<glist_node> glist; //typedef 2 so the problem comes here, in the typedef 1, how can I forward declare glist? I know this is not a problem if I define glist as a struct or class, but I think the all-powerful library must has a beautiful solution, if any one has a solution, please let me know.

3 2