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

An error in MTL4(Matrix template Library).Can anyone with kindness help me?
by fmingu 18 May '10

18 May '10

I am using Dev-C++ with gcc 4.4.1 and boost 1.37.0 and MTL 4 (MTLVERSION 4\nMTLRELEASE beta-1\nMTLREVISION 6916 ) for matrix computation. And my code is the following : #define MATRIXCOLS 3 #define MATRIXROWS 3 #include <boost/numeric/mtl/mtl.hpp> using namespace mtl; using namespace mtl::matrix; typedef dense2D<double> Matrix; typedef dense_vector<double> Vec; ................................. using namespace mtl; using namespace mtl::matrix; const unsigned xd= 2, yd= 5, n= xd * yd; Matrix Kk(n,n),Hk(n,n),Rk(n,n);hessian_setup(Kk, 3.0);hessian_setup(Hk, 3.0); Rk=trans(Hk); Vec hxkk_1(n,0.0),zk(n,0.0),hxkk(n,0.0),hxkk_11(n,0.0); hxkk=zk-Hk*hxkk_1; hxkk= Kk*hxkk; //the * line ............................... and it is complied OK. But when it ran to the (*) line the result is : This application has requested the Runtime to terminate it in an unusual way, please contact the application's support team for more information. I found that the mailinglist in http://osl.iu.edu/research/mtl/mtl4/ is quite a place that almost no letters. When I use hxkk*=Kk; instead of the * line,even it can not be complied. So I write letter here for any experts to give me some advices. Can any one with kindness help me?

1 0

Re: [Boost-users] [Asio]Question about error_code when socket::close
by Comet 18 May '10

18 May '10

> BTW, you also can try to use a trivial custom allocator that would > eliminate some heap allocations in completion handlers (unrelated to > shared_ptr): > http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/example/allocation… Thanks! that would be very helpful.

1 0

shared_ptr question
by David Michael Bond 18 May '10

18 May '10

Hello, I am learning shared_ptrs and I am running into a segfault. I'm fairly certain it's because of some misunderstanding I have. Here is some code. I have altered it to just so the relevant data: ---- START CODE ---- std::deque<boost::shared_ptr<Frame> > processing_queue ; void this_is_called() { boost::shared_ptr<Frame> rx ; interface->open( "eth0" ) ; while( running ) { interface->rx_frame( this->processing_queue ) ; if( !processing_queue.empty( ) ) { rx = processing_queue.back( ) ; if( rx ) { std::cout << "Received Frame of Ethertype " << ntohs( rx->get_ether_header( ).ether_type ) << "." << std::endl ; } } } } } // rx frame from interface and add onto processing_queue boost::shared_ptr<Frame> last_rx_frame ; // (CLASSXX member) void CLASSXX::rx_frame( std::deque<boost::shared_ptr<Frame> >& processing_queue ) { // Do some stuff to receive frame.. (int size= # bytes in frame) last_rx_frame.reset(new Frame( )) ; last_rx_frame->bytes.reset( new u_char[size]) ; memcpy( last_rx_frame->bytes.get(), frame_bytes, size) ; last_rx_frame->size = size ; processing_queue.push_back( this->last_rx_frame ) ; } ---- END CODE ---- The program receives one frame and successful and outputs it: Received Frame of Ethertype 0x800. But the second time when it gets to 'rx = processing_queue.back( ) ;' I have a segfault. My understanding of shared_ptrs is that when this assignment is done rx will have its ref count decremented (possibly leading to it being deleted). The back of the processing_queue will then become rx do to the assignment and that shared ptrs reference count will be increased by one. Anyone know what my misconception is? Any idea what's causing the segfault? Thanks! -David

1 0

Please help with rebuild on Windows
by John Dlugosz 18 May '10

18 May '10

I want to use the program-options library, and the copy of boost used by this application suite is 1.38. Using Visual Studio 2008, debug build, the resulting program crashes in the variables_map constructor. My assumption is that the compiler options don't match: in particular, a stupid thing called _HAS_ITERATOR_DEBUGGING=0 is infectious as it causes the STL to generate different code and different sized objects. The layout of the boost files doesn't match the documentation, in that bjam.exe is in a subdirectory, and there is no such thing as bootstrap. Anyway, I try: D:\boost_1_38_0> bin\bjam link=static threading=multi variant=debug toolset=msvc-9.0 --define=_HAS_ITERATOR_DEBUGGING=0 Libs\program_options\build and it indeed makes a file with the same name as the one my program is linking to: libboost_program_options-vc90-mt-gd-1_38.lib, which I copy over the original. It made no difference. I don't think that's the specific problem, though, since it crashes on the constructor, not on some later usage from a different translation unit. The call tree is: foo.exe!std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,boost::program_options::variable_value,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,boost::program_options::variable_value> >,0> >::_Init() Line 1180 + 0xe bytes foo.exe!std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,boost::program_options::variable_value,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,boost::program_options::variable_value> >,0> >::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,boost::program_options::variable_value,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,boost::program_options::variable_value> >,0> >(const std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > & _Parg=less, const std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,boost::program_options::variable_value> > & _Al={...}) Line 511 foo.exe!std::map<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,boost::program_options::variable_value,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,boost::program_options::variable_value> > >::map<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,boost::program_options::variable_value,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,boost::program_options::variable_value> > >() Line 104 foo.exe!boost::program_options::variables_map::variables_map() Line 172 + 0x40 bytes foo.exe!main(int argc=1, char * * argv=0x01f84190) Line 179 + 0xb bytes TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

3 7

[filesystem] iterator VC 10.0
by Commander Pirx 17 May '10

17 May '10

Hi, I tried to compile the following lines with VC 10: void path_adapter::convert( const boost::filesystem::path& p) { typedef boost::filesystem::path::const_iterator const_path_iterator; for (const_path_iterator pos = p.begin(); pos < p.end(); ++pos) { //... } } and got the error: error C2039: 'distance_to': is not an element of 'boost::filesystem::basic_path<String,Traits>::iterator' Seems to be a problem of the new iterator facade implementation. I had no trouble with this method until Boost 1.43.0. Any idea how to fix this? Pirx!

2 2

BOOST_FIXTURE_TEST_SUITE problem
by Olaf Peter 17 May '10

17 May '10

Hi, the simple snippet doesn't compile on 1.43 or trunk: #include <boost/test/unit_test.hpp> struct F { F() : i( 0 ) { BOOST_TEST_MESSAGE( "setup fixture" ); } ~F() { BOOST_TEST_MESSAGE( "teardown fixture" ); } int i; }; BOOST_FIXTURE_TEST_SUITE( s, F ) $ g++ -I ../boost/1.43/include/ rr.cpp -c rr.cpp:10: error: expected ‘}’ at end of input which results into: ... namespace s { static boost::unit_test::ut_detail::auto_test_unit_registrar s_registrar10( "s" ); typedef F BOOST_AUTO_TEST_CASE_FIXTURE; where the closing '}' is really missing. Does I miss something? Thanks, Olaf

2 1

Re: [Boost-users] Boost-users Digest, Vol 2362, Issue 3
by NuSkooler 17 May '10

17 May '10

> Are you using the trunk's version of STLPort? The STLPort in trunk has > modifications for use in android. Though it assumes it doesn't have RTTI > and exceptions. > You would need to add -D__ANDROID__ as well, since it is this that > STLPort checks for. > I'm still trying to compile and your email was *very* valuable. > Maybe creating a android.jam in the tools/ dir in boost.build would be > better. Glad the post has been helpful -- I probably should have re-tested without the STLPort references. Originally I had been using the standard non-modified NDK and the STLPort from the "ndk-wrappers" posts found on the NDK group. Later I found RTTI and exceptions just too hard to live without and upgraded to the Crystax modified NDK which contains it's own STL (no need for a external STLPort). I'll try re-compiling without any STLPort references now. A android.jam would be great -- So far I've found the jam build system very overwhelming though... I have no clue where to start on something like that. Bryan

1 0

Re: [Boost-users] [Asio]Question about error_code when socket::close
by 鑫炜廖 17 May '10

17 May '10

> Then you need to do reference counting yourself. You must count pending > asynchronous I/O operations and destroy the object when the counter is > decreased to 0. I don't think there is much else you can do? > Boris Thanks, that's a good idea and what I intended to do. Some what ugly, but can be hidden under the table :-)

2 2

Re: [Boost-users] [Asio]Question about error_code when socket::close
by Comet 17 May '10

17 May '10

> That is because you are most likely using the inefficient creation > style, probably like this: > shared_ptr<myClass> myPtr(new myClass(arg1,arg2)); > Which will also new a struct inside the shared_ptr that holds that > pointer and bookkeeping information. If you have read the shared_ptr > documentation, the efficient creation style is this: > shared_ptr<myClass> myPtr = make_shared<myClass>(arg1,arg2); > Which will new both your class and the bookkeeping information in the > same place in memory, increasing both the speed of creation (only one > new), and speed of accessing (better cache coherency). > When creating your objects at the same time (literally) as the > shared_ptr, that should fix most of those speed issues. That's not the point, make_shared can be used only when the object is created,but what I said is as follows: class Session : public boost::enable_shared_from_this<Session> { public: static void HandleRead(boost::weak_ptr<Session> session, const boost::system::error_code& error, size_t bytes_transferred) { if (session.expired()) return; ... } void Read() { // this line is very slow, // because boost::bind(&Session::HandleRead,shared_from_this(), ...) // causes extra new/delete operations socket_.async_read_some(boost::asio::buffer(...), boost::bind(&Session::HandleRead, shared_from_this(), _1, _2)); ... } void Close() { socket_.close(); } private: boost::asio::ip::tcp::socket socket_; }; std::set<boost::shared_ptr<Session> > session_set; boost::shared_ptr<Session> session = boost::make_shared<Session>(); session_set.insert(session); session->Read(); .... session->Close(); session_set->erase(session); // session is destroyed here, if I replace static void HandleRead(weak_prt ...) with void HandleRead(...) and boost::bind(&Session::HandleRead, shared_from_this()...), with boost::bind(&Session::HandleRead, this, ...); the question I asked emerges: void HandleRead(const boost::system::error_code& error, size_t bytes_transferred) { if (error) //should I erase shared_from_this() from session_set? this object may have been destroyed... } .... session->Close(); session_set->erase(session); // session is destroyed here. if I don't do this here, where should I do ? HandleRead may not be registered ever...

2 1

Re: [Boost-users] [fusion]simple fusion seq_size fails to compile
by Pete Bartlett 17 May '10

17 May '10

>The attached works; however, it just seems a lot of effort for such a simple task. >Anybody have a simpler way? Well, as you said the simpler way is to use the size function provided :-). Also your size implementation is somewhat unsatisfying in the sense that it uses empty which internally uses the library's size (meta)function. In fact I think size has to be implemented as a "core" function (i.e. not built up from other publically available functions) because it is implementation is necessarily quite different for different types of fusion sequence (e.g. array and an MPL sequence). Not an expert, Pete

2 1