August 2008 - Boost - lists.boost.org

[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

[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

[proto][design]why unary_expr,binary_expr; but no nullary_expr?
by Larry Evans 14 Dec '08

14 Dec '08

Although there's unary_expr<Tag,*>, binary_expr<tag.*,*> in traits.hpp there's no nullary_expr<Tag>. I realize this would be a replacement to the current terminal template but with a user specified tag. After all, if a user specified tag for n-ary (where n>0) expressions *is* desirable, why is a user specified tag for 0-ary expressions *not* desirable? On case where this would be useful is for algebraic morphisms where n-ary ops in a source algebra are mapped to n-ary ops in a target algebra. This *includes* 0-ary ops. An op would be the equivalent to proto tags. I think this could be done by another transform similar to the pass_through transform but allowing transformation of the tag. Currently pass_through just uses the source tag in the target expression. It seems like it should be pretty easy to allow transformation on the tag also.

2 3

Review Request: Polynomial
by Paweł Kieliszczyk 30 Oct '08

30 Oct '08

Hi, I'd like to request a review of my polynomial library which I wrote during Google Summer of Code project this year. The zip file is in Boost Vault (called polynomial.zip). It includes the library, tests and documentation. The same files (not compressed) are also available in sandbox: http://svn.boost.org/svn/boost/sandbox/SOC/2008/polynomial/ Thanks -- Pawel Kieliszczyk

3 5

[boost.org] people not updated?
by Thorsten Ottosen 24 Oct '08

24 Oct '08

Hi, It seems like we are missing some of our recent members. -Thorsten

4 3

[integer] Promotion of endian library code from vault
by Neil Mayhew 01 Oct '08

01 Oct '08

On 2006-07-22 12:21:01, Beman Dawes wrote: > [boost] [integer] endian-0.6 posted w/ names changed > endian-0.6.zip has been posted in the integer directory of the file > vault at http://boost-consulting.com/vault/ This code is still in the vault, but I'd like to see it in the main part of boost. What needs to be done to make this happen? The endian library is exactly what I've been looking for, and I would really like to use it in my work, but I can't justify that to my colleagues if it's not an official part of boost. I would hate to become yet another person that reinvents this particular wheel. However, I notice there was a lot of discussion <http://lists.boost.org/Archives/boost/2006/07/108125.php> about PODs vs constructors, because of unions, so maybe not enough consensus was reached? There were some interesting proposals but no agreed-upon solution. In which case, I suspect that people will need to copy the code and each hack it to suit their own purposes, which is not what boost is all about. I have two use cases from my own work: TrueType fonts, and Mac HFS+ file systems. Both of these are big-endian file formats that need to be read into memory and processed, so (FWIW) I would support the POD approach. Currently, I can't use the code as-is because of the need to use the types in unions. References: http://lists.boost.org/Archives/boost/2000/03/2495.php http://lists.boost.org/Archives/boost/2006/05/105621.php http://lists.boost.org/Archives/boost/2006/06/105695.php http://lists.boost.org/Archives/boost/2006/06/105779.php http://lists.boost.org/Archives/boost/2006/06/105968.php http://lists.boost.org/Archives/boost/2006/06/106655.php http://lists.boost.org/Archives/boost/2006/07/108125.php http://lists.boost.org/Archives/boost/2006/07/108202.php --Neil

9 37

[log] RFC: An alternative implementation is coming up
by Andrey Semashev 23 Sep '08

23 Sep '08

Hi, After more than a year of development my implementation of logging library is coming to its first release. Here are some feature highlights: * independent logger/sink and multimodule-friendly design with great extensibility potential * support for both embedded and global loggers * full-fledged attribute support (global, thread-specific and logger-specific attributes supported) * filtering and formatting support, including lambda expressions for filters and formatters construction * support for writing log to streams (files, console), rotating files support * support for Syslog API * support for library initialization helpers, including settings file support * thread safety support with least possible locking * wide-character logging support The library documentation can be found online on SourceForge: http://tinyurl.com/5e4fd7 Some requirements background can also be found on this Wiki: http://tinyurl.com/2fndfg The library code is quite stable, however, minor changes are still possible. The code can be checked out from the SourceForge CVS, the detailed instructions can be found here: http://tinyurl.com/6k9vvp There are currently no automatic tests, but there are some examples, which were compiled and run on Linux and Windows. I would like to see what Boost community thinks of this library, whether it worth submitting, has any critical flaws or any other thoughts. I also would appreciate if Gennadiy Rozental and John Torjo expressed their thoughts on possibility to review this library in parallel with John's solution, which is currently in the review queue. I would gladly discuss this privately, if they find it more suitable.

3 5

[BENUM] Any interest in auto-generated enum-to/from-string functions, without longer/more-complex usage?
by Tony D 15 Sep '08

15 Sep '08

Anyone think this functionality belongs in boost? (I have working code) ENUM(X, B = N, C, D = B + C }; // or whatever X x1 = C; cout << x1 << '\n'; // outputs "C\n" X x2("D"); // construct from string... if (x2 == D) { will do } Tony __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

4 3