March 2009 - Boost - lists.preview.boost.org

Boost.Asio asio::basic_socket_acceptor
by Joshua Pedrick 13 Mar '09

13 Mar '09

I'm trying to write an application that can simply switch between using local stream sockets and tcp stream sockets. I successfully implemented this behavior with BSD sockets in Linux, but it seems the class hierarchy in boost::asio makes this behavior awkward, since asio::basic_socket_acceptor template requires a protocol type, but there is so base class for protocols. I'm wondering if there is a reason for this or if it could possibly be changed? Basically, I have a client/server library for distributed processing, which in some cases, I wish to run using local sockets and other times run using TCP sockets. I was hoping Boost Asio could make the solution a little more elegant/clean, but at the moment I can't find an elegant manner to do this. I'd be glad to do all the work for this, provided some guidance, but I basically don't want to build my application on a custom version of boost::asio, which won't improve with the main version. So if this can't be changed, I just won't use asio, but if it can, I'll go ahead and take the time to implement the changes

2 1

To create a boost thread
by Filip Klasson 13 Mar '09

13 Mar '09

Hi, I have problems creating a thread. This is an example i found: #include <boost/thread/thread.hpp> #include <iostream> void hello() { std::cout << "Hello world, I'm a thread!" << std::endl; } int main(int argc, char* argv[]) { boost::thread thrd(&hello); thrd.join(); return 0; } What if i want to create a thread outside of main (in a class) like this: "myClass.h" class MyClass { public: hello(); myFunction(); }; "myClass.cpp" MyClass::hello() { std::cout << "Hello world, I'm a thread!" << std::endl; } MyClass::myFunction() { boost::thread thrd(&hello); thrd.join(); } This does not work and i get the compile error: '&' : illegal operation on bound member function expression

4 4

Re: [boost] [Fwd: Re: Google SOC Mentors?]
by Niall Douglas 12 Mar '09

12 Mar '09

On 12 Mar 2009 at 15:41, troy d. straszheim wrote: > >> Do have any interest in teaming up on this? > > > > Umm sure ... I can't find the message below in the Boost mailing list > > archives, so I'm unsure as to context. > > > > But if it's to mentor Google SoC then yes please, though do note I am > > extremely time pressed until the start of June after which I'll be > > finally free of academia. > > > > i.e. please do put my name forward. > > > > No worries. Whatever happens will be done on the mailing lists and > IRC, so you can join in at any point. Just to let everyone know, I have subscribed to boost(a)lists.boost.org and will remain until the Google SoC process is over. This is a very high volume list - this is why I normally lurk around Boost.Python only - so I won't be staying for much past the SoC process. I am *extremely* time pressed before the start of June and will neither be able to access IRC nor my own email (thank you very much university firewall!). However start of June onwards I'll be finally free and working from home for the next few years. Looking forward to hearing from you all, Niall

1 0

[mpi] Boost.MPI + GCC 4.3 + MPICH2 (1.0.3) Issue on Gentoo
by Dean Michael Berris 12 Mar '09

12 Mar '09

Hi Guys, Anybody been successful with combining Boost.MPI and MPICH2 before? I keep getting this link-time error about 'now' couldn't be found. The command I get from Boost.Build + Boost.Jam is the following (stripped of Friendster-specific names/symbols): "g++-4.3.3" -L"/usr/lib64" -o "output" -Wl,--start-group "main.o" "boost_1_38_0/bin.v2/libs/mpi/build/gcc-4.3.3/debug/link-static/optimization-speed/threading-multi/libboost_mpi-gcc43-mt-d-1_38.a" "boost_1_38_0/bin.v2/libs/serialization/build/gcc-4.3.3/debug/link-static/optimization-speed/threading-multi/libboost_serialization-gcc43-mt-d-1_38.a" -Wl,-Bstatic -Wl,-Bdynamic -lmpich -lpthread -lrt -lrt -Wl,--end-group -g -pthread -O2 -Wl,-rpath -Wl,-z,now -Wl,/usr/lib64 -march=opteron -pipe The auto-configuration worked for MPI: ===============MPI Auto-configuration=============== Found MPICH wrapper compiler: mpicc MPI compilation flags: -march=opteron -O2 -pipe -Wl,-z,now -I/usr/include -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -lmpich -lpthread -lrt MPI link flags: -march=opteron -O2 -pipe -Wl,-z,now -I/usr/include -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -lmpich -lpthread -lrt MPI build features: <include>/usr/include <library-path>/usr/lib64 <find-shared-library>mpich <find-shared-library>pthread <find-shared-library>rt <cxxflags>-march=opteron <cxxflags>-O2 <cxxflags>-pipe <cxxflags>-Wl,-z,now <cxxflags>-Wl,-rpath <cxxflags>-Wl,/usr/lib64 <include>/usr/include <library-path>/usr/lib64 <find-shared-library>mpich <find-shared-library>pthread <find-shared-library>rt <linkflags>-march=opteron <linkflags>-O2 <linkflags>-pipe <linkflags>-Wl,-z,now <linkflags>-Wl,-rpath <linkflags>-Wl,/usr/lib64 MPI launcher: mpirun -np ==================================================== In my Jamfile I have something like the following: exe output : main.cpp : <source>/boost//mpi <library>/mpi//mpi ; Am I missing anything obvious? TIA -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

2 3

[iostreams][repost] How can code conversion failure be detected
by Eric MALENFANT 12 Mar '09

12 Mar '09

Hi, I posted what's quoted below a while ago on the boost devel mailing list, but received no replies. (Naïvely?) assuming that this lack of feedback was caused by the excessive length of the post, let me try to summarize it: For the purpose of this example, assume the existence of always_fail_cvt, a codecvt facet which always returns "fail" namespace bio = boost::iostreams; std::wofstream fs("whatever"); fs.imbue(std::locale(fs.getloc(), new always_fail_cvt)); bio::filtering_wostream s(fs); s << L"Hello"; std::cout << std::boolalpha << s.good() << '\n'; // 1 s.flush(); // 2 std::cout << s.good() << '\n'; // 3 "s" being buffered, it is not surprising that line //1 outputs "true" (nothing failed yet, "Hello" is in the buffer) By stepping in the code, I see that line //2 tries to empty the buffer by calling sputn() on the underlying wofstream's filebuf, which fails because code conversion fails. I thus find it surprising that line //3 also ouputs "true" I'm also surprised that line //2 does not cause flush() to be called on the wofstream, or pubsync() on its filebuf Is this a bug or am I wrong in assuming that 1) The codecvt error occuring during flush() should cause the failbit to be set on the filtering_stream 2) flush()-ing a filtering_ostream wrapping an std::ostream should flush() the std::ostream ? Thanks, Éric Malenfant Original post follows: By default, filtering_streams do buffering. This means that what is written to them does not necessarily reach the underliyng Filters and Device immediately. It is thus my understanding that, in order to be sure that all data was written, one should somehow flush the buffered data, and then check the stream state before closing it. As a first attempt, I tried flush(), but it does not seem to do what I expected, as it is pretty lax in the failures that it tolerates. Looking at the docs, I then found what seemed to be what I was looking for: strict_sync(), whose documentation states that "A return value of true guarantees that all buffered data has been successfully forwarded.". Moreover, the FAQ entry "Can I swap Filters or Devices in the middle of a sequence of i/o operations?" seems to confirm this, as it says: "First call strict_sync. If it returns true, you can safely call set_auto_close(false) and pop one or more components without closing the stream. This applies to instances of filtering_stream, filtering_streambuf and chain." But again, this did not work: strict_sync() returns true altough buffered data remains. Consider this contrived example: // A codecvt facet that always fails class always_fail_cvt : public std::codecvt<wchar_t,char,mbstate_t> { protected: virtual result do_unshift(state_type&, char*, char*, char*&) const { return std::codecvt_base::error; } virtual int do_encoding() const throw() { return -1; } virtual bool do_always_noconv() const throw() { return false; } virtual int do_length(const state_type&, const char*, const char*, size_t max) const { return max; } virtual int do_max_length() const throw() { return 4; } virtual result do_out(state_type&, const intern_type*, const intern_type*, const intern_type*&, char* to, char*, char*&) const { return std::codecvt_base::error; } virtual result do_in(state_type&, const char*, const char*, const char*&, intern_type*, intern_type*, intern_type*&) const { return std::codecvt_base::error; } }; int main(int argc, char* argv[]) { namespace bio = boost::iostreams; std::wofstream fs("whatever"); fs.imbue(std::locale(fs.getloc(), new always_fail_cvt)); bio::filtering_wostream s(fs); s << L"Hello"; std::cout << std::boolalpha << s.good() << '\n'; // 1 s.flush(); std::cout << s.good() << '\n'; // 2 return 0; } Running this (on Windows with MSVC 7.1) produces true true The first "true", is not surprising, as the characters are buffered and code conversion has not taken place yet, but the second is. Considering the presence of strict_sync(), I assumed that the laxism of flush() is intentional, to allow stateful filters to retain buffered data, maybe. However, replacing the "s.flush();" line in the above program with "std::cout << s.strict_sync() << '\n';" does not seem to improve things. Although a conversion failure occured and data remains buffered, strict_sync() returns true, and the stream's state is still good(). So, to sum up: 1) If my understanding of the semantics of strict_sync() is correct, it seems that indirect_streambuf::strict_sync() should verify that the buffer is empty after the call to sync_impl(), and fail if it is not the case. Something like this maybe: template<typename T, typename Tr, typename Alloc, typename Mode> bool indirect_streambuf<T, Tr, Alloc, Mode>::strict_sync() { try { // sync() is no-throw. sync_impl(); return obj().flush(next_) && ((pptr() - pbase()) != 0); // Added this --^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ } catch (...) { return false; } } 2) Is it "correct" that filtering_stream::flush() does not completely flush without reporting an error? 3) Does this come from an incompatibility between Boost.IOStreams idea of error-reporting (throwing exceptions) and that of the std streambufs (returning EOF, mainly)? In particular, Boost.IOStreams writes in a wrapped std::streambuf by using sputn(), which, AFAI(don't)U, does not have a clear error reporting strategy. IOWs, should write_device_impl<streambuf_tag>::write() be modified like this: template<typename T> static std::streamsize write (T& t, const typename char_type_of<T>::type* s, std::streamsize n) // { return t.sputn(s, n); } { std::streamsize count = t.sputn(s, n); if (count == n){ return count; } // If all characters could not be written, check if it is because of an error or only because of blocking if (T::traits_type::eq_int_type(t.sputc(s[count]), T::traits_type::eof())){ throw std::ios_base::failure("write error"); } else{ return count + 1; } } so that errors occuring during a write on std::streams and streambufs are reported by an exception? -- Éric Malenfant If it ain't broke, you're not trying hard enough. - Seen on the Google testing blog home page

1 0

Now Accepting Mentor Applications for Google Summer of Code 2009
by Hartmut Kaiser 12 Mar '09

12 Mar '09

http://google-code-updates.blogspot.com/2009/03/now-accepting-applications-f or-google.html Will we apply this year? What's the procedure? Can I help? Regards Hartmut

4 10

[Property Tree] Maintenance Takeover
by Sebastian Redl 12 Mar '09

12 Mar '09

Hi, I'd like to officially announce that I have, with Marcin Kalicinski's permission, taken over maintenance of the Property Tree library. Over the next week I'll take a good look at it and see what there is to be done for inclusion in an official release. At the moment, it seems like the main problem is insufficient and outdated documentation. Marcin also had other concerns regarding the library (performance and interface), and I'll see if they should be addressed before an official release as well. (Interface concerns are more pressing, obviously.) If anybody has additional comments on the library, change requests, performance data, or simple discussion of ideas, now is the time to let me now. Sebastian

4 3

[math] calculate derivative automatically.
by Dongfei Yin 12 Mar '09

12 Mar '09

Hi, I notice that some one may not have vc++9 with sp1, if so, there will be many compile errors. because I use #include <tuple>, the earlier version does not have such a library. so I made a version for boost::tuples::tuple. a file named "[math]AD.zip" in vault. BTW: I am wondering whether I do something wrong, there is no responding about this subject for a long time. Dongfei.

4 3

Re: [boost] [math] calculate derivative automatically.
by Dongfei Yin 12 Mar '09

12 Mar '09

Hi, Thank you for your explanation, to simplify a expression somewhat has relationship between philosophy. Any way, just a practice. thank you . Dongfei.

1 0

[Boost][GSoc] boost.crypto
by Kasra 12 Mar '09

12 Mar '09

Hi, I am looking into enrolling for GSoc program. I am checking for interest on a crypto library. The idea is to have a library that provide high level facilities for the user i.e. kernel entropy sources, random pools, CS PRNGs and etc. I am wondering if there is an interested party for mentor ship of the program? With Best Regards -- Kasra

1 0

Is Boost going to participant in this year's Google Summer of Code?
by Haoyu Bai 12 Mar '09

12 Mar '09

Hi, I know Boost is a mentor organization for last year's GSoC, so how about this year? I'm interesting in contribute to Boost.Python's py3k support. Though the project may be mentored under PSF, but it is best if it can be mentored under Boost. The time left for orginazation application it not so much, any ideas? Thanks! -- Haoyu Bai

1 0

Re: [boost] [C++-sig] [Python] GSoC and Python 3.0 Support
by Haoyu Bai 12 Mar '09

12 Mar '09

On Thu, Mar 12, 2009 at 4:50 AM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: > On 11 Mar 2009 at 13:42, Ravi wrote: > >> On Wednesday 11 March 2009 12:38:55 Haoyu Bai wrote: >> > > 1. Thread safety >> > > 2. PyFinalize support >> > > 3. Easier methods to write to_python/from_python converters >> > > 4. Python 3.0 support >> > > 5. Ability to extend the fundamental PyTypeObject used by boost.python > > My thread safety patch is still working to my knowledge. It sure > would be lovely to have it officially integrated. I'd also like to > see PyFinalize working though maybe not "complete" in the sense of a > total cleanup (just "good enough"). > > I would say that any GSoC project should choose *one* of the above > rather than try combining them. Better to do one thing well and in > stages than many things at once (unless you have loads of spare > time!). > > I have been out of commission development-wise during the last few > years as I have been undertaking some very time consuming academic > study - hence I have been very quiet on here. However, I finally > become free come this June and at long, long last I finally can > return to my own self-directed study (but now I have a whole pile of > bits of paper to officially say I can do what I was already capable > of). I will certainly be updating my TnFOX library for sure anyway, > and that means fresh Python bindings. > >> > Thanks! Seems there's a lot of interesting. So would anyone willing to >> > mentor this? >> >> Sadly, I suspect that finding a mentor will be difficult (perhaps even more >> difficult than the actual project). Off the top of my head, the following >> folks come to mind: >> - Dave Abrahams >> - Stefan Seefeld >> - Ralf Grosse-Kunstleve >> - Roman Yakovenko >> You might try contacting them off list or on c++-sig (cc'ed on this email). > > It's not /quite/ as easy as that ... Google want a mentoring > organisation rather than just a mentor and it has to be an approved > one. I could volunteer as mentor but I wouldn't qualify as I don't > come with an organisation attached. I'd need an approved organisation > to adopt me. > >> I did not mean to imply that the features I requested should be part of your >> GSoC. Thread safety & PyFinalize support would each be worth a GSoC project >> just by themselves, IMHO. If you will be tackling python 3.0 support, it might >> be possible to combine it with greater support for embedding python since much >> of the work in both aspects would be about wrapping python C API for C++ >> programmers. > > As mentioned before, thread safety is actually fairly trivial as all > the required work is already done. There is certainly some work > involved in writing a test suite and making my patch much more > generic as my patch was specifically designed to be diff-friendly to > any Boost alterations, and it doesn't make for good code. I would be > happy to mentor this project if we can find an approved mentoring > organisation to adopt me. It certainly would be a good GSoC for a > student programmer. > > PyFinalize() is likely just a hard slog in catching all the code > paths you wouldn't expect. It's harder than thread safety, but doable > as a GSoc. > > Adding Python 3.0 support ... I am afraid I have no idea as I've been > out of the coding scene for two years now, but it does sound big and > complex. But it's something I'm interested in though I'd be not much > use as a mentor except as in general Boost.Python programming. > > So, I guess you got a bit of a mentor if you'd like. BTW, I couldn't > start mentoring till the start of June as I have my final project due > then. But that fits the GSoC timetable just perfect. > > If you want to know more about my suitability, search this mailing > list. > > HTH, > Niall > > > Hi, Thanks Niall, it is great that you are willing to mentor. Also you don't need to worry about the Python 3.0 things, since I have worked on it and have knowledge about the API change. On the other side, I need guidance of Boost.Python internals, which you are familiar. Your time table is OK, but should notice that there's some trival things before the coding started, eg. sign up as mentor and evaluating proposal, hope you have time to do so. Hopefully you will be a great mentor! :-) One issue is that seems Boost is not going to participant in this year's GSoC as a mentor organization. (Anyone knows the real situation please clarify this, thanks!) If so, the project may could be attached to PSF, since it is Python related. We may limit the scope of this project to py3k support and thread-safety. I'll try to learn more about Boost.Python internals and see if the scope is feasible. Thanks you all! :-) -- Haoyu Bai

1 0

Re: [boost] [scope_exit] Boost.ScopeExit capturing 'this'
by Kim Barrett 12 Mar '09

12 Mar '09

At 8:35 AM +0000 3/10/09, adam.butcher(a)selex-comms.com wrote: >The enhancement allows capturing of 'this' in the BOOST_SCOPE_EXIT >capture sequence allowing access to any class members within the body. FWIW I ran into this problem almost immediate upon starting to use BOOST_SCOPE_EXIT, and it seems to be a common situation in my usage. >Member access for the enclosing class can be performed with the >syntax: > > (*this) -- convertible to enclosing 'this' > (**this) -- enclosing 'this' > (*this)->member -- accesses member 'member' of enclosing 'this' > >This syntax is perhaps controversial though I think both Alex and >myself are reasonably happy with it. Alternatives suggested were >'this_', 'this_()', 'enclosing_this', 'enclosing_this()', 'enclosing', >'enclosing()', 'self' and 'self()'. Any access syntax that doesn't have the form of a variable name will go right back to the original problem if one has a scope exit in the body of another scope exit. I've not yet needed to do something like that with BOOST_SCOPE_EXIT, but I know that I've more than once written a try/finally block that was in the finally clause of another try/finally block (in other languages, obviously).

2 2

[thread] performance of thread-local storage implementation
by Alexander Bernauer 11 Mar '09

11 Mar '09

Hi, I did some performance measurements as I wanted to find out, how expensive thread-local storage is. It turned out, that in my tests, boost's thread-local storage implementation is factor 5.5 slower than pthread's one. Why could this be? The test spawns n threads each of which increments a particular 64-bit counter. After 2 seconds the threads are shut down and joined and the counters are summed up. Between the counter objects there is enough space to rule out false sharing. Synchronization is done via a volatile sig_atomic_t, so no locks skew the tests. In the "no tls" test the counters are access directly. In the "pthread" and "boost" test the counters are accessed through thread-local storage, using pthread's and boost's implementation, respectively. The code can be found here [1] The test environment is: - Debian Lenny (gcc 4.3.2) - MacPro, 8 x Intel Xeon 2.80GHz - release variant, i.e. -O3 -finline-functions -fPIC -DNDEBUG The results are: ("factor" is ratio to "no tls" with same number of threads) type # threads counter sum factor no tls 1 558e+07 no tls 2 1116e+07 no tls 3 1674e+07 no tls 4 2237e+07 no tls 5 2811e+07 no tls 6 3372e+07 no tls 7 3943e+07 no tls 8 4784e+07 pthread 1 50e+07 11.16 pthread 2 101e+07 11.05 pthread 3 152e+07 11.01 pthread 4 203e+07 11.02 pthread 5 241e+07 11.66 pthread 6 306e+07 11.01 pthread 7 339e+07 11.63 pthread 8 434e+07 11.02 boost 1 9e+07 62.00 boost 2 18e+07 62.00 boost 3 27e+07 62.00 boost 4 37e+07 60.46 boost 5 46e+07 61.10 boost 6 56e+07 60.21 boost 7 65e+07 60.66 boost 8 79e+07 60.56 My interpretation of the results is, that using thread-local storage is quite expensive. This was somehow expected. But what's surprising is, that the boost lib introduces an other penalty of factor 5.5. Does anybody see any mistake? Or is there an explanation of why using the boost implementation is so expensive. Can it perhaps be done better? regards Alex [1] http://github.com/copton/roadrunner/tree/b2b19d752308c253e42d7c28c86f612aa6…

2 1

Re: [boost] Making friend with boost::interprocess
by Ion Gaztañaga 11 Mar '09

11 Mar '09

Oncaphillis wrote: > Of course somewhere deep in the guts of boost I get an error since > the Foo constructor is private. Who do I have to befriend in order > to make this scheme work ? At this moment you have no possibility of constructing non-constructible objects in shared memory. > Thank you > > O. Best, Ion

2 1

[Python] GSoC and Python 3.0 Support
by Haoyu Bai 11 Mar '09

11 Mar '09

Hi, I'm a student who has finished SWIG's Python 3.0 support in GSoC 2008. If Boost will participate in this year's Summer of Code, I'd like to contribute my knowledge of Python 3 migration to Boost.Python, by implement Python 3.0 support for it. Finally the users of Boost.Python would get 3.0 support smoothly. Is that worth for a GSoC project? Any interesting? Thanks! -- Haoyu Bai

4 5

Compiling error with VC8
by Christophe Henry 11 Mar '09

11 Mar '09

Hi, I just got a strange compiling error while testing Msm with VC8. If I write: template <class StateType> typename ::boost::enable_if< typename ::boost::mpl::and_<typename ::boost::mpl::not_ <typename has_exit_pseudo_states<StateType>::type>::type, typename ::boost::mpl::not_ <typename is_pseudo_exit<StateType>::type>::type >::type,BaseState*>::type I get : error C2770: invalid explicit template argument(s) for '`global namespace'::boost::enable_if<is_pseudo_exit<StateType>::type,BaseState*>::type boost::msm::state_machine<Derived,HistoryPolicy,BaseState>::add_state<ContainingSM>::new_state_helper(boost::msm::dummy<__formal>) const' If I replace the ::boost::mpl by boost::mpl, it compiles fine. But I'm still wondering if I'm doing something wrong or the compiler. Does anyone have an answer? Thanks in advance, Christophe

1 0

[Math] boost::math::signbit returns false for -NAN
by Hartmut Kaiser 11 Mar '09

11 Mar '09

Hi all, the boost::math::signbit function in trunk fails for an argument of -NAN. #include <boost/math/special_functions/sign.hpp> int main() { using boost::math::signbit; BOOST_ASSERT(signbit(-std::numeric_limits<double>::quiet_NaN())); return 0; } I'd expect to get a '1' back, but the function returns zero and the assertion fails. I know it worked while using Jon Rade's floating point utilities library from the vault. Does this have been integrated? Regards Hartmut

1 0

[filesystem][cygwin] Standard conformance for wide characters
by Beman Dawes 11 Mar '09

11 Mar '09

I've decided not to attempt support for Cygwin in the next version of Boost.Filesystem. Cygwin's lack of library support for wchar_t is the problem . For the current Boost.Filesystem version (v2), the necessary workarounds are so pervasive that the implementation code is much harder to read and maintain. Witness the number of bug reports that are Cygwin specific. For v3, currently under development, trying to support Cygwin would be even harder, and would cause a serious delay in development. Plus I'm tired of waiting for the cygwin folks to come into full C++ conformance. IIUC, the reason Cygwin doesn't provide C++ standard library support for wchar_t is that the underlying C library is missing the C wchar_t functions. Perhaps Boosters who care about Cygwin could spearhead an effort to add the missing C support? The needed functionality isn't all that complex; the main problem might be just learning enough about how Cygwin/GCC is configured and built to be able to add a fairy small number of C functions. Thoughts? --Beman

10 29

Question about futures library that was written by Anthony Williams
by Jon Shuler 11 Mar '09

11 Mar '09

There is an example in the documentation under Creating Asynchronous Values that shows how to call a function. Is it possible to call a member function that has arguments? Jon

2 1

[1.39.0] New libraries?
by Beman Dawes 11 Mar '09

11 Mar '09

Are there any new libraries that will be ready to go into the 1.39.0 release? Thanks, --Beman

3 8

[Review] RangeEx review extended to the 10th of March
by Thorsten Ottosen 11 Mar '09

11 Mar '09

Dear Developers and Users, The review period is extended one week. If you find this library interesting, please submit a review. The discussion so far may be found here: http://archives.free.net.ph/message/20090220.122836.73bdbd04.en.html Below you will find a description of the library and information on how to write a review. best regards Thorsten, review manager What is it? +++++++++++ The library provide two very useful extensions to the range library 1. Range-based algorithms. E.g. boost::sort( rng ); which is a convenient wrapper of instead of std::sort( boost::begin(rng), boost::end(rng) ); But the new interface also allows for more expressive code because (on the fly) composition of algorithms suddenly is possible. 2. Range adaptors. E.g. std::vector<int> vec = ...; boost::copy( vec | boost::adaptors::reversed, std::ostream_iterator<int>( std::cout ) ); where the expression "vec | boost::adaptors::reversed" wraps the iterators of the range on the left in reverse iterators. The library provides a wide range (no pun intended) of Range adaptors, and they are a powerful way to create ranges on the fly and pass them to algorithms. Getting the library +++++++++++++++++++ The library may be downloaded from http://www.cs.aau.dk/~nesotto/boost/range_ex.zip or from the Boost vault under "Algorithms". The docs may be browsed online here http://www.cs.aau.dk/~nesotto/boost/libs/range/ Please note that the documentation is integrated with the current Range ilbrary. Therefore the relevant sections for the review is http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/adaptors.html and http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/algorithms.html The code may be browsed here: http://www.cs.aau.dk/~nesotto/boost/boost/range/ Notice the library is header only (exception: the adaptor tokenized() depends on Boost.Regex). Writing a review ++++++++++++++++ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick - reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Special considerations ++++++++++++++++++++++ Various RangeEx like libraries have been implemented in the past. You might want to compare with those libraries when you form your oppinion: 1. John Torjo's range lib http://rangelib.synesis.com.au/libs/boost-rangelib-20040913.zip http://torjo.com/rangelib/index.html 2. Adobe's ASL libraries include range-based algorithms: http://stlab.adobe.com/group__algorithm.html I'm looking forward to your review. best regards Thorsten, Review Manager

2 1

RangeEx review
by Mathias Gaunard 10 Mar '09

10 Mar '09

Here is a quick review of RangeEx. > - Do you think the library should be accepted as a Boost library? Yes, assuming issues raised in the recent discussions are addressed, and that people agree on the naming. > - What is your evaluation of the design? It is nice and pretty. Here are a few comments: - I am unsure about the syntax of the unified return type system. It's very practical, however, but not so pretty. - Fusion of the function syntax and pipe syntax for adaptors would be useful, so that both range | transformed(f) and transformed(range, f) may be written. - Relying on standard algorithms means that the functors have to provide a result_type. I would like the functors to be automatically wrapped so that boost::result_of can be used instead. I don't know if Boost.Iterator needs it too. - In the sandbox version, find(range) used to call range.find() if range had a find member (the has_find meta-function had a poor implementation, but that could have been solved). I don't know why this feature was removed, but I personally liked that better. - I would like to library to also provide lazy range generators, potentially defining an infinite range recursively. - Adaptors for type filtering within heterogeneous sequences (sequences of "potentially smart" pointers, sequences of variants, sequences of any...) would also be a plus. It's basically a filter+transform at the same time. I found such an adaptor primitive very practical when dealing with trees, for example. > - What is your evaluation of the implementation? It seems good. It's mostly just forwarding things to standard algorithms or Boost.Iterator for adaptors, nothing much to say. > - What is your evaluation of the documentation? Simple, but doesn't necessarily need to be more complicated. > - What is your evaluation of the potential usefulness of the library? Huge. I deal with sequences (or ranges) of objects everyday, and being able to express operations directly on them would make my code simpler and clearer. > - Did you try to use the library? With what compiler? Did you have any problems? I used an old version from the sandbox, with a few custom modifications, less than a year ago to code some experimental proof-of-concept C++ wrapper over a hierarchical thread scheduler written in C (a component which mapped trees of tasks to trees of processors) so as to see how it could make the code more high-level. This was done with GCC 4.2. I didn't have problems except making it work with a lambda DSEL (I actually cheated and used typeof for return type deduction everywhere at the time). > - How much effort did you put into your evaluation? A glance? A quick - reading? In-depth study? I only quickly read the documentation and gave a glance at the version under review; but I did study the sandbox version more in-depth. > - Are you knowledgeable about the problem domain? I know about ranges, iterators, functional programming, and lazy sequences fairly well.

2 1

Help needed with some Math lib failures
by John Maddock 10 Mar '09

10 Mar '09

Folks, There are a few failures from Boost.Math (for example http://tinyurl.com/clvlq3) which I'm unable to reproduce locally - it seems only certain (possibly AMD x86-64 machines running Linux or *BSD) exhibit the problem. I can provide a test case to help with debugging what's going on, but I need to find someone who can reproduce the issue first. So... if you think you can help, then cd into libs/math/test and do a: bjam gcc test_hypergeometric_dist0 test_hypergeometric_dist1 test_hypergeometric_dist2 test_hypergeometric_dist3 test_hypergeometric_dist4 test_hypergeometric_dist5 and if one or more fail then let me know the failure message and I'll put together a test case. Many thanks in advance! John.

2 2

Request for interest in the new Synchro library
by vicente.botet 10 Mar '09

10 Mar '09

Hi, I would like to know if the Boost community is interested in the Synchro library. Of course there is a lot of work to do, but I think that there is enough material to start a discussion on the approach. I'd appreciate it if people could take a look, test it on their compiler and give me some feedback. The library is available at Boost Sandbox: https://svn.boost.org/svn/boost/sandbox/synchro and Boost Vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=synchr… that iIncludes every thing on the Sandbox + Html documentation Some examples use Boost.Interthreads also (available on the vault and the sandbox). This library is a compilation of what I have found in the literature not yet present in Boost. My main concern has been to boostify all these ideas in a coherent way. Next follows an overview of the library features: Boost.Synchro provides: * A uniform usage of Boost.Thread and Boost.Interprocess synchronization mechanisms based on lockables(mutexes) concepts and locker(guards) concepts. o lockables traits and lock generators, o lock adapters of the Boost.Thread and Boost.Interprocess lockable models, o locker adapters of the Boost.Thread and Boost.Interprocess lockers models, o complete them with the corresponding models for single-threaded programs: null_mutex and null_condition classes, o locking families, o semaphore, o condition_lockable lock which put together a lock and its associated conditions. * A coherent exception based timed lock approach, * A rich palette of lockers as o strict_locker, nested_strict_locker, o condition_locker, o reverse_locker, nested_reverse_locker, o locking_ptr, on_dereference_locking_ptr, o externally_locked, * A polymorphic lockable hierarchy. * High-level abstractions for handling more complicated synchronization problems, including o monitor for guaranteeing exclusive access to an object, and o a so-called rendezvous mechanism for handling direct communication between objects concurrent_components via ports using an accept-synchronize protocol based on the design of the concurrency library in the Beta language. On going work * array_locker and tuple_locker locker containers. * A complement to the already present in Boost.Thread lock, try_lock free functions: o lock_until, lock_for, try_lock_until, try_lock_for Best regrads, Vicente Juan Botet Escribá

3 12