- Boost - lists.boost.org

What Should we do About Boost.Test?
by Dave Abrahams 17 Sep '12

17 Sep '12

Hi All, I was just going through Boost.Test to try to figure out how to teach it, and while it looks to have substantial value, it is also in quite a mess. It contains loads of features that are exercised in the examples/ directory but neither included in any of the tests nor documented. There are facilities for command-line argument parsing! There are "decorators" that turn on/off features for test cases. There is support for mock objects! These are cool and sometimes necessary features, but who knew? The third tutorial page (http://www.boost.org/doc/libs/1_51_0/libs/test/doc/html/tutorials/new-year-…) has a glaring typo in the code examples: "BOOST_AUTO_EST_CASE". There's no reference manual at all. There are nearly-identical files in the examples/ directory called "est_example1.cpp" and "test_example1.cpp" (Did the "t" key on someone's keyboard break?) I could go on, but where would I stop? I don't know what to do about this. Because of the lack of redundancy (i.e. tests and documentation), it's hard to tell whether this library is correct or even to define what "correct" should mean. It seems like, as long as the code is incompletely / incorrectly documented and tested, it's just someone's personal coding project that we happen to keep shipping with Boost, and not really a library for general use. This situation reflects poorly on Boost as a whole and the fact that it centers around a _testing_ library, which is concerned with robustness... well, let's just say that the irony isn't lost on me. I don't mean this posting as an attack on Gennadiy in any way, but I think the situation is unacceptable and therefore am opening a discussion about what should happen. As a straw man, I'll make this suggestion: - Boost.Test is officially deprecated in the next release - Its documentation, such as it is, is removed from the release after that - Meanwhile, other tests in Boost that use this library are rewritten to use a different mechanism

1 1

[Review:Contract] Boost.Contract Library is Accepted
by Dave Abrahams 17 Sep '12

17 Sep '12

Lorenzo Caminiti's Boost.Contract Library is hereby accepted into Boost. I will be brief but that should in no way be construed as a lack of enthusiasm. Reviewing the review commentary was a genuine pleasure. Anyone interested in this domain could learn a lot by going through the threads the way I did. There were five "yes" votes, one of which was very late (but I'm counting it), and one of which was conditional, and one "no" vote. I am accepting the library unconditionally because of Lorenzo's demonstrated responsiveness to issues. He gave thoughtful responses to the review comments and entered every issue raised that remained open into a bug database (http://sourceforge.net/apps/trac/contractpp/report/3) Congratulations, Lorenzo! -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

4 4

boost::asio::detail::win_iocp_io_service
by xakepp35 17 Sep '12

17 Sep '12

good time of day. i need to extend some basic boost functionality and performance by 1) variable timeouts in poll/run 2) replacing GetQueuedCompletionStatus with GetQueuedCompletionStatusEx and parallelized vectored i/o handling with single kernel/user transition so how can i replace win_iocp_io_service with my own implementation without modifying it's code inside "io_service.hpp"? there are HARD-CODED strings inside "io_service.hpp" like namespace detail { typedef win_iocp_io_service io_service_impl; } which better be something like user #define or template with default argument (like allocator) how do you suppose user may provide it's own implementation? how can i use my_iocp_io_service, declared and implemented within my executable's sources? -- View this message in context: http://boost.2283326.n4.nabble.com/boost-asio-detail-win-iocp-io-service-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[review][coroutine] A Late Review
by Stewart, Robert 17 Sep '12

17 Sep '12

Coroutine should be accepted into Boost conditionally. My hesitation comes from the seemingly significant design and interface changes occurring during the review. I'm unsure how the current state compares to the library I reviewed. This leaves me wondering what is being accepted. I don't think the functionality of the library is changing, so I'm confident in accepting it on that basis. However, I think that a mini-review is needed to verify the finished design and documentation before final acceptance. ***** What is your evaluation of the design? I dislike the namespace. "coro" is meaningless and awkward. The namespace name should be "coroutines" (since there is a class named "coroutine", it must be plural). What users may choose as an alias is another matter. I wonder whether assertions can be added to flag calls of operator() from within a coroutine or generator. I know that's undefined behavior, but an assertion will catch the mistake in non-optimized builds. ***** What is your evaluation of the implementation? The source has major whitespace issues. It looks like a botched tab-to-spaces conversion. The move assignment operators do a self-assignment check. That is a "performance bug", as Howard Hinnant puts it. There are no comments in the code. This means Oliver's own maintenance will be harder, but it particularly means that it will be harder for anyone else to pick up the library's maintenance to help or replace Oliver in the future. The code looks well factored, though I certainly didn't spend a long time studying it. ***** What is your evaluation of the documentation? There is no Motivation section. The documentation must catch the attention of the reader right on the first page. Why should anyone care about this library? What can it do for them? Why should anyone spend time reading the rest of the documentation? Overall, the documentation is a good introduction to the library. The examples are appropriate for tutorial purposes, but there is a complete lack of non-trivial examples to illustrate how the library can be employed. What can one do with this library that isn't possible otherwise? What is better, according to any number of criteria like less code, faster, etc., using this library? How much of the interface remains what was designed by Giovanni Piero Deretta? Given all of the changes during the review, I wonder how much remains. The "Executing a coroutine" section of coroutine.html could do with a sentence about the coroutine-function's signature as, say, a new, third sentence in the first paragraph: "The coroutine-function can take arguments and return values as discussed in the next section." The "Exceptions in coroutine-function" section of coroutine.html, and the corresponding section of generator.html, suggests that exceptions must be thrown using Boost.Exception. Is that the intent? If so, you need to make that point clear. I suppose that isn't true in C++11. Also, what is the namespace of forced_unwind? This section is the first mention of it, so one is left to wonder if it belongs to the library or not. The "FPU preserving" sections of coroutine.html and generator.html imply that the library allows to prevent preserving the FPU registers, but gives no information about how that is done or where to read more about it. Also, the note, in those sections, references "ABIs", but gives no references and fails to specify which ABIs are meant. The coroutine and generator synopses, in coroutine/coroutine.html and generator/generator.html, are confusing. The definition of self_t refers to undefined types T and R. The synopsis of coroutine suggests that the type is not copyable Some detailed comments are at the end of this message. ***** What is your evaluation of the potential usefulness of the library? I think this library will be extremely useful. I think it could have profound implications for the design of libraries that rely on multiple threads today. Indeed, there is a use case in some current code in one of our applications that, I think, would be simplified yet improved by using this library. - Did you try to use the library? With what compiler? Did you have any problems? Unfortunately, and despite the lateness of my review, I've had no time to try it. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent several hours reading the documentation, and a fraction of that looking over the code. ***** Are you knowledgeable about the problem domain? No. ___________________ Documentation Comments ________________ coroutine/coroutine.html The illustration of make_coroutine() is accompanied by no description, so f() should be omitted. It adds nothing one cannot infer from the signature and raises questions about what c and, in turn, f() actually does. In the first warning, s/coroutine/a coroutine/. In the second, s/::FlsAlloc(), ::FlsFree()/::FlsAlloc() and ::FlsFree()/. s/stack-allocator/stack allocator/ Odd internal spacing for parentheses: one space after the open parenthesis, and no space before the close parenthesis. s/operator()()/operator()/ s/flags, and stack and instruction/flags, stack, and instruction/ s/value of local variable is preserved/value of local variable i is preserved/ "yield was called so we returned" is confusing. The coroutine hasn't been called by that point. That comment should probably be, "while the coroutine hasn't returned" (or "finished"). In Transfer of data, the last sentence of the second paragraph (after the note) is rather confusing and includes a grammatical error. I suggest this instead: "The arguments passed to coroutine<>::operator(), in one coroutine, are passed to coroutine<>::self_t::yield() in the other coroutine, except for the first invocation of coroutine<>::operator(), which passes them to the coroutine- function, instead." The example in Transfer of data could use with a few more comments. Specifically, "int x = c(7)" could use the comment, "x is 7 because c(7) passes 7 to fn, where self.yield(i) passes i == 7 back", and "x = c(10)" could use the comment, "x is 10 because c(10) causes "self.yield(i)" to return 10 in fn(), so fn() returns j == 10". While you're at it, s/j == 10 because c( 10) in main()/j == 10 because of c(10) in main()/. The coroutine-function with multiple arguments example deserves some comments explaining why yield() gets one int argument and returns a two-int tuple and why the function returns one int, to tie those aspects into the Signature template argument. The Exit a coroutine-function section discusses yield_break(), but the example calls yield_return(). In the Important note within Exit a coroutine-function, s/complete (can not resumed/complete and cannot be resumed/. In Stack unwinding, s/(stack is unwound by default)/(the default)/. In FPU preserving's note, s/ABIs the/ABIs, the/. ________________ coroutine/coroutine/coroutine.html In the Effects of the template constructor, s/stack before destructing it/stack before releasing it/. In the Effects of the function call operator, the wording can be improved: "Invokes the coroutine-function with the supplied arguments, returning the argument passed to self_t::yield()." Likewise, the Throws clause: "Any exception emitted by the coroutine-function or coroutine_terminated if self_t::yield_break() is called." The Effects of self_t::yield() can be improved: "Returns execution control to the calling context, arranging for the calling context's operator() to return r." (You need to make the argument list "(R r)" for that description.) Next, yield() needs a "Returns" clause: "Returns: " Arguments passed to the calling context's operator()." Change the Effects clause for yield_break() to: "Marks the coroutine complete and returns execution control back to the calling coroutine in such a way as to cause the calling coroutine's operator() to emit a coroutine_terminated exception." ______________ generator.html s/yielding a values/yielding values/ s/and can be returned/, so they can be returned/ make_generator() is not introduced. The illustration of make_generator() is accompanied by no description, so f() should be omitted. It adds nothing one cannot infer from the signature and raises questions about what c and, in turn, f() actually does. (If you choose to keep it, perhaps "g" is a better identifier for a generator.) In the second note, s/::FlsAlloc(), ::FlsFree()/::FlsAlloc() and ::FlsFree()/. Also, that same information is marked as a warning for coroutine. In the warning, s/If generator/If a generator/. There are no comments in most of the examples on this page. The fifth paragraph of Executing a generator needs to be rewritten to fix mistakes and improve clarity: "A generator is usually called inside a loop. The generator- function calls generator<>::self_t::yield() to produce a value. When the generator is called a second or subsequent time, the generator-function resumes execution after the yield() call. If a generator-function must be called no more, it can call generator<>::self_t::yield_break()." The sixth paragraph also needs to be rewritten: "The generator-function is invoked the first time from the generator's constructor. generator<>::operator() can be called while the generator is valid (while generator<>::operator unspecified_bool_type() returns true). When the generator-function cannot return more values, it can return a value or call generator<>::self_t::yield_break(). The latter returns execution control back to the caller and marks the generator complete. Note that generator<>::operator() does not thrown an exception, unlike a coroutine." (It isn't clear whether returning from a generator-function marks a generator complete.) In the last Executing a generator example, the "yield was called so we returned" comment within main() is a bit unclear. I suggest, "calls fn()" on g's construction and "fn()called self.yield(), so control returned here" on "while (g)". In the Important note within Exit a generator-function, s/complete (can not resumed/complete and cannot be resumed/. _______________ generator/generator.html The Effects clause of operator() would be better separated into an Effects and a Return clause: "Effects: " Invokes the generator-function." "Returns: " The value passed to self_t::yield() by the generator-function." Likewise, for self_t::yield(): "Effects: " Returns execution control to the calling context such that generator<>::operator() returns r in the calling context. "Returns: " The arguments passed to generator<>::operator() in the " calling context." The Effects clause for self_t::yield_break() is incorrect. I suggest the following: "Marks the generator complete and returns execution control to the calling context." _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 2

Proposed new RAII Library
by Andrew Sandoval 17 Sep '12

17 Sep '12

I'd like to propose a new Boost library for RAII wrapper classes that I think could be standardized to help promote the use of RAII. Though shared_ptr, scoped_ptr, etc. greatly enhance the use of RAII, I propose two additional classes. The first of these is RAIIFunction (I'm open to other names and coding conventions). This one is very simple, but powerful. It's a small wrapper (using composition) around std::tr1::function, that simply calls the function on scope-exit, in the normal case. Unlike Boost.ScopeExit, it uses no macros. Anything that can be assigned to a std::tr1::function<AnyType> taking no parameters will work with it, so lambdas are perfect -- and allow for all of the associated benefits like capturing variables by reference, etc. It also works with std::tr1::bind / boost::bind, with no placeholders. // // RAIIFunction<> Written by Andrew L. Sandoval 2011/2012 // Include guard here #include <functional> // // An RAII class that works with std::tr1::bind and lambdas // NOTE: making a const RAIIFunction prevents the use of Invoke() // and Cancel() and operator=(fn) which is often appropriate // NOTE: m_func copies the original function object, so that const and // non-const refs can be passed in, etc. template <typename TRet> class RAIIFunction { private: std::tr1::function<TRet ()> m_func; bool m_bInvoke; RAIIFunction(); RAIIFunction(const RAIIFunction &); void operator=(const RAIIFunction &); public: RAIIFunction(const std::tr1::function<TRet ()> &fn) : m_func(fn), m_bInvoke(true) { } void operator=(const std::tr1::function<TRet ()> &fn) { if(m_bInvoke) { m_func(); } m_bInvoke = true; m_func = fn; } ~RAIIFunction() { if(m_bInvoke) { m_func(); } } void Cancel() { m_bInvoke = false; } TRet Invoke(bool bRelease = false) { m_bInvoke = !bRelease; return m_func(); } }; Examples: const RAIIFunction<void> closeDB = ([pDB]() { if(pDB) { sqlite3_close(pDB); } }); // // while example... bool bContinue = true; RECORD record = { }; while(bContinue) { // Ensure that no matter how the loop wraps (continue or fall-through) the next // record is grabbed or the loop terminates... const RAIIFunction<void> loopAdvance = ([&bContinue]() { bContinue = SomeCallThatGetsAnotherRecord(record); }); // A bunch of record processing here ... } // // A convoluted example that shows assignment, etc. RAIIFunction<int> mb = std::tr1::bind(MessageBoxW, HWND_TOP, L"Present pop-up prompt again?", L"Test", MB_TOPMOST|MB_YESNO); int iMB = mb.Invoke(true); if(IDYES != iMB) { mb = ([]() ->int { dprintf("Printing what the user didn't wanted popped up" " on scope-exit...\n"); return 0; }); -- The other one I call just RAIIWrapper, and it works with static deleter functions taking a single argument of the type being delete. Since it includes a lot more code (much of which could probably be replaced with type_traits code), I'll just show examples of usage below to gauge interest. I first used an earlier version of this in an environment where the standard function required a goto ErrorExit (like Microsoft example driver code in the WDK) to clean-up all of the resources. The original concern was that the c++ class would bloat the deliverable size. This class proved to be as tight as the goto equivalent. It uses one macro that I'll include below. The class takes 3 template parameters: 1) The type of the deleter function, 2) the deleter function, and 3) a no-delete value that defaults to NULL. // // Simplify usage with a macro: #define RAIIDeleter(deleterFunction) decltype(&deleterFunction), deleterFunction // Example: const RAIIWrapper<RAIIDeleter(CloseHandle), INVALID_HANDLE_VALUE> hFile = CreateFile(pwzFileName, GENERIC_WRITE, FILE_SHARE_WRITE, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); if(!hFile.IsValid()) { // handle error... } // Similar but using the default no-delete value (NULL): const RAIIWrapper<RAIIDeleter(CloseHandle)> hEvent = CreateEvent(NULL, FALSE, FALSE, NULL); -- I've found that using RAII consistently can dramatically improve code quality. It forces the coder to think about resource lifetime at inception rather than at exit points, etc. Much of what I've shown above can be done with scoped_ptr or shared_ptr, but these specialized classes put the focus on RAII and resource management. Please let me know your thoughts. I'd love to see this become part of Boost, and hopefully eventually part of the C++ standard library. Thank You, Andrew Sandoval

13 56

[rational] optional over/underflow checking
by Dan Searles 17 Sep '12

17 Sep '12

>> https://svn.boost.org/svn/boost/sandbox/rational Sandbox now includes the test driver. All the updates are in the single rational header file, so this is a relatively small update. Rational.h, however, has had small updates before. This update centers on adding an optional over/underflow check, that would generate an exception if the result of an operation could not be represented with full numeric precision. Seeking comments on the update and any steps/requirements needed to get the update accepted for release. BTW, are there any status updates on the unlimited precision numeric class effort? Thanks, Dan Searles

2 1

Re: [boost] [result_of] Usage guidelines
by Andrey Semashev 17 Sep '12

17 Sep '12

Ok, here is my second take on this. I've attached a patch with my changes. 1. I moved the guidelines to a separate section in order not to clutter the formal result_of description. 2. I seperately outlined the C++11 and C++03 recommendations. 3. I left the result_of examples. I think they illustrate the result_of usage quite well, but I'll be happy if someone comes up with something better. 4. I rephrased some of the wording about result<> usage, in response to Jeffrey's reply. Comments are welcome.

4 6

[ASIO] async SSL operations unnecessary serialized?
by Michał Madziar 16 Sep '12

16 Sep '12

Hello all. It looks like all openssl_operation handlers are synchronized on io_service allowing only one connection to be processed at the a time. As I understand this orginated from the time when libopenSSL didn't support multi-threaded applications, but it slows down everything a lot. Adding locking function, and getting rid of strand_->wrap in lines 320, 385 in file boost/asio/ssl/detail/openssl_operation.hpp allows SSL connections to be used in multiple threads simultaneously solving the problem. Or do I miss something? I've attached simple line-based echo server which demonstrates the problem: openssl s_client -connect localhost:10001 #x 2 telnet localhost 10000 #x 2 After sending something in each connection TCP and one SSL work in parallel, second SSL waits with receiving until first one finishes it's write. After patching all connections work in parallel. -- Pozdrawiam Michał 'michoo' Madziar

2 3

{Review] Coroutine reviewstarts today, September 3rd
by Hartmut Kaiser 16 Sep '12

16 Sep '12

Hi all, The review of Oliver Kowalke's Boost.Coroutine library starts today, September 3rd 2012, and will end on September 12th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! ----------------------------------------------------- About the library: Boost.Coroutine provides templates for generalized subroutines (coroutines) which allow multiple entry points for suspending and resuming execution at certain locations. It preserves local state/data and allows re-entering subroutines more than once (useful if state must be kept across function calls). Coroutines can be viewed as a language-level construct providing a special kind of control flow. You can download the library and the view documentation here: docs: http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/ src: http://ok73.ok.funpic.de/boost.coroutine.zip --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - 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? Regards Hartmut Review Manager

7 23

[result_of] Make result_of doc separate from utility.htm
by Michel Morin 15 Sep '12

15 Sep '12

The documentation of result_of is contained in monolithic utility documentation: http://www.boost.org/libs/utility/utility.htm But I think result_of is worth having its own (i.e. separate) documentation. Comments? Regards, Michel

1 0