- Boost-users - lists.boost.org

[chrono] Compilation with MinGW/gcc 4.4.0
by Richard Hazlewood 14 Oct '11

14 Oct '11

I've been trying to compile the chrono "hello world" example with MinGW/GCC 4.4.0, but it fails. I then tried to compile the tests, and saw similar errors. The docs say this compiler is supported, has anyone else tried this? Here's the error chain: .\boost_1_47_0/boost/type_traits/common_type.hpp: At global scope: .\boost_1_47_0/boost/type_traits/common_type.hpp: In instantiation of 'boost::common_type<double, long long int, long long int>': .\boost_1_47_0/boost/chrono/duration.hpp:252: instantiated from 'ToDuration boost::chrono::detail::duration_cast_aux<FromDuration, ToDuration, Period, true, false>::operator()(const FromDuration&) const [with FromDuration = boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> >, ToDuration = boost::chrono::duration<double, boost::ratio<1ll, 1ll> >, Period = boost::ratio<1ll, 10000000ll>]' .\boost_1_47_0/boost/chrono/duration.hpp:311: instantiated from 'ToDuration boost::chrono::detail::duration_cast<FromDuration, ToDuration>::operator() (const FromDuration&) const [with FromDuration = boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> >, ToDuration = boost::chrono::duration<double, boost::ratio<1ll, 1ll> >]' .\boost_1_47_0/boost/chrono/duration.hpp:472: instantiated from 'boost::chrono::duration<Rep, Period>::duration(const boost::chrono::duration<Rep2, Period2>&, typename boost::enable_if<boost::mpl::or_<boost::chrono::treat_as_floating_point<Rep>, boost::mpl::and_<boost::chrono::chrono_detail::is_evenly_divisible_by<Period2, Period>, boost::mpl::not_<boost::chrono::treat_as_floating_point<Rep2> >, mpl_::bool_<true>, mpl_::bool_<true>, mpl_::bool_<true> >, mpl_::bool_<false>, mpl_::bool_<false>, mpl_::bool_<false> >, void>::type*) [with Rep2 = long long int, Period2 = boost::ratio<1ll, 10000000ll>, Rep = double, Period = boost::ratio<1ll, 1ll>]' ...\test.cpp:96: instantiated from here .\boost_1_47_0/boost/type_traits/common_type.hpp:77: error: no type named 'type' in 'struct boost::common_type<double, long long int, void>'

3 4

Problem with Spirit Qi and inherited attributes reference
by Anand kumar 14 Oct '11

14 Oct '11

Hello, This is my first time using boost and spirit. I am trying to find construct a tree from a string input. While parsing I am trying to assign each created node a number. For this purpose I am using a inherited attribute, an integer reference. But when I check on the values assigned. It is not the value of the integer reference rather some other value (some consistent value). I am sure this must be something that I am overlooking. But I am not sure what exactly. Thanks for your help, Anand Kumar. Code: struct node; struct term { bool visited; int cnt; int val; term(bool b = false, int cn = -1, int v = numeric_limits<int>::min()) { visited = b; cnt = cn; val = v; } }; BOOST_FUSION_ADAPT_STRUCT( ::term, (bool, visited) (int, cnt) (int, val) ) typedef boost::variant<term, boost::recursive_wrapper<node>> node_impl; struct node { bool visited; int cnt; vector<node_impl> children; }; BOOST_FUSION_ADAPT_STRUCT( ::node, (bool, visited) (int, cnt) (std::vector<::node_impl>, children) ) template<typename Iterator> struct node_parser : qi::grammar<Iterator, node(), ascii::space_type> { qi::rule<Iterator, node(), ascii::space_type> start_r; qi::rule<Iterator, node(int&), ascii::space_type> node_r; qi::rule<Iterator, node_impl(int&), ascii::space_type> node_impl_r; node_parser() : node_parser::base_type(start_r) { using qi::int_; using qi::lexeme; using namespace qi::labels; using phoenix::ref; int cnt = 990; start_r %= node_r(phoenix::ref(cnt)); node_r = ('{' >> +node_impl_r(_r1) >> '}') [at_c<0>(_val) = false, at_c<1>(_val) = _r1++, at_c<2>(_val) = _1]; node_impl_r = ((lexeme['(' >> int_ >> ')'])[_val = phoenix::construct<term>(phoenix::val(false), _r1++, _1)]) | (node_r(_r1)[_val = _1]); } };

1 0

Regarding building of boost1.38.0 with aCC ( Hp compiler)
by Pravar 14 Oct '11

14 Oct '11

Hi *, I am trying to build *boost1.38.0* with *aCC A.0.17* ( HP compiler). I need to understand a few details: - Does in older boost versions, *build process* is a bit different ? I think it is as I can not found any bootstrap.sh in boost root directory. - Does $BOOST_ROOT./configure is equivalent to $BOOST_ROOT./bootstrap.sh in latest versions ? I executed following commands during building of boost 1.38.0 : - From boost root directory, ./configure --prefix=/opt/boost, I get following output, ----------------------------------------------------------------------- -n Building Boost.Jam with toolset acc... tools/jam/src/bin.hpuxia64/bjam ----------------------------------------------------------------------- - Then, I changed directory to tools/jam/src/bin.hpuxia64/bjam. I tried to build by executing ./bjam /some build options/ I get below error, *------------------------------------------------------- notice: could not find main target install notice: assuming it is a name of file to create. don't know how to make <e>install ...found 1 target... ...can't find 1 target... --------------------------------------------------------* Is there something i am missing ? Any inputs would be helpful. Best Regards, Pravar DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . -----------------------------------------------------------------------------------------------------------------------

1 0

[thread] UpgradeLockable Concept & Writer Starvation
by Ovanes Markarian 14 Oct '11

14 Oct '11

Hello *, I was reading through the docs of boost::thread lib and I can't find any guarantees that when using upgrade_lock the writer (upgrader) starvation is prevented. Are there any ordering guarantees, that if some thread is going to upgrade the lock the threads which acquire the shared lock after the upgrade request will not be able to acquire the lock until the upgrade request was accomplished and released the lock? Many thanks for help, Ovanes

1 0

Problem using special mathematical function in Visual C++
by Keith Fraser 13 Oct '11

13 Oct '11

Hello, I downloaded Boost in order to use the expint function: http://www.boost.org/doc/libs/1_37_0/libs/math/doc/sf_and_dist/html/math_to… I copied the /boost folder into the /include folder in Visual C++ where the other library files (stdio.h, etc.) are kept. In the .cpp file for the program I wanted to use expint in, I inserted the following line, taken from the description: #include <boost/math/special_functions/expint.hpp> When compiling, Visual C++ appears to be able to open expint.hpp, but it doesn't recognize the function: error C3861: 'expint': identifier not found Is there something else I need to add to the .cpp file so that expint will be recognized? I am using Visual C++ 2010 Express. Thanks, Keith

2 2

[lexical_cast] Fast conversion from boost::iterator_range<std::string::iterator>?
by Michel Morin 13 Oct '11

13 Oct '11

lexical_cast made optimizations for some types (such as `std::string`) to achieve better performance. But, from my experience, it seems that lexical_cast does not make any optimization for `boost::iterator_range<std::string::iterator>`. Is there any plan to add optimization for such iterator ranges? Currently, - `lexical_cast<int>(std::string(iter_rng.begin(), iter_rng.end()))` is faster than `lexical_cast<int>(iter_rng)`. - Assuming it is safe to use `std::atoi`, `std::atoi(&iter_rng.front())` is faster than both of the above two methods. (`iter_rng` is an instance of `boost::iterator_range<std::string::iterator>`.) Regards, Michel

1 0

[xpressive] treating special literals as non-regex
by Ovanes Markarian 13 Oct '11

13 Oct '11

Hello *, I ran into a problem, that I use some regex to split a string by some delimiters. My interface to the outer world is non-regex. A user can pass anything like delimiter. E.g. $d$ can be a valid delimiter. If I use sregex_token_iterator with regex created as: as_xpr("$d$") are $ treated as regex special characters and I have to escape them or can I safely use them in this context? If I have to escape the special characters is there any helper function like protect("$d$"). Many thanks for help, Ovanes

1 1

help with boost::spirit:parsing out a list of menuitems
by Littlefield, Tyler 13 Oct '11

13 Oct '11

Hello: I have a client I'm writing, where the server sends data to the client to display as a menu in one instance. I wanted to use boost::spirit to parse this out. So, here's the code. I have three questions: 1) What can I do better/differently? 2) When I parse out my menuitem, if there's no flag, can it be set to 0 by default somehow? 3) Where is menuitem returned? Is there a way I can push it to a queue since I'll have more? My actual parser will look something like: pstart >> item >> *(delem >> item) >> pend; Here is the code I have currently: struct menuitem { std::string name; int flag; int choice; }; BOOST_FUSION_ADAPT_STRUCT( menuitem, (std::string, name) (int, flag) (int, choice)) namespace ascii = boost::spirit::ascii; namespace qi = boost::spirit::qi; //I'd like to just take a char* here, since that's my payload. copying the char* to a std::string will take extra time, is there a way to do that? BOOL Menu::Parse(const std::string &data, int length) { std::string::const_iterator it, itEnd; it = data.begin(); itEnd = data.end(); //we construct a few parsers to make things easier. qi::rule<std::string::const_iterator, char, ascii::space_type> pstart = qi::char_('['); qi::rule<std::string::const_iterator, char, ascii::space_type> pend = qi::char_(']'); qi::rule<std::string::const_iterator, char, ascii::space_type>delem = qi::char_('|'); qi::rule<std::string::const_iterator, menuitem(), ascii::space_type>item = qi::char_("a-zA-Z0-9 -.?!$@") >> qi::char_('(') >> -qi::int_ >> qi::char_(':') >> qi::int_ >> qi::char_(')'); if (!qi::phrase_parse(it, itEnd, pstart >> item >> pend, ascii::space)) { return false; } return true; } -- Take care, Ty Web: http://tds-solutions.net The Aspen project: a light-weight barebones mud engine http://code.google.com/p/aspenmud Sent from my toaster.

3 3

Boost message_queue: when I receive an object, how can I remove it from the queue?
by pietro 13 Oct '11

13 Oct '11

I noticed that, when I get an object from a Boost message_queue with the *receive() member functions, that object remains in the queue. So if I read the same message_queue multiple times, I keep getting copies of the same objects, even if nothing has been inserted from the producer's side. Is there a way to remove an object from the queue once it has been read? In message_queue I found no member function that allows to do it. E.g.: (this is pseudo code; the consumer is shown and the producer would be in a separate process) boost::scoped_ptr<boost::interprocess::message_queue> pMQueue; message_queue::remove("myQueue"); pMQueue.reset(new message_queue(open_or_create, "myQueue", 100, sizeof(MyClass))); MyClass token; std::vector<MyClass> tokens; size_t recvdSize = 0; float timeDelay = 100; // milliseconds bool dataAvailable = true; // If I do this block twice, I receive the same tokens twice while(dataAvailable) { ptime t = microsec_clock::universal_time() + milliseconds(timeDelay); dataAvailable = pMQueue->timed_receive(&token, sizeof(token), recvdSize, 0, t); if(dataAvailable && recvdSize > 0) tokens.push_back(token); else ... } Note: in this example, MyClass' objects are fixed sized POD member variable objects only. -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-message-queue-when-I-receive-an-ob… Sent from the Boost - Users mailing list archive at Nabble.com.

1 1

[graph] vertex property Graph type cyclic definition problem. forward declaration not possible.
by Christoph 13 Oct '11

13 Oct '11

Hi, i would like to use the bundled properties feature of the boost graph library to specify the vertex properties of my graph. The problem is that i would like to have some graph type dependent descriptor type map defined within these vertex properties. Here is the example: // begin code #include <iostream> #include <boost/graph/adjacency_list.hpp> struct vertex_properties { vertex_properties () : color (-1) {} int color; std::list <int> free_colors; std::map<int,link_graph_traits::edge_descriptor> used_colors; // this is a cycle def problem }; struct edge_properties { edge_properties () : color (-1) {} int color; }; struct graph_properties { int delta; }; typedef boost::adjacency_list < boost::listS, boost::vecS, boost::bidirectionalS, vertex_properties,// this is a cycle problem edge_properties, graph_properties> link_graph; typedef boost::graph_traits <link_graph> link_graph_traits; int main(int argc, char** argv) { link_graph g; return 0; } // end code This example won't compile because the 'struct vertex_properties' contains a variable declaration of a std::map which contains the type ('link_graph_traits::edge_descriptor') as a template parameter that is not defined yet. I tried to forward declare the 'struct vertex_properties;' and move the definition of 'struct vertex_properties {...};' behind the graph type definition but then the compiler complained about. The forward declaration code, that does not compile, too follows: // begin code #include <iostream> #include <boost/graph/adjacency_list.hpp> struct vertex_properties; struct edge_properties { edge_properties () : color (-1) {} int color; }; struct graph_properties { int delta; }; typedef boost::adjacency_list < boost::listS, boost::vecS, boost::bidirectionalS, vertex_properties, edge_properties, graph_properties> link_graph; typedef boost::graph_traits <link_graph> link_graph_traits; struct vertex_properties { vertex_properties () : color (-1) {} int color; std::list <int> free_colors; std::map <int, link_graph_traits::edge_descriptor> used_colors; }; int main(int argc, char** argv) { link_graph g; return 0; } // end code I do not want to use (void*) and std::reinterpret_cast to work around this problem. I hope that you can help me with a technique not using casts. I assume that there may be a possibility to first declare the graph type without the vertex_properties struct and then 'adding' the vertex_propterties struct after defining the graph. best regards Christoph

2 2