September 2008 - Boost - lists.boost.org

Boost.Process 0.3 released
by Boris 14 Apr '09

14 Apr '09

I've released Boost.Process 0.3. Here's the documentation and a link to download the zip archive: Docs: http://www.highscore.de/boost/process/ Code: http://www.highscore.de/boost/process.zip It's a header-only library and thus pretty easy to use: Just copy the files to your Boost directory. In this release my main goal was to merge various snapshots: * There was my Boost.Process 0.2 version which was based on Boost.Process 0.1 from 2006. * There was a post-0.1 version of Boost.Process in SVN from 2007. * Chris Fairles had modified a Boost.Process snapshot for Unix platforms. * Ion Gaztañaga had also some ideas and bug fixes he sent to this mailing list recently. I just saw that Ilya Sokolov created another snapshot based on Boost.Process in SVN. That means we have again at least two different versions of Boost.Process. :-/ In my Boost.Process 0.3 version I concentrated on merging and overhauling code. I did not change the design but tried to make the code work: All the code which was written since 2006 should become usable. That's why I also concentrated a lot on test cases. There are quite a lot of test cases, and they all can be built and passed successfully on three platforms with four compilers. As it would be great if others run the test cases, too (ideally on new platforms), I'll send another message in a few minutes with a description how to run the test cases yourself. As the documentation was written in 2006 I also updated it. It's not yet really a good documentation: There are some files coming from 2006 while other files I wrote myself only last week. While the documentation can be improved it's at least up-to-date: The examples all work and can be compiled. As the documentation was not my priority for Boost.Process 0.3 it should be ok for now. Boris

9 14

Final report of GSOC project 'Spatial Indexes'
by Federico J. Fernández 27 Mar '09

27 Mar '09

Hi List! I'm writing this email as a final report of my Google Summer of Code 2008 project for Boost. My project consist in adding some spatial indexing structures to Boost in the context of the Geometry proposal done by Barend Gehrels. Spatial indexes are data structures optimized for spatial oriented queries. The classic index structures (i.e. a binary tree) aren't spatially enabled, they have different ordering criteria but none of them relates to topological properties. The scope of these structures is really wide, from collision detection for games to geometry indexing for GIS software. The original project goals were: - Build a Quadtree. - Build an rTree. - Integrate some previous work from a former GSoC project of a k-d-tree. - Test and document everything. Both indexes are implemented now and everything is tested and documented. The only task that we didn't complete is the k-d-tree integration, because when we analyzed the code it was not ready, and we didn't have the time to finish it. About the results, we made several tests and benchmarks. We tested both indexes with 230.000 objects from GIS data to check the correctness of the implementation, and we made some benchmarks comparing the quadtree vs. rtree and comparing both of them to existing implementation (like GEOS) with very good results. We describe this benchmarks in the documentation offering this as a guide to choose the best index for each use. The code is still beta (or maybe alpha) and not recommended for production use because it is still not tested enough, but if you want to check the actual status you can find it in the following location: https://svn.boost.org/svn/boost/sandbox/SOC/2008/spacial_indexing/ And the docs are at: https://svn.boost.org/svn/boost/sandbox/SOC/2008/spacial_indexing/libs/spat… The future work now is huge. We have some ideas about integrating this in some way to multindexes, and we want to implement also a 'packed' version of the rtree to improve bulk-loading times among another things. Finally, I would like to thank to Boost for allowing me to be part of this year's SOC. And specially to my mentor Hartmut Kaiser for all his help during the program. -- federico j. fernandez

8 13

[endian] superfluous boost::operators<> ?
by Roland Schwarz 26 Mar '09

26 Mar '09

I discovered, that the following will not compile: unsigned u; ulittle32_t u1; ulittle32_t u2; u = 1; u1 = 1; u2 = u1 + u; The compiler complains about not being able to resolve similar conversions. My guess is, that using boost::operators<> _and_ providing type conversion operators at the same time is causing this. I think it should be enough to define the essential operators in cover_operators template, and omit boost::operators<> at all. At least I am not able to find any problems with this, since the compiler adjusts the arguments (using the provided type conversion operators?) and calls the built in operators, thereby resolving ambiguity. Any thoughts? -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

2 1

Profiling template instantiations
by Steven Watanabe 12 Feb '09

12 Feb '09

AMDG Over the last few days, I've been working on a tool that counts the number of class template instantiations in a translation unit. To use it from a jamfile import profile_templates : : directory of the tool ; template-profile result : some_file.cpp : <include>some_directories ; If everything works, this will create a file with the extension .tp which will contain the number of times each class template was instantiated, with the most common templates at the top. I've put a zip of a rough version in the vault. http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… Caveats: I've only tested with Visual C++ 9.0 and gcc 3.4.4 on cygwin so far. Other compilers won't work, yet. Other versions of these compilers may or may not work. It may be necessary to add link=static to the bjam command line. In Christ, Steven Watanabe

6 20

Re: [boost] Profiling template instantiations (Steven Watanabe)
by PORKOLAB Zoltan 12 Feb '09

12 Feb '09

Hi Steven, We have created a framework for debugging/profiling template metaprograms in 2006. It might give you a few tips. It works based on the same idea you have. We instrument all template codes, both at the begining and at the end of each template we insert a special piece of code emitting warning messages of a well-defined form. Before instrumentation we create an XML file to remember the template positions in the source file. When we parse the warning, using this information we can reconstruct the instantiation stack knowing the original line numbers, identifiers, etc.. At the end we produce another XML for possible front-ends. The framework uses boost::spirit and boost::wave. We have also implemented and tested a visual studio plug-in. An overview of the whole idea: http://gsd.web.elte.hu/templight/ There is also a GPCE article about the framework, you can find it here: http://portal.acm.org/citation.cfm?id=1173746&coll=portal&dl=ACM&CFID=47731… or here: http://gsd.web.elte.hu/contents/articles/gpce06.pdf You can download both the VS binaries and the source from: http://people.inf.elte.hu/pocok Please feel free to use the code or any of the ideas. For technical question you can find Jozsef: jmihalicza(a)gmail.com or me. Regards, Zoltan

4 3

[thread/interprocess] could we improve recursive_mutex constructor
by vicente.botet 24 Jan '09

24 Jan '09

Hi, the recursive_mutex constructor initialize/set/destroy the pthread_mutexattr_t every time. I'm wondering if we can improve the efficiency storing this on a static variable which will be initialized once. What could be the better way to initialize this static variable? Note: the same applies to interprocess mutexes. recursive_mutex() { // begin code that can be initialized only once pthread_mutexattr_t attr; int const init_attr_res=pthread_mutexattr_init(&attr); if(init_attr_res) { throw thread_resource_error(); } int const set_attr_res=pthread_mutexattr_settype(&attr,PTHREAD_MUTEX_RECURSIVE); if(set_attr_res) { throw thread_resource_error(); } // end code that can be initialized only once int const res=pthread_mutex_init(&m,&attr); if(res) { throw thread_resource_error(); } // begin code that can be removed BOOST_VERIFY(!pthread_mutexattr_destroy(&attr)); // end code that can be removed } Regards, Vicente

2 2

manipulators for filtering_stream s
by Roland Schwarz 22 Jan '09

22 Jan '09

Surprisingly I was not able to find on the net code that would give me a smart way to indent a stream. So I wrote a little filter based on the boost iostreams library. My first attempt was: boost::iostreams::filtering_ostream out; indent_filter ind(4); out.push(ind); out.push(std::cout); However trying to control it via e.g. ind.in() ind.out() turns out to be problematic interface since, 1) out.push() takes a copy of ind 2) the interface ind.in() is suboptimal. With my attached example it is possible to: #include "indent.hpp" ... boost::iostreams::filtering_ostream out; indent_filter::push(out,2); out.push(std::cout); ... And use it like so: out << "Hello Filter!\n" << indent_in << "this is\n" << "indented\n" << indent_out << "until here\n" ; Which will result in output: Hello Filter! this is indented until here The state is stored in the ios base class of the stream, by way of the pword mechanism. Consequently the filter stream even may be downcast to a basic_ostream, and the indenter will still work. E.g. with out defined as above: ... foo(out); ... void foo(std::ostream& out) { out << indent_in << "out is a downcast filter_stream\n" << indent_out << "end of indentation\n" ; } If you want to try it out, you just need to include the header indent.hpp. If someone thinks the snippet is usable either as an example for the iostreams library or the filter streams manipulator idea is worth generalizing to make it usable for other filters too, I would be glad to hear from you. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

5 17

[thread] proposal to manage portable and non portable thread attributes
by vicente.botet 22 Jan '09

22 Jan '09

Hello, Boost.thread has already a non portable interface to get the thread handle class thread { public: ... typedef np_native_handle_type native_handle_type; native_handle_type native_handle(); ... }; Boost.Thread do not allow to pass thread attributes on the thread constructor. I supose that this is due to portable issues. Could we identifiy which attributes are portable and which one not? The portable attributes (as stack size, ...) can be grouped on a thread_attributes class. In order to be able to pass whatever attribute to the thread constructor we can add the setting of non portable attributes to this thread_attributes class, and making the thread constructor take a thread_attributes in addition to the existing parameters. class thread { public: class thread_attributes { // portable attributes public: // set/get of attributes // .. #if defined(BOOST_THREAD_PLATFORM_WIN32) // ... window version #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) private: pthread_attr_t native_attributes; public: set_np_attributes(const pthread_attr_t* h); // ... other #else #error "Boost threads unavailable on this platform" #endif }; thread(const thread_attributes*p, F f,A1 a1); ... }; The portable application needing some specific configuration can construct portable threads using the following schema thread::thread_attributes attr; // set portable attributes // ... #if defined(BOOST_THREAD_PLATFORM_WIN32) // ... window version #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) // ... pthread version pthread_attr_t native_attributes; pthread_attr_init(&native_attributes); pthread_attr_setstacksize(&native_attributes, 1000000); attr.set_np_attributes(&native_attributes); #else #error "Boost threads unavailable on this platform" #endif thread th(attr, f,ctx); What do you think? Vicente

3 3

Tests are a mess
by Gennaro Prota 23 Dec '08

23 Dec '08

Few questions: * BGD-Ubuntu is among tested platforms for release, but not for trunk. How is a poor fellow supposed to test on trunk first? * Same as above for BGD-Windows, with the fellow getting poorer and poorer * Are RW_WinXP_VC and RW_WinXP_VCrtl the same? * Can anyone please have a look at the trunk failures for HP-UX_ia64_aCC? For a bunch of libraries I've looked at it gives an Unsatisfied symbol "boost::exception_detail::refcount_ptr<..." What's that? Compiler bug, misconfiguration, phase of the moon? Sorry, but if this is the status quo I'm just going to merge to branches/release and be done with it. -- Genny

11 44

[swap] How to fix ADL barrier for XL, Intel, GCC, Sun and Como?
by Niels Dekker - mail address until 2008-12-31 19 Dec '08

19 Dec '08

The boost::swap utility from Joseph Gauterin has an ADL barrier against infinite recursion or ambiguity, as recommended by Steven Watanabe and David Abrahams, last year at the mailing list: "Re: [boost] Koenig lookup swap." http://lists.boost.org/Archives/boost/2007/08/125938.php Last Friday I added "test_adl_barrier" to test this ADL barrier. Unfortunately it fails on many compilers, including XL (AIX), Intel (version 9 and 10), GCC, Sun and Como: http://www.boost.org/development/tests/trunk/developer/utility-swap_.html While I usually use MSVC, and for that specific compiler, the ADL barrier appears successful! Do you know how to fix the ADL barrier for the other compilers? I'm afraid we'll need to have #if BOOST_WORKAROUND statements in there... FYI, the boost::swap utility is at: http://svn.boost.org/svn/boost/trunk/boost/utility/swap.hpp The ADL barrier test is at: http://svn.boost.org/svn/boost/trunk/libs/utility/swap/test/test_adl_barrie… Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

5 26