- Boost - lists.boost.org

unable to merge trunk
by Oliver Kowalke 17 Sep '12

17 Sep '12

could I get a little bit more time to merge trunk into release? currently subversion fails with strange errors: svn merge ../../../boost-trunk/libs/context svn: error executing »xxdiff-subversion«: return value: 255, parameter: in directory ».«, Basename: doc/.svn/tmp/svn-z6MhPR /tmp/svn-1pKQPw doc/.svn/tmp/svn-wdZ3Xa svn: error reading answer of REPORT request from hdd Oliver

2 2

[Review.Contract] Vicente's review
by Vicente J. Botet Escriba 17 Sep '12

17 Sep '12

Hi, here is my short review. My vote is YES subject to these condition. * Removal of the Concepts part. The use of Boost.ConceptCheck to emulate C++ concepts proposal is in my opinion erroneous. Boost.Concept.Check is used to assert the actual parameter satisfy statically the concept conditions, while if I'm not wrong the C++ Concepts proposal use the requires clause to state the conditions of a possible instantiations. Using the same grammar with different semantics is confusing. In a last resort, if this feature is preserved, the requires keyword must be changed by another one. * static assertions are removed from the pre/post conditions. They can be moved to a specific "static assertions" section at the same level than the requires clause. This section could also include the concept check included now in the requires clause. * The library extends the EDSL to use directly C++11 features, in particular move semantics. Now that since the C++11 standard is released, more and more people are using C++11 specific features. I, in particular, will not use Contract if I can not make use of C++11 features provided by the compiler. * The contract broken handlers are noexcept, so that adding contracts don't change the original prototype. === STANDARD REVIEW QUESTIONS === * What is your evaluation of the design? While Lorenzo has show that using the preprocessor we can define a EDSL that is close to the native syntax (besides the parentheses stuff), the resulting interface is *closed* and interacts badly with c++ features not taken in account by the EDSL. I'm guessing that the user can not extend this EDSL without modifying the library. This is also the case of other libraries that make use of the pre-procesor to define a EDSL as Boost.Parameters or Toward Boost.Generics. It will be great if the user can extend the EDSL, but I suppose this could be very hard, if not impossible. I understand that Lorenzo is trying to reduce the preprocessor time using whatever is needed, but making the interface more complex would not help to improve the usability. I'm not sure the _TPL macros are really needed and whether the resulting code could perform better or not. * What is your evaluation of the implementation? I've not look inside. * What is your evaluation of the documentation? Very good. I would appreciate if the documentation includes a sections showing what is behind the scenes, what is generated by these macros. It would be great if you add a section/table with all the limitations, as e.g. these ones * Function and array types cannot be directly used as function parameter types within the contract macros ... * Each function parameter must always specify both its type and its name (parameter names can instead by omitted in usual C++ declarations). * All tokens must be specified in the fixed order listed in theGrammar section (it is not possible to specify postconditions before preconditions,|volatile| before|const| for member functions, etc). * Unfortunately, this library does not allow to specify contracts for unions. * Unfortunately, when member initializers are specified, the constructor body must be defined together with its declaration and contract * What is your evaluation of the potential usefulness of the library? I don't think the library could be used in a industrial context. The domain of this preprocessor EDSL is too large (C++ declarations + contracts + named parameters + concepts) and we will need to expand it yet to be useful (c++11, compiler specifics, ...). While the syntax is quite close to C++ syntax the library intends to emulate, the compiler errors will be quite unreadables. * Did you try to use the library? With what compiler? Did you have any problems? No. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have not do a in-depth study. I has been concentrated inspecting the usability of the library and trying to identify the limitations it could introduce. * Are you knowledgeable about the problem domain? Yes, from a theoretical point of view. I have never used contract programming in real world projects. Best, Vicente

4 12

[Review:Contract]
by Roland Bock 17 Sep '12

17 Sep '12

Hi, first of all, YES, the library should be included in BOOST, in my opinion. In addition: * What is your evaluation of the design? Very cool. Looks like a 1:1 translations from some good algorithm books into code :-) * What is your evaluation of the implementation? I spent some time browsing through the macro code hoping it would help me to solve a problem of my own which looked similar (turned out it wasn't). Never being a fan of too much macro code, I have to say that this is very nicely written! My only concerns: - It seems to me that the implementation is spread over more files than necessary. It made following the call stack a bit tiresome. - I a bit torn between a) Steven's comment who would like to see CONTRACT_OLDOF being replaced by the would-be keyword in a possible future standard b) boost macros being clearly visible as such, leaving translation to future standard keywords to the user of the library, e.g. #define foreach BOOST_FOREACH I tend towards b). * What is your evaluation of the documentation? Excellent! * What is your evaluation of the potential usefulness of the library? It is a very good proof of concept and hopefully the basis for continued discussions about including contracts into the C++ language. Due to a lack of formal contracts in much of day to day programming and the enormous compile time overhead, I don't see the library being used all over the place anytime soon, but I expect it to be used in generic algorithms, helping both developers and library users. * Did you try to use the library? With what compiler? Did you have any problems? Sadly: No. Did not find the time. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a few hours with the code, maybe two hours with the documentation and I followed some of the discussions during the review period. * Are you knowledgeable about the problem domain? I would not call myself an expert, but I know enough to say: I'd really like to have Boost.Contract available the next time I write a mission-critical function/class/library! Best regards, Roland PS: Sorry for being late. I'm hoping for lenience since the review period was announced a bit late as well :-)

4 8

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