- Boost - lists.boost.org

Mentoring students
by Chris De Vries 05 Sep '08

05 Sep '08

Hi, My name is Chris De Vries and I am involved with the IEEE student branch at the Queensland University of Technology in Brisbane, Australia [1]. I am organizing a program that encourages students to become involved with open source. I am looking for projects that are interested in taking on students. The branch will be running an information session and I am hoping to list some projects that are willing to mentor students. Is Boost interested? Thanks, Chris De Vries [1] http://ewh.ieee.org/sb/queensland/qut/

2 1

Stacking iterators vs. dataflow
by Phil Endecott 05 Sep '08

05 Sep '08

I just noticed this in the "lifetime of ranges vs. iterators" thread (which I've not really been following): Arno Sch?dl wrote: > rng | filtered( funcA ) > | filtered( funcB ) > | filtered( funcC ) > | filtered( funcD ) > | filtered( funcE ) I thought it worth pointing out the similarity, and also the difference, between this and the proposed dataflow notation. Here, operator| is being used like a shell pipe operator. In dataflow, operator| has a quite different meaning: it's a vertical line, distributing the output of "rng" to the inputs of the funcs in parallel. Confusing, perhaps? Anyway you could presumably write something like rng >>= funcA >>= funcB .... and I would be interested to hear how the two implementations compare. Is it true to say that stacked iterators implement a "data pull" style, while dataflow implements "data push"? I also note that Arno wants to use stacked iterators because this alternative: result = fn1( fn2( fn3( fn4( huge_document ) ) ) ); creates large intermediates and requires dynamic allocation. Again, a framework that allowed buffering of "sensible size" chunks and potentially distributed the work between threads could be a good solution. Phil.

8 19

binary operator raits
by frederic.bron＠alcan.com 05 Sep '08

05 Sep '08

I have just commited new traits in the sandbox (sandbox/type_traits) to know if a type is comparable or not. I have included tests but could not make bjam and quickbook run together so I have no documentation to commit. The names of the traits are based on standard header <functional>: is_less_comparable<T>, is_less_equal_comparable<T>, is_greater_comparable<T>, is_greater_equal_comparable<T>, is_ equal_to_comparable<T> and is_not_equal_to_comparable<T>. Some comments about these traits: - I was not able to remove the warnings, - the traits inherits from true_type is the operator exists, however, I am not sure if we should return true if the binary operator does not return a type convertible to bool F. Bron Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

1 0

Asio and SSL problem
by Berserker 05 Sep '08

05 Sep '08

I tried to post this problem in the asio mailing list but I hadn't any feedback, so I'm reporting it here with the hope that someone can help me. I have a "stack overflow" problem with the following code (using boost 1.36): void test_handshake(const std::string &host, const std::string &cert) { boost::asio::io_service service; boost::asio::ssl::context sslContext(service, boost::asio::ssl::context::sslv23); sslContext.set_verify_mode(boost::asio::ssl::context::verify_peer); sslContext.load_verify_file(cert); boost::asio::ip::tcp::resolver resolver(service); boost::asio::ip::tcp::resolver::iterator endpoint_iterator = resolver.resolve(boost::asio::ip::tcp::resolver::query(host, "443")); boost::asio::ip::tcp::resolver::iterator end; boost::asio::ssl::stream<boost::asio::ip::tcp::socket> sslSocket(service, sslContext); boost::system::error_code error = boost::asio::error::host_not_found; while(error && endpoint_iterator != end) { sslSocket.next_layer().close(); sslSocket.next_layer().connect(*endpoint_iterator++, error); } if(error) throw boost::system::system_error(error); sslSocket.handshake(boost::asio::ssl::stream_base::client); // bla bla } When I call this function with a valid certificate for the host I have no problems, but when I pass a "custom" cerificate (not valid for the host specified) it results in a stack overflow error instead of throwing an exception as I expected... This example works: test_handshake("sourceforge.net", "cacerts.pem"); // grab cacerts.pem from here for example: http://www.cs.fsu.edu/~engelen/soapcacerts.html This causes, as I said, a stack overflow instead of an exception: test_handshake("sourceforge.net", "ca.pem"); // ca.pem was taken from the asio examples Plz help P.S.: is anyone using asio with ssl? It's very strange that nobody has reported this problem... _________________________________________________________________ Cerchi un locale per la serata? Chiedilo a Live Maps! http://maps.live.it/

2 1

Boost::log query
by Rajpal Dangi 05 Sep '08

05 Sep '08

While using rotating text file as stream, is it possible to keep most recent log file name same all the time? Currently what I observe is 'N' keeps incrementing and have to manually find out the most recent file. Also, is there some way to print severity in log file without explicitly passing it as part of message i.e. BOOST_LOG_SEV(my_logger, CRITICAL) Thanks

2 5

[testing] How not to mark up explicit failures
by David Abrahams 05 Sep '08

05 Sep '08

https://svn.boost.org/trac/boost/ticket/2258 describes a problem with explicit failure markup that I suspect is not atypical. I believe we need to establish some ground rules for markup that ensure * Boost problems don't pass unnoticed * there is a uniform standard for interpreting test results across libraries * "non-Boost problems" and non-problems don't add alarm bells for people reading test results You can view the markup in question here: https://svn.boost.org/trac/boost/browser/trunk/status/explicit-failures-mar… Aside from the specifics in the ticket, the following problems jump out at me just from looking at that XML: * even on compilers that do support nonstandard calling conventions, failures in these tests will never be flagged as problematic * even on compilers that don't support nonstandard calling conventions, these tests will fail and add useless noise to the chart. I can think of a few general principles and practices that will prevent such problems: * Boost regression tests should test the functionality of code that is expected to work, not to test the capabilities of the platform or C++ implementation. There is a place for capability testing, but it needs to be segregated from regular regression tests somehow. If/when we move to using CMake globally, capability tests should take place in its configure stage. In the meantime, such tests must be kept out of Boost regression testing. * Tests that do not apply to a given compiler or platform should ideally not be run on that compiler. * If we can't find a way to avoid running the test at all, the test should be written to trivially succeed on that compiler or platform. * Test annotation wildcards should be written restrictively so that they only match the compilers/platforms to which they apply. This is probably just a start; I'd like to hear other ideas. I intend that this thread will result in an official Boost policy for test annotation. Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

[review] FSM Second Call for Reviews
by Martin Vuille 04 Sep '08

04 Sep '08

The formal review for Andrey Semashev's Finite State Machines (FSM) library has been running for a week now and continues until the 20th. There have been some lively discussions about the library, but no one has yet entered an explicit yes or no vote. If there are no votes either way, the FSM library submission will be rejected by default. If you wish to review, but don't have time before the review period ends on the 20th, please let me know as it may be possible to extend the review period. And, finally, a reminder to include an explicit "for" or "against" vote in your review. ----------- The documentation (overview and reference) is available online: http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.html http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) There has already been some discussion of the library since the rewiew was first announced: http://www.nabble.com/FSM-Review-Announcement-to18820219.html http://www.nabble.com/FSM-Review-Reminder-to18890305.html ----------- Description ----------- "The main goals of the library are: * Simplicity. It should be very simple to create state machine using this library. * Performance. The state machine infrastructure should not be very time and memory-consuming in order to be applicable in more use cases. * Extensibility. A developer may want to add more states to the existing state machine, and this addition should be relatively safe since it shouldn't interfere with the existing states. The developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code." "Boost.FSM vs. Boost.Statechart There is another library in Boost that provides similar functionality: Boost.Statechart. Although it currently covers almost all major Boost.FSM features and provides ones that are not supported in this library, Boost.Statechart is more targeted to creation of big and complex state machines with possibility of distributed development. But this does not come at no price and Statechart has little tools for compile-time programming and does not provide as much run-time performance as Boost.FSM does. So there are main guidelines for users to make a decision between Boost.FSM and Boost.Statechart: [...]" "The following compilers are known to have problems or most likely will have ones: * Microsoft Visual C++ 6.0 and 7.0. Most probably will fail to compile due to lack of partial template specialization support. * Borland C++ Builder 5.5.1 (free version). Fails to compile due to lack of partial template specialization and in-class using declarations support. Some other minor problems also have been noticed. Newer versions of the compiler have not been tested. * OpenWatcom 1.5. Fails to compile due to problems with Boost.MPL code. Newer versions of the compiler have not been tested. * SunPro C++ Compiler 5.5 for Solaris (SPARC). Most likely will show problems with function overload resolution. Newer versions of the compiler have not been tested." The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) ---------------------------------- What to include in Review Comments ---------------------------------- Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. 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. Thanks in advance for your participation in this review. MV

7 26

[1.35.x] Any critical bugfixes?
by David Abrahams 04 Sep '08

04 Sep '08

Hi all, I'm trying to compile a list of critical bugfixes and workaround for users of Boost 1.35.0. I already got this information on Boost.Threads and Boost.Filesystem from their respective maintainers. If anyone knows of further issues I would appreciate hearing about them. The ideal would be to refer me to the changeset in our SVN that addresses the issue, but any information would be most appreciated. Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 1

[iterator] could non-small predicates/functors be stored as boost::optional<T> to avoid double construction?
by Thorsten Ottosen 04 Sep '08

04 Sep '08

Hi, The headline pretty much says it all. Take transform iterator. When the predicate is not trivial, we also have a redundant construction of the object in the end iterator. Maybe that could be removed? best regards -Thorsten

5 8

[math] svn rev 48294 (2008-08-22) breaks gcc 3.2 builds
by Ralf W. Grosse-Kunstleve 04 Sep '08

04 Sep '08

Hi, This svn revision... ------------------------------------------------------------------------ r48294 | johnmaddock | 2008-08-22 05:51:40 -0700 (Fri, 22 Aug 2008) | 1 line Merged changes from sandbox, and regenerated the docs. ------------------------------------------------------------------------ broke our gcc 3.2 builds. (Sorry I couldn't report this earlier; I was out of town.) The minimal reproducer is simply: #include <boost/math/special_functions/atanh.hpp> % g++ -c -Iboost atanh.cpp In file included from boost/boost/math/special_functions/atanh.hpp:24, from atanh.cpp:1: boost/boost/math/special_functions/log1p.hpp:456: new declaration ` template<class T> T boost::math::log1pmx(T)' boost/boost/math/special_functions/math_fwd.hpp:491: ambiguates old declaration `template<class T> boost::math::tools::promote_args<RT, float, float, float, float, float>::type boost::math::log1pmx(T)' % g++ --version g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20) I can make the error go away with the simple-minded patch below, just to prove that the ifdefed-out code is the only problem for us. I'd be happy to try out ideas for proper workarounds. Ralf Index: boost/math/special_functions/log1p.hpp =================================================================== --- boost/math/special_functions/log1p.hpp (revision 48578) +++ boost/math/special_functions/log1p.hpp (working copy) @@ -451,11 +451,13 @@ return result; } +#if !(defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 2) template <class T> inline T log1pmx(T x) { return log1pmx(x, policies::policy<>()); } +#endif } // namespace math } // namespace boost

1 0