- Boost-users - lists.boost.org

Using boost with 'c' level interfaces ?
by avib369 . 07 Jun '13

07 Jun '13

I can not find any solution where a 'c' api can update/modify a std::vector Passing a std::vector<int>/std::vector<double> to a 'c' or fortran api function, that _reads_, works like a charm. However we are out of luck, if we need the 'c' api, to populate the array. When passing a std::vector will 'kind of' work. But you can never use any of the following // 1/ size() // 2/ empty() // 3/ begin()/ end()/ rbegin()/rend() // 4/ push_back() // 5/ pop_back() You have to separately carry the size of the vector, in order to use it. You then just end up using it like a 'c' array. I thought there may have been way of updating the vectors begin/finish after the api call. But there does not appear to any way to do this. One solution would be to use 'c' array when calling the interface, and then copy to a std::vector. However this would degrade performance, when dealing large data sets. Is there any boost libraries/containers that are applicable or that can handle this issue ? It must have similar properties to a vector, like contiguous memory ? I have included a sample program below, to demonstrate. Before resorting back to 'c' array I was wondering if any one else has come across this problem ? Ta, Avi ============================================================= #include <vector> #include <string> #include <string.h> // memcopy #include <stdlib.h> // malloc #include <iostream> #include <ostream> using namespace std; void c_function_that_reads(int* array, int size_of_array) { for(int i = 0; i < size_of_array; i++) cout << array[i] << ","; cout << "\n"; } void c_function_that_writes(int* array, int size_of_array) { for(int i = 0; i < size_of_array; i++) array[i] = i; } int main(){ { cout << "\ncalling c_function_that_reads\n"; vector<int> dataVec; dataVec.push_back(1); dataVec.push_back(22); c_function_that_reads(&dataVec[0],dataVec.size()); } { cout << "\ncalling c_function_that_writes\n"; int the_size = 10; int* int_array = (int*)malloc(the_size*sizeof(int)); c_function_that_writes(int_array,the_size); // Copy into vector. vector<int> dataVec; dataVec.insert(dataVec.end(), &int_array[0], &int_array[the_size]); for(size_t i = 0; i < dataVec.size(); i++) { cout << dataVec[i] << ","; } cout << "\n"; free(int_array); } { cout << "\ncalling c_function_that_writes\n"; int the_size = 10; vector<int> dataVec; dataVec.reserve(the_size); c_function_that_writes(&dataVec[0],the_size); cout << "dataVec.size() = " << dataVec.size() << ", dataVec.capacity() = " << dataVec.capacity() << " dataVec.empty() = " << dataVec.empty() << "\n"; cout << "for(size_t i = 0; i < dataVec.size(); i++): BROKEN\n"; for(size_t i = 0; i < dataVec.size(); i++) { cout << dataVec[i] << ","; } cout << "\n"; cout << "for(size_t i = 0; i < the_size; i++): WORKS\n"; for(int i = 0; i < the_size; i++) { cout << dataVec[i] << ","; } cout << "\n\n"; cout << "for(vector<int>::iterator i = dataVec.begin(); i != dataVec.end(); i++): BROKEN\n"; for(vector<int>::iterator i = dataVec.begin(); i != dataVec.end(); i++) { cout << (*i) << ","; } cout << "\n"; dataVec.push_back(11); the_size += 1; // dataVec.pop_back(); the_size -= 1; // also broken cout << "for(size_t i = 0; i < dataVec.size(); i++): BROKEN\n"; for(size_t i = 0; i < dataVec.size(); i++) { cout << dataVec[i] << ","; } cout << "\n"; cout << "for(size_t i = 0; i < the_size; i++): BROKEN\n"; for(int i = 0; i < the_size; i++) { cout << dataVec[i] << ","; } cout << "\n\n"; cout << "for(vector<int>::iterator i = dataVec.begin(); i != dataVec.end(); i++): BROKEN\n"; for(vector<int>::iterator i = dataVec.begin(); i != dataVec.end(); i++) { cout << (*i) << ","; } cout << "\n"; // Using std::vector is ok for read only access when calling a c api function // *however* Using a c/fortrans api to *populate* a std::vector leads to issues: // // The following will not work after the api call. // 1/ size() // 2/ empty() // 3/ begin()/ end()/ rbegin()/rend() // 4/ push_back() // 5/ pop_back() // 6/ will ~vector() work since that use begin()/end() ?? // Is it worth using std::vector, since many of invariants are broken ???? // We have to carry the length separately } }

3 2

All talks for Meeting C++ 2013 are online!
by Jens Weller 06 Jun '13

06 Jun '13

1 0

Re: [Boost-users] [1.54.0] Beta 1 Available
by Cromwell Enage 06 Jun '13

06 Jun '13

Hi, all. When calling the merge() member function of a boost::heap::d_ary_heap, is the heap passed in not supposed to be emptied? Here's my test program: ['' #include <boost/heap/d_ary_heap.hpp> #include <boost/heap/binomial_heap.hpp> #include <boost/heap/fibonacci_heap.hpp> #include <boost/heap/pairing_heap.hpp> #include <boost/heap/skew_heap.hpp> #include <boost/test/minimal.hpp> template <typename Heap> void test_heap_merge_memfun() { Heap heap_1, heap_2; heap_1.push(3); heap_1.push(5); heap_1.push(1); heap_2.push(2); heap_2.push(4); heap_2.push(0); heap_1.merge(heap_2); std::cout << " heap_2"; if (!heap_2.empty()) { BOOST_CHECK(4 == heap_2.top()); heap_2.pop(); BOOST_CHECK(2 == heap_2.top()); heap_2.pop(); BOOST_CHECK(0 == heap_2.top()); heap_2.pop(); std::cout << " not"; } std::cout << " emptied." << std::endl; BOOST_CHECK(heap_2.empty()); BOOST_CHECK(5 == heap_1.top()); heap_1.pop(); BOOST_CHECK(4 == heap_1.top()); heap_1.pop(); BOOST_CHECK(3 == heap_1.top()); heap_1.pop(); BOOST_CHECK(2 == heap_1.top()); heap_1.pop(); BOOST_CHECK(1 == heap_1.top()); heap_1.pop(); BOOST_CHECK(0 == heap_1.top()); heap_1.pop(); BOOST_CHECK(heap_1.empty()); } int test_main(int argc, char** argv) { test_heap_merge_memfun< boost::heap::d_ary_heap< int , boost::heap::arity<4> , boost::heap::mutable_<true> > >(); test_heap_merge_memfun<boost::heap::binomial_heap<int> >(); test_heap_merge_memfun<boost::heap::fibonacci_heap<int> >(); test_heap_merge_memfun<boost::heap::pairing_heap<int> >(); test_heap_merge_memfun< boost::heap::skew_heap<int,boost::heap::mutable_<true> > >(); return 0; } ''] When I run this program, I see that all the other heap types empty the heap passed in. I use gcc 4.2.1 with Apple clang version 4.0 on MacOSX 10.8 Cromwell D. Enage

1 0

[Iostreams] Safely returning filtering_istream from function
by Szymon Gatner 06 Jun '13

06 Jun '13

Hi, I would like to return filtering_istream via std::unique_ptr<std::iostream> so that client code can just use iostream interface without knowing what is actual stream type. Inside the factory function filtering_istream is prepared with possible filters attached. Problem is filters are attached by reference. My question is: how to elegantly attach filters to a filtering_istream so that they live as long as filtering_istream itself? How to attach a filter via shared_ptr for example? Regards, Szymon Gatner

2 3

Trouble with posix_time
by Davies, John 06 Jun '13

06 Jun '13

I'm trying to time part of my program and coming up with something I can't explain. I don't expect great accuracy with the sample code here. But I'd like to understand what is happening. static boost::posix_time::ptime MillisecondsFromNow(int milliseconds) { return(boost::posix_time::ptime(boost::posix_time::second_clock::universal_time()) + boost::posix_time::milliseconds(milliseconds)); } Code segment: nanosecond_type const twenty_seconds(20 * 1000000000LL); cpu_timer timer; long count = 0; while(true) { boost::thread::sleep(MillisecondsFromNow(1000)); cpu_times const elapsed_times(timer.elapsed()); nanosecond_type const elapsed(elapsed_times.wall); if (elapsed >= twenty_seconds) { break; } count++; } std::cout << count << '\n'; So I'm running for 20 seconds and delaying each time for a second. So I would expect to get output of 19, maybe 20 or 18. Instead I'm getting around 38-40 I've tried .system and .user and get different values. But never something close to 20. This is on Windows. ___________________________________ John Davies Contractor Home Respiratory Care Philips Home Healthcare Solutions 1740 Golden Mile Highway Monroeville, PA 15146 Email: john.davies(a)philips.com Fax: 724-387-4109 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

2 1

[DNS] Heads up: svn.boost.org moving to a new server; IP address changing
by Beman Dawes 05 Jun '13

05 Jun '13

At 2:00 pm Eastern US time (i.e 30 minutes from now) we will switch svn.boost.org to a new server with a new IP address. It would be best to hold off on any SVN commits until after the change over, and after your DNS server has the new IP address. If command line "ping svn.boost.org" is going to [129.79.245.252], you are still getting the old IP address. Once svn.boost.org is resolving to [129.79.13.13] it should be OK to resume normal Subversion activity. Thanks, --Beman

1 2

[iostreams] C++ 11 moving semantics
by Ovanes Markarian 05 Jun '13

05 Jun '13

Hello *, I am wondering if latest boost iostreams implementation (1.53) supports C++ 11 moving semantics. I would like to create a tee_device and related stream in a separate function and hide the complexity from the user and just return a stream object which moved out of the function. Any ideas how to do that, without using heap and returning smart pointers? Thanks for your help, Ovanes

1 0

[program_options] Config file and/or response file
by Michael Powell 05 Jun '13

05 Jun '13

Hello, Couple of questions about program options config file (and/or response file). I've got an options set that is starting to get fairly verbose, it's rich, but is also impractical to expect users to type that many options. So I would like to capture some (or all) of those options in one or more different config files, depending on the options that need to be set for a given session. With config files, can the parse_config_file method build a vector of options? For instance if I define "value" as vector<int>, can I specify value=1, value=2, value=3 and expect {1,2,3}? Or does the convention go something like this, value=1 2 3, and so on? Next, how does the parse_config_file method treat boiler plate iterative sections? In other words, if I've got a pattern and would like to capture zero or more of that pattern: [pattern] name=test param=1 expected=2 actual=3 [pattern] name=result param=4 expected=5 actual=6 Those might inform a vector<pattern> type concern downstream of the parser. Possible? Third, in a response file, there is a statement about "limitations", which was left at that. Can we be more specific? What kind of limitations are we talking about? Obvious ones like the delimiters between tokens come to mind, but other than that, that's a nebulous statement at best. Thank you. Regards, Michael Powell

2 1

Nesting bind with shared_ptr<T>::operator* and ref
by Chris Stankevitz 04 Jun '13

04 Jun '13

Hello, Can you please help me uncomment out the last "bind" of the program pasted below? The problem is that it will require some kind of mechanism to dereference the shared_ptr. Thank you, Chris === #include <boost/bind.hpp> #include <boost/function.hpp> #include <boost/make_shared.hpp> #include <boost/shared_ptr.hpp> #include <boost/utility.hpp> using namespace boost; struct C : noncopyable { C() {} void f() {} }; shared_ptr<C> GetC(int) { return make_shared<C>(); } int main() { function<void(C&)> x = bind(&C::f, _1); function<void(shared_ptr<C>)> y = bind(&C::f, _1); // Call x after first computing 42, GetC, and shared_ptr::operator* x(*GetC(42)); // Same as above, but with bind and ref bind(x, ref(*GetC(42)))(); // Similar to above, but delay calling 42, GetC, shared_ptr::operator*, // and ref until later. Also use y (takes a shared_ptr) vs x (that takes // a reference) bind(y, bind(GetC, _1))(42); // Same as above, but use x vs y // todo: add call to operator* // todo: add call to ref // // bind(x, bind(GetC, _1))(42); return 0; }

2 3

[Spirit] Stack overflow, suspect infinite recursion
by Simon 03 Jun '13

03 Jun '13

Hi, I'm writing a math string parser with boost::spirit and I'm stuck on this stack overflow. I've seen this before when I wrote a rule that was misleading. It's the second time I get these and I'm really not sure how I can troubleshoot this kind of problem. Help would be greatly appreciated. I have no issues parsing the forms "A?B" (where A,B are floats and ? is an arithmetic operator +,-,*,/). No issues parsing "(A)" either... At the moment of writing this, I haven't tried but I will be trying to parse simpler forms like "(A)?B" and "A?(B)", "(A?B)", "(A?B)?C" and "A?(B?C)"... I suspect going through them will eventually help me fix the bug with the form below... Below is the final output of my program through valgrind and the rules I have are at the end of my post. I suspect the prob is in the definition for start, operation or operand (an operand may be the result of an operation and an operation is performed on operands). There may be a nasty infinite recursion between operand and operation... The resulting objects are polymorphic and they are correct (as seen when used without spirit). Simon Parsing operations such as ( A?B ) ? ( C?D ) Parsing: (0.1+1.9)+(4.2+6.1) -> (AB=2.000000, CD=10.300000, ABCD=12.300000) ==17013== Stack overflow in thread 1: can't grow stack to 0xb907cfbc ==17013== ==17013== Process terminating with default action of signal 11 (SIGSEGV) ==17013== Access not within mapped region at address 0xB907CFBC ==17013== at 0x13487A: bool boost::spirit::qi::action<boost::spirit::qi::reference<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<char const*, std::string>, std::string ()(), boost::spirit::unused_type, boost::spirit::unused_type, boost::spirit::unused_type> const>, boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::phoenix::composite<boost::phoenix::detail::new_eval<HS::Language::axIdentifier>, boost::fusion::vector<boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> >, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > > >::parse<__gnu_cxx::__normal_iterator<char const*, std::string>, boost::spirit::context<boost::fusion::cons<HS::Language::axIdentifier*&, boost::fusion::nil>, boost::fusion::vector0<void> >, boost::spirit::unused_type, boost::spirit::unused_type const>(__gnu_cxx::__normal_iterator<char const*, std::string>&, __gnu_cxx::__normal_iterator<char const*, std::string> const&, boost::spirit::context<boost::fusion::cons<HS::Language::axIdentifier*&, boost::fusion::nil>, boost::fusion::vector0<void> >&, boost::spirit::unused_type const&, boost::spirit::unused_type const&) const (action.hpp:50) ==17013== If you believe this happened as a result of a stack ==17013== overflow in your program's main thread (unlikely but ==17013== possible), you can try to increase the size of the ==17013== main thread stack using the --main-stacksize= flag. ==17013== The main thread stack size used in this run was 96002048. ==17013== Stack overflow in thread 1: can't grow stack to 0xb907cfb8 ==17013== ==17013== Process terminating with default action of signal 11 (SIGSEGV) ==17013== Access not within mapped region at address 0xB907CFB8 ==17013== at 0x48224AC: _vgnU_freeres (vg_preloaded.c:58) ==17013== If you believe this happened as a result of a stack ==17013== overflow in your program's main thread (unlikely but ==17013== possible), you can try to increase the size of the ==17013== main thread stack using the --main-stacksize= flag. ==17013== The main thread stack size used in this run was 96002048. ==17013== ==17013== HEAP SUMMARY: ==17013== in use at exit: 410,754 bytes in 25,628 blocks ==17013== total heap usage: 25,847 allocs, 219 frees, 437,192 bytes allocated ==17013== ==17013== LEAK SUMMARY: ==17013== definitely lost: 409,080 bytes in 25,571 blocks ==17013== indirectly lost: 432 bytes in 27 blocks ==17013== possibly lost: 1,050 bytes in 20 blocks ==17013== still reachable: 192 bytes in 10 blocks ==17013== suppressed: 0 bytes in 0 blocks ==17013== Rerun with --leak-check=full to see details of leaked memory ==17013== ==17013== For counts of detected and suppressed errors, rerun with: -v ==17013== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Segmentation fault Extract of the grammar: constnum = double_ [_val = new_<axConstant>(_1)]; alpha_numeric = alpha >> +(alnum); ident = alpha_numeric [_val = new_<axIdentifier>(_1)]; operand = ident | constnum | operation; addition = (operand >> lit('+') >> operand) [_val = new_<axAddition>(_1,_2)]; substraction = (operand >> lit('-') >> operand) [_val = new_<axSubstraction>(_1,_2)]; multiplication = (operand >> lit('*') >> operand) [_val = new_<axMultiplication>(_1,_2)]; division = (operand >> lit('/') >> operand) [_val = new_<axDivision>(_1,_2)]; precedence = (lit('(') >> operand >> lit(')')) [_val = new_<axPrecedence>(_1)]; operation = precedence | multiplication | division | addition | substraction; start = operation | operand; } boost::spirit::qi::rule<Iterator, AX*()> start; boost::spirit::qi::rule<Iterator, std::string()> alpha_numeric; boost::spirit::qi::rule<Iterator, axIdentifier*()> ident; boost::spirit::qi::rule<Iterator, axConstant*()> constnum; boost::spirit::qi::rule<Iterator, axOperand*()> operand; boost::spirit::qi::rule<Iterator, axOperation*()> operation; boost::spirit::qi::rule<Iterator, axAddition*()> addition; boost::spirit::qi::rule<Iterator, axSubstraction*()> substraction; boost::spirit::qi::rule<Iterator, axMultiplication*()> multiplication; boost::spirit::qi::rule<Iterator, axDivision*()> division; boost::spirit::qi::rule<Iterator, axPrecedence*()> precedence; };

2 2