- Boost-users - lists.boost.org

filesystem::recursive_directory_iterator quits on unreadable directory
by Charles Karney 06 Oct '08

06 Oct '08

Version: boost 1.36 Library: filesystem Platform: Linux Compiler: g++ 4.3.0 The increment operator in filesystem::recursive_directory_iterator throws an exception when trying to enter an unreadable directory (permissions, no-such-device, etc.). Often (usually?), a user wants to be able to skip the unreadable directory and continue the iteration over the rest of the directory tree. Catching this exception doesn't help because the iterator hasn't been incremented and I couldn't figure a way to skip over the unreadble directory. The following modification of filesystem/convenience.hpp catches the exception at a low enough level to allow the directory to be skipped over. Is there a better way of handling this? Thanks. --- /usr/local/include/boost-1_36/boost/filesystem/convenience.hpp 2008-09-30 17:34:10.000000000 -0400 +++ boost/filesystem/convenience.hpp 2008-10-02 16:40:43.000000000 -0400 @@ -239,10 +239,15 @@ else if ( is_directory( m_imp->m_stack.top()->status() ) ) { system::error_code ec; - m_imp->m_stack.push( - m_imp->m_no_throw - ? basic_directory_iterator<Path>( *m_imp->m_stack.top(), ec ) - : basic_directory_iterator<Path>( *m_imp->m_stack.top() ) ); + const Path& top = *m_imp->m_stack.top(); + m_imp->m_stack.push(end_itr); + try { + m_imp->m_stack.top() = + m_imp->m_no_throw + ? basic_directory_iterator<Path>( top, ec ) + : basic_directory_iterator<Path>( top ); + } + catch ( ... ) { } if ( m_imp->m_stack.top() != end_itr ) { ++m_imp->m_level; -- Charles Karney <ckarney(a)sarnoff.com> Sarnoff Corporation, Princeton, NJ 08543-5300 URL: http://charles.karney.info Tel: +1 609 734 2312 Fax: +1 609 734 2662

3 3

[MPL] for_each help needed
by Manuel Jung 06 Oct '08

06 Oct '08

Hey, I have problems using mpl::for_each. Well, it works for simple functors, but i need a functor with some context. I'm trying to build a functor through boost::bind. mpl::_1 should be a type from the consensus sequence if evaluated, shouldn't it? You can see a small (hopefully not too small) example below. Kind Regards Manuel class filter{ //[..] // "In" and "Out" are fusion::maps template< typename T > inline const boost::promise_stream<T>& get_promise(){ return fusion::at_key< T >(Out); }; template< typename T > inline void connect(const boost::promise_stream<T> &promise){ fusion::at_key< T >(In).reset(new boost::future_stream< T >(promise)); }; template< typename producer_type > void connect(producer_type Producer){ //[..] // "consensus" is a mpl sequence. mpl::for_each< consensus >(boost::bind(&producer_type::connect, Producer, get_promise< mpl::_1 >())); };

3 2

Cross-compile Boost, python include path problem
by raoul 06 Oct '08

06 Oct '08

Hi everyone, I'm trying to cross compile boost 1.36, and having an issue regarding boost.python compilation. In fact the cross compile is getting right. I'm using this script to cross compile boost: echo "using gcc : i686 : $CC ;" > tools/build/v2/user-config.jam cd tools/jam/src ./build.sh cp bin.*/bjam $BASE_DIR/toolchain/$TOOLCHAIN_VER/$TOOLCHAIN/bin/ cd ../../../ bjam -d2 --toolset=gcc-i686 --prefix=${ROOTFS_DIR}/usr --with-python install Boost.python compiles right, but when I want to link to the created library (libboost_python...) it failes with some strange errors: libboost_python-gcc-mt-1_36.so: undefined reference to `PyUnicodeUCS4_FromEncodedObject' libboost_python-gcc-mt-1_36.so: undefined reference to `PyUnicodeUCS4_AsWideChar' I googled a bit, and it seems that this problem is because libboost_python was not compiled with the same python version than the one I've corsscompiled with. And this is the problem. When reading the boost compilation log: "i686-unknown-linux-gnu-gcc" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -pthread -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DNDEBUG -I"." -I"/usr/include/python2.5" -c -o "bin.v2/libs/python/build/gcc-calaos/release/threading-multi/dict.o" "libs/python/src/dict.cpp" bjam is using the host include path for python (the -I/usr/include/python2.5 option), and this is wrong. How can I force bjam to use ${ROOTFS_DIR}/usr/include/python2.5 for python include path, instead of the one of my host system? I don't know how boost is checking and detecting python cflags. Using python-config? Is there a way to tell bjam to use ${ROOTFS_DIR}/usr/bin/python-config? Thanks, -- ------------------------ Raoul Hecky

2 2

boost::iostream exception
by Lloyd 06 Oct '08

06 Oct '08

Hi, I am trying to decompress a file using boost::iostreams (1.35.0) library built with zlib-1.2.3 . I am able to decompress the file with other utilities but this program throws me an exception saying "gzip error". I am able to uncompress other gzipped files. What could be the reason for the exception? Any help is very much appreciated. Thanks Lloyd The decompress function is also added here ========================================== bool ParseHttp::Decompress(const char* inBuff, int inLen,char** outBuff, int* OutLen,int type) { enum { CHUNK=4096 }; if(inBuff==NULL) return false; filtering_streambuf<input> in; switch(type) { case GZIP: in.push(gzip_decompressor()); break; case ZLIB: in.push(zlib_decompressor()); break; } in.push(boost::make_iterator_range((const char*)inBuff,(const char*)inBuff+inLen)); vector<vUnzip*> unZipV; int totLen=0; while(1) { char* data=new char[CHUNK]; int xyz=0; try { xyz=boost::iostreams::read(in,data,CHUNK); } catch(exception& e) { if(debug) cout<<e.what()<<endl; } unZipV.push_back(new vUnzip(data,xyz)); totLen+=xyz; if(xyz!=CHUNK) break; } *outBuff=new char[totLen]; int g=0; for(int k=0;k<unZipV.size();++k) { memcpy((*outBuff)+g,unZipV[k]->ptr,unZipV[k]->len); g+=unZipV[k]->len; delete unZipV[k]; } *OutLen=totLen; return true; } ______________________________________ Scanned and protected by Email scanner

1 0

Asio question
by Amit Sonawane 06 Oct '08

06 Oct '08

Hi, I am using Asio in Boost version 1.36.0 and I have a question regarding recursive call to a completion handler. I have implemented a class similar to the one from the examples of asio acceptor. I would like to know if there is a way to recursively call handle_accept () within handle_accept() and break on condition when the socket is closed. (Please see my comment in the code ). Does Asio allow such implementation or is there another way to handle this condition. #include "server.hpp" #include <boost/bind.hpp> namespace http { namespace server2 { server::server(const std::string& address, const std::string& port, const std::string& doc_root, std::size_t io_service_pool_size) : io_service_pool_(io_service_pool_size), acceptor_(io_service_pool_.get_io_service()), new_connection_(new connection( io_service_pool_.get_io_service(), request_handler_)), request_handler_(doc_root) { // Open the acceptor with the option to reuse the address (i.e. SO_REUSEADDR). boost::asio::ip::tcp::resolver resolver(acceptor_.io_service()); boost::asio::ip::tcp::resolver::query query(address, port); boost::asio::ip::tcp::endpoint endpoint = *resolver.resolve(query); acceptor_.open(endpoint.protocol()); acceptor_.set_option(boost::asio::ip::tcp::acceptor::reuse_address(true) ); acceptor_.bind(endpoint); acceptor_.listen(); acceptor_.async_accept(new_connection_->socket(), boost::bind(&server::handle_accept, this, boost::asio::placeholders::error)); } void server::run() { io_service_pool_.run(); } void server::stop() { io_service_pool_.stop(); } void server::handle_accept(const boost::system::error_code& e) { if (!e) { new_connection_->start(); acceptor_.async_accept(new_connection_->socket(), boost::bind(&server::handle_accept, this, boost::asio::placeholders::error)); //Need to call handle_accept again here e.g. boost::bind(&server::handle_accept, this, boost::asio::placeholders::error)); } } } // namespace server2 } // namespace http Thanks, Anuit Esta mensagem pode conter informação confidencial e/ou privilegiada. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não deverá utilizar, copiar, alterar, divulgar a informação nela contida ou tomar qualquer ação baseada nessas informações. Se você recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperação. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, change, take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.

3 2

[shared_ptr] Cannot include shared_ptr.hpp in a Visual Studio .Net 2003 managed C++ file
by Alice Johnson 06 Oct '08

06 Oct '08

When I include <boost/shared_ptr.hpp> in a file that has Compile as Managed set to Assembly support (/clr), I get: error C2373: 'InterlockedIncrement' : redefinition; different type modifiers C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinBase.h(1298) : see declaration of 'InterlockedIncrement' I started with boost version 1.34.1, but have also tried 1.35.0 and 1.36.0 Is there any solution to this? Alice Johnson

4 3

[Asio]: Massive performance degradation with compiler optimization
by Roland Bock 06 Oct '08

06 Oct '08

Hi, I am experimenting with asio in order to replace our current tcp library and stumbled over something weird this morning: The ansynchronous tcp echo server from the examples is much slower (~factor 3) with compiler optimization turned on! http://www.boost.org/doc/libs/1_36_0/doc/html/boost_asio/example/echo/async… For my test I modified the blocking single threaded tcp echo client to send 1000 identical messages of about 100kB length to the server and display the echo (see attachment). with -O0: ========= time ./src/TcpClient localhost 3000 | wc 1000 3000 104459000 real 0m6.072s user 0m5.564s sys 0m0.508s with -O3: ========= time ./src/TcpClient localhost 3000 | wc 1000 3000 104459000 real 0m21.287s user 0m5.756s sys 0m0.164s The optimization has very little effect on the client, though. When performing several runs, the time needed for the experiments varies a lot with -O3, ranging from about 13 seconds to up to 40 seconds. With -O0, the values do not change much (6-7 seconds). Other optimization switches (-O1 or -O2) behave like -O3. I have not tried to turn on/off the single optimization flags like -ftree-dominator-opts yet. Some system information (please do not hesitate to ask for more): Ubuntu 8.04, 64bit g++ 4.2.3 With other parts of boost I checked, opimization works as expected, sometimes with outstanding results: My date parser using spirit gained almost a factor of ten in performance. Any ideas what might be happening with the server? Thanks and regards, Roland

1 0

fast_pool_allocator question
by Ta-Cheng Lin 06 Oct '08

06 Oct '08

Hi : I use fast_pool_allocator and it seems not release memory even I explicitly call boost::singleton_pool<boost::fast_pool_allocator_tag, sizeof(int)>::release_memory(); out put 1. MEM USAGE = 11 MB, 2. MEM USAGE = 35 2. MEM USAGE = 35 2. MEM USAGE = 35 3. MEM USAGE = 35 4. MEM USAGE = 35 <<<--- memory is not released!!! Any suggestions are welcomed. -Todd --- BEGIN ---- #include <boost/pool/pool_alloc.hpp> #include <list> using namespace std; using namespace boost; #include "memusage.cpp" <<-- function to call Unix 'top' //-------------------------------------------------- void func() { list<int, fast_pool_allocator<int> > v; // list<int> v; for (int i = 0; i < 1000000; ++i) { v.push_back(i); } printf("2. MEM USAGE = %d\n", getMemUsage()); } //-------------------------------------------------- int main(int argc, char **argv) { printf("1. MEM USAGE = %d\n", getMemUsage()); func(); func(); func(); /// Exiting the function does NOT free the system memory allocated by the pool allocator // You must call // boost::singleton_pool<boost::pool_allocator_tag, sizeof(int)>::release_memory() // in order to force that printf("3. MEM USAGE = %d\n", getMemUsage()); boost::singleton_pool<boost::fast_pool_allocator_tag, sizeof(int)>::release_memory(); printf("4. MEM USAGE = %d\n", getMemUsage()); return 1; } // from boost doc // If you are seriously concerned about performance, // use fast_pool_allocator when dealing with containers such as std::list, // and use pool_allocator when dealing with containers such as std::vector. -- END --

1 0

[date-time] Should this be an exception
by Larry 06 Oct '08

06 Oct '08

Using 1_35_0 on MSVS .NET 2003 string x("200810051"); try { date d(from_undelimited_string(x)); } catch (exception& e) { } I would have though this would thrown an exception (too many digits in the date) but it didn't. I may have missed it in the doc that the constructor only considers the first 8 digits (for the undelimited case - actually probably the from_undelimited_string function). Or did I miss something else? Larry

1 0

[thread] Synchronisation Across Multiple Condition Variables
by Alex Adranghi 05 Oct '08

05 Oct '08

Dear All, I'd like to ask the floor what is the best way to wait on multiple condition variables, with the first one causing the "aggregated wait" to return with some distinguishable value. --- I'm looking to achieve something akin to .NET's WaitHandle.WaitAny, or a limited Occam ALT. After a quick peak at the source, I believe this would be a non-trivial change to the library. A way around it involves sharing data and wrapping a condition, defining notify() to take a boost:condition_variable. This would notify the condition_variable argument* so that sole observers will be notified, then setting an identifier to a member field, followed by notifying the wrapped general condition itself. The new aggregated wait() would first wait for a notification from the wrapped condition, before retrieving the identifier written to the object to return. Problem is, I don't think this is particularly elegant. Another solution is using threads to wait for each boost::condition_variable, but I don't see this as practical due to obvious overhead. *However this means for notify(), observers of the sole condition have waking preference over observers of the aggregated condition, and there is no way to know if any thread has been woken (in order to determine whether to notify the wrapped boost::condition_variable). --- Thanks for reading this, and answers on a postcard appreciated ;). -- Best regards, Alex Adranghi web: www.alexadranghi.com linkedin: www.linkedin.com/in/alexadranghi mail: mail(a)alexadranghi.com pgp: 0x6770b73f

2 1