- Boost - lists.boost.org

Interest in UDL suffixes for built-in and some standard library types?
by Peter Sommerlad 08 Sep '12

08 Sep '12

Dear boost members, I am preparing a paper for the next C++ standardization meeting for providing user-defined-literals for some standard types. b (and a variety of derivations lik bULL) for binary integer literals as in 101b s for std::string as "hello, world!"s s, h, min, etc. for std::chrono::duration literals such as 0xfh for 15 hours i, r for creating std::complex literals see http://wiki.hsr.ch/PeterSommerlad/wiki.cgi?LiteralsForBinaryStringComplexDu… for the paper draft. It also includes machinery to parse integers using the template version of a user-defined literal, because using constexpr operator"" foo(unsigned long long bar); overload loses the ability to treat the number bar as a compile-time constant, e.g., to use as template argument further on. Some people told me, such a facility would be nice in its own way, to be used by other authors of UDL constexpr overloads. I wonder if there is interest to provide standard conforming versions of my implementation (including the required _ prefix) for boost (which would require to clean up things a bit beforehand). Such a boost.suffixes library would only work with C++11 capable compilers that actually implement UDL and constexpr in combination (for some uses the constexpr is not required). gcc4.7.1 is fine, for example, my version of clang didn't do constexpr yet (that might have changed). Feedback, encouragement and thoughts are welcome. TIA and Best Regards Peter. -- Prof. Peter Sommerlad Institut für Software: Bessere Software - Einfach, Schneller! HSR Hochschule für Technik Rapperswil Oberseestr 10, Postfach 1475, CH-8640 Rapperswil http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includator.com tel:+41 55 222 49 84 == mobile:+41 79 432 23 32 fax:+41 55 222 46 29 == mailto:peter.sommerlad@hsr.ch

2 1

Newbie question: Can't see my own posts
by Peter Sommerlad 07 Sep '12

07 Sep '12

Hi, it seems to me that I cannot see my own posts. For one containing a hyperlink I got a post confirmation but it never reached me: > Your message entitled > > Interest in UDL suffixes for built-in and some standard library types? > > was successfully received by the Boost mailing list. Did anybody see that message? Regards and thanks for your help Peter. -- Prof. Peter Sommerlad Institut für Software: Bessere Software - Einfach, Schneller! HSR Hochschule für Technik Rapperswil Oberseestr 10, Postfach 1475, CH-8640 Rapperswil http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includator.com tel:+41 55 222 49 84 == mobile:+41 79 432 23 32 fax:+41 55 222 46 29 == mailto:peter.sommerlad@hsr.ch

2 1

[heap] typedef T gets prevalence over template parameter
by Alex Hagen-Zanker 07 Sep '12

07 Sep '12

Hi, The d_ary_heap does not compile (in VS2010) when the Comparison class contains a typedef T. The typedef takes prevalence over the template parameter T when the heap is derived from the Comparison class. I.e. the following pattern occurs: template<class T, class Cmp> struct heap_base : Cmp { typedef T value_type; // value_type = Cmp::T } I don't know if this is a bug, a user issue, or a compiler issue. But it caused me a lot of headache when I was trying to apply Jeremiah's indirect_cmp with Boost.Heap. See below for a complete failing example. Kind regards, Alex #include <boost/heap/d_ary_heap.hpp> struct less { typedef int T; bool operator()(const int& a, const int& b) const { return a < b; } }; int main() { boost::heap::d_ary_heap<int, boost::heap::compare<less>, boost::heap::arity<4> > my_heap; return 0; }

3 5

[Review] Coroutine : Christopher's Review
by Christopher Kormanyos 07 Sep '12

07 Sep '12

(I lost the initial review announcement.) Yes, I vote that Coroutine should be accepted into Boost! General impression of the library: Coroutine offers enormous potential for programming regimes such as communications software and embedded systems design. For example, a lightweight event/alarm-based cooperative multitasking scheduler for embedded systems can be readily implemented usingCoroutine combined with a timer resource. Oliver has selected a sensible granularity for Coroutine. It includes Boost.Context, Coroutine and the proposed Boost.Fiber. This granularity allows for fine-tuning the implementations of cooperative scheduling mechanisms while avoiding the prohibitively heavy weight of preemptive scheduling that is found in POSIX and often in implementations of the C++11 thread support library. The documentation is terse, yet complete and informative. The examples are good. The design of Coroutine is clearly thought through. In particular, the separation of Coroutine from Context allows for porting to other systems with minimal effort and maximum reliability and code re-use. How long did I work with Coroutine? I worked for about 1 week with Coroutine. In particular, I worked very intensively with Coroutine for 2 days straight. I used Coroutine with VS2010, VS2012-RC and several GNU compilers. I spent a lot of time deeply embedding Coroutine in a hard real-time system. This experience has led to the comments and suggestions shown below. Am I familiar with the regime of Coroutine? Yes. I am absolutely familiar with the regime of Coroutine. I have authored many cooperative multitasking schedulers for a variety of CPU architectures and shipped them in tens of millions of devices. Suggestions for Coroutine: I have several suggestions for Coroutine, none of which stand in the way of immediate acceptance into Boost. 1) The code may potentially benefit from some clean-up. In particular, there is a mixture of tabs and spaces in the code, possibly resulting from programming over two or more time epochs with different styles. A simple reformat will clean this up. Coroutine is desperately needed in the embedded systems community. Along these lines, I suggests some extensions. 2) There should be, let's say, a *lightweight* version (or configuration) of Coroutine for embedded systems 3) The lightweight version can not use the non-placement version of new(). The internal details of a coroutine are stored in the class as a pointer created with non-placement new(). The lightweight version could add a parameter for user-supplied memory and create the coroutine implementation details with placement-new(). 4) Furthermore, the lightweight version should not not use any exceptions whatsoever. I spent two solid hours removing all traces of exceptions while embedding Coroutine. The result was a lightweight mechanism that only costed a few kilobytes of program code. 5) We need to work together to create more contexts for different CPU architectures. The ARM(R) context that is present in Boost.Context uses several ASM operations that my ARM(R) Cortex(R)-M3 does not support. For this reason, I could not complete my benchmark. We can work on this in the future. Thank you for your efforts and good luck! Best regards, Chris.

3 2

[rational] Over/underflow checked update ready for comments
by Dan Searles 07 Sep '12

07 Sep '12

Le 06/09/12 04:28, Dan Searles a ?crit :>Le 06/09/12 04:28, Dan Searles a ?crit : >>>> For those interested in the rational number class, see: >>>> https://svn.boost.org/svn/boost/sandbox/rational >>>> >>>> Requesting comments on the code, and review for >>>> inclusion in the next release. >>>> >>>> >>> Hi, >>> >>> the enum type could follow the one defined in >>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html >>> "When an overflow does occur, the desirable behavior depends on the >>> application, so programmers may specify the overflow mode with a value >>> of type |enum class overflow|. The possible values are: >>> >>> |impossible| >>> Programmer analysis of the program has determined that overflow >>> cannot occur. Uses of this mode should be accompanied by an argument >>> supporting the conclusion. >>> |undefined| >>> Programmers are willing to accept undefined behavior in the event of >>> an overflow. >>> |modulus| >>> The assigned value is the dynamic value mod the range of the >>> variable. This mode makes sense only with unsigned numbers. It is >>> useful for angular measures. >>> |saturate| >>> If the dynamic value exceeds the range of the variable, assign the >>> nearest representable value. >>> |exception| >>> If the dynamic value exceeds the range of the variable, throw an >>> exception of type |std::overflow_error|. >> 'impossible' and 'undefined' are effectively the same thing, and >> equivalent to the 'no check' currently implemented. >Yes and not. Maybe from the point of view of the library, but this is a >useful information from the user point of view. So for the 'impossible' case, what should the library do when there is an over/underflow? >>> 'modulus' makes >>> more sense for the fixed point class that it's being described for >>> than rational numbers. I'm not sure a useful definition can even be >>> made for rationals. >>You are right. modulus for rational has not a clear sense. >> 'Saturate' sounds like it might be useful, but gets problematic >> quickly when there is under/overflow within the largest/smallest >> range limits. >Could you clarify? 'Saturate' implies returning the max value when the computed result is larger than can be represented, and returning the min value when the computed is smaller (more negative) than can be represented, but rationals can underflow between those extremes. For example, what is 1/2 * 1/maxint? >> The point is that if a result of a calculation is not >> exactly representable, you will get an exception to notify you. And of >> course 'exception' is in the new implementation for just that purpose. >A user can be interested in overflow check without exceptions. The >saturate policy should be a good replacement in context where exceptions >are not allowed. I can't quite see a point for there being 3 possible results when there is an overflow: exception, undefined, and ???. Maybe if '???' is a wrong value, but as close as possible? If you don't need the exact answers, float or double would probably be better. Returning zero for ??? might work. >Anyway, you should replace the CamelCase use in the definition of this >new enumeration. I think that basing your definition on the preceding >one could be acceptable. Which ones? Please suggest the names you think would be appropriate. (I tried to pick names that had a low probability of ever being used anywhere else. Common single dictionary words are probably not good.) >>> >>>> BTW, I have no access to the link for the examples and the test. >>> I have not changed those files. The existing examples and test >>> are still valid for the original non-checked case. For the checked >>> case, I have tests which run for hours. The tests for rational >>> instantiated with signed char is exhaustive (there are only so >>> many normalized values. Pairing up each value with every >>> other value on the binary operators doesn't result in much more >>> that 2**32 combinations). For short/int/long long, sets of interesting >>> values are created, and each value is paired up with every other >>> value in the set. I can provide the test drivers if anyone is >>> interested. >>I was interested by the examples and test using the new facility. Could >>you commit them in the sandbox, please? Uploaded the test driver to: https://svn.boost.org/svn/boost/sandbox/rational/Test_Rationals > >Best, >Vicente Thanks Dan Searles

2 1

[Review:Contract] Andrzej's review
by Andrzej Krzemienski 06 Sep '12

06 Sep '12

Hi, First, my vote is "YES": Contract should be accepted into Boost. Now for some details... === MOST IMPORTANT THINGS === (1) Let me start from the most important arguments. "Contract" enables us to use DbC design and tools in C++. This is the only library in C++ that I am aware of that takes DbC seriously, in every detail. In particular, unlike any "simple contract library," it observes that: (a) function pre- and post-conditions need to be part of declaration rather than function implementation, (b) a precondition is something different than a postcondition, (c) It is the execution of destructors of automatic objects that may (re)establish invariants or satisfy postconditions (thus, they need to be checked after destructors have been executed). "Contract" deals with things more detailed than my above list; but even this list is not always addressed in "simple contract libraries". This already gives me the confidence that Lorenzo has a very good understanding of the domain. I believe the community needs BbC framework: it is necessary in order to be able to program consciously. If the responsibilities and expectations are expressed clearly not only is it faster to track bugs, but also programmers would not plant (I think) some bugs from the outset. Of course, contract framework should ideally be provided as language extension; but in the absence of such support we are left with the attempts to implement it via a (possibly too clever) library. "Contract" may also enable and/or speed up the adoption of DbC as language feature in C++, as it will be possible to have a real-world implementation of the framework that people can play with, experiment and assess its usability. (2) An obvious and serious issue with the library is the burdensome syntax you have to use. Given the ambitious task of wrapping each function call with with tests executed before and after, and still leaving the bodies intact, I realize this is not avoidable. In fact I believe Lorenzo made the impossible to make the EDSL as close to normal declaration syntax as possible. Yet, all this may not be enough to call the interface "acceptable". There is a number of issues with it: you have to learn yet another language; compile times increase; if you mis-spell something you have horrible error messages; you cannot use some C++ constructs that you would otherwise use; your IDE and the debugger may be confused (if your contract fails, the bug may be either in your code or in the testing code). I cannot imagine telling my coworkers "from today on we are using Boost.Contract; start learning the new EDSL". I believe that it is not possible to significantly improve the current interface; its limitation is the natural consequence of the nature of the problem. The cost cannot be reduced any more, so the library can only offer even more value. And this is what it does, by (for instance) simplifying the integration with Boost.Concept or adding virtual specifiers. (3) I see it as a useful tool for personal projects, experimentation, learning, validation of usefulness of DbC, a proof of concept for proposal N1962. But the question is, should "Concept" be included into Boost. "Contract" needs inclusion into Boost to gain visibility and some sort of "attestation" and "certification". Only proposing "Contract" for addition to Boost brought attention to DbC: at least it prompted me to learn more. But does Boost need "Contract"? Similar questions have been asked during the review of Boost.LocalFunction. I am not aware of any objective criteria that would help decide in this case. Is this library of "high quality"? Can library with such interface be called "high quality"? But there is no other way to implement DbC in C++ (I believe)? But is it strong enough the argument? Perhaps we should treat some problems as "not implementable" and not include libraries only because there is no cleaner way to implement the tool. The decision to vote "yes" is not easily made. This is a subjective weighing between the offered value and the imposed cost. Personally, I would like to have this library available whenever I download Boost. === GENERAL OBSERVATIONS === (4) The library has very vast and very thorough documentation. It contains tutorials that teach you step by step how to use the library, the introduction into DbC, very detailed rationale, good reference, lots of examples. It is a good "reference documentation". (5) In order to define concept the library defines EDSL for declaring (and defining) classes and functions. This framework as the potential to do other useful things: enable support for concept definition and checking, base class aliases (see N2881), override control, named parameters, noexcept, simplified enable_if (or static if), etc... In fact, perhaps it could be used as a more general EDSL for declarations. This is my loose suggestion to change macro names from BOOST_CONCEPT_CLASS to BOOST_DECL_CLASS, etc, in case someone wants to use the framework for purposes other than contract enforcements. === ISSUES === Here I list a couple of random issues. I do not consider them critical for decision whether to adopt "Contract" to Boost or not. (6) Static assertions: is there any value in providing them, given that we already have this ability in Boost? I see that N1962 decided to abandon them; I am pretty sure the reason was that static_assert was already there. They somehow do not fit conceptually into the model of preconditions, postconditions and invariants. Precondition, for instance tries to detect a run-time condition occurring immediately before a function is called this time. Static assertion is not even executed then. What point is there in putting such assertion into the precondition? Documentation says " static assertions can be selectively disabled depending on where they are specified [...] so it is still important to logically associate them with preconditions, postconditions, etc." -- technically this sentence makes logical sense, but can you think of a single example where this selective disabling of assertions would be useful? What is the point in disabling such assertions at all, if they cost you nothing in run-time? I propose to remove them and give a sort of recommendation that software quality is assured by using a number of fairly independent tools: DbC, concepts, static assertions. (7) Loop variants: They are definitely a good thing to have (and I started using them immediately I learned about them in your documentation!). But they seem to have little to do with "contracts". A contract is (by definition -- I think) something that involves two parties. For instance, precondition implies two parties: one ensures something, the other expects something. Invariants are harder to explain this way, but to me they are like "automated postconditions" (I explain this later on). However with loop variants the situation is different: they are put inside the the code, so no-one expect function author knows about them. The programmer guarantees something only to himself. It is more like assertion (in the sense of C macro assert()), perhaps with better configuration. I only want to make an observation here that this could be proposed irrespectively of contracts (pre-, post-conditions, invariants and subcontracting) -- but I am not proposing this. (8) Block invariants: Same remark as above: they appear to be separate from contracts. Another question is, what is the difference between block invariant and an assertion (like C-style macro assert())? I know, I know: conditional assertion, requirements, selectively disabling them, customizing run-time behavior... But if this is superior to BOOST_ASSERT, would it be correct to say that with Boost.Contract BOOST_ASSERT is no longer needed (except for backward compatibility)? (9) Class invariants: I have an observation, not about yuor library but the way invariants are handled in DbC methodology. As a "contract" (involving two parties) they make sense when checked after any (public) function call: they are a sort of postcondition that is the same for every function: class implementer "ensures" and class user "expects". But when checked before any function execution they are more like a C-assert: the function "expects", but who is supposed to "ensure"? Only any other public function of that class -- but this is already verified by checking postconditions. Somehow checking invariants before function execution is checking the same thing twice. If you find my reasoning even a bit convincing, perhaps it is worth considering adding another config macro: CONTRACT_CONFIG_NO_CLASS_INVARIANTS_ON_FUNCTION_ENTRY, that would disable invariant checking before function or destructor call, but still check them after function or constructor call? (10) It looks that when I include header <contract/class.hpp>, I also include <boost/concept/requires.hpp> even if I do not intend to use concepts. Would it be possible to avoid this somehow? (An additional header that also allows me to use macros: like CONTRACT_FUNCTION, but does not include <contract/class.hpp>, and if I use keyword "requires" the compilation fails). (11) The library supports almost all of C++03's declaration syntax, but I suppose it may not support some essential declarations from C++11, e.g.: noexcept(condition) or trailing return types. I hope it is doable in the future? (12) In the documentation (Introduction) we read that "This library is implemented for the C++03 <http://en.wikipedia.org/wiki/C%2B%2B> standard and it does not require C++11 <http://en.wikipedia.org/wiki/C%2B%2B11>." I think it is a bit imprecise, because many examples in the docs silently assume that variadic macros, which are not part of C++03, are available. I believe something like this would be more accurate "This library is designed to work on C++03 compilers that support variadic macros; no other C++11 support is necessary. Additionally, if variadic macros are not supported, this library works in >>strict C++03<< mode with slightly different syntax." (13) The documentation says that you can use protected and private members in contracts because "C++ provides programmers ways around access level restrictions (e.g., friend and function pointers)". Next, we read that "only public member functions shall check class invariants. Private and protected member functions are allowed to brake class invariants because private and protected member are part of the class implementation and not of its specification". To me, these two statements appear incompatible: either we say that only public members constitute class'es interface, or even protected and private members constitute class interface, e.g. for befriended functions. And either we both contract-check only public functions and allow only public members in contracts, or we both contract-check all functions and allow all members in contract. I prefer the former. Or am I missing something? If there are some technical obstacles in checking member access in assertions, then I accept such library limitation, but the current argumentation in the docs appears inconsistent. (14) The docs say that in order to make disabling of nested assertions thread-safe in multi-threaded programs, the library needs to use a global lock. Sorry if I am talking nonsense now (I have no intuition of using DbC in multi-threaded apps), but is it not possible to use thread_local storage for this purpose? Is it possible that executing an assertion in one thread would cause the execution of another (nested) assertion in another thread? (15) Unfortunately, I will not have time to check it, so I will only ask you: are any special considerations required in contract-checking classes that inherit virtually (e.g. class hierarchies with diamond inheritance structure). Order of object layout and construction is very particular in those classes, perhaps the order of contract verification and subcontracting should be special a well? (16) Functions like set_precondition_broken() are defined with dynamic exception specification: throw(). Is this necessary? throw() is known to be causing problems, adds little value, and some compilers do not support it; some other issue warnings on dynamic exception specifications; and they are deprecated. (17) According to docs, the framework checks invariants on destructor throw. This is already tracked: https://sourceforge.net/apps/trac/contractpp/ticket/66 (18) "Duplicated globals" problem may cause failure to register custom contract failure handler. This is already tracked: https://sourceforge.net/apps/trac/contractpp/ticket/60 (19) Documentation sometimes uses name "Contract Programming" as though it was a framework. For instance, "This library implements Contract Programming" or "Contract Programing checks them". I think it is incorrect. I understand that "Contract Programming" is a philosophy or a paradigm, whereas what you mean should be called "Contract Programming Framework" or similar. (20) In "Contract Programming Overview" -> "Benefits", in the note we read, "However, the probability that programmers make a mistake twice (in both the body *and* the contract) is lower than the probability that the mistake is made just once (in either the body or the contract)". This implies that we write contracts in order that the code be duplicated because this reduces the probability of the bug. I believe that the mechanism of testing in general is somewhat different (contract-checking is similar to unit testing in this respect, I think): you want the tests to be much simpler then the code they test. Therefore when some test fails you know (although not for sure) that it is the code that is broken rather than the test. For instance: double sqrt(double v) postcondition{ close(return * return = v); }; Testing almost the same thing as function body makes sense because multiplication is conceptually much simpler than the logic to find the square root. Conversely, writing this: bool invert(bool b) postcondition{ b == !return; }; Would be of little practical value, and I believe if there is a chance I will implement such function incorrectly, duplicating the logic in the precondition does not in practice reduce by half the probability of leaving the bug in the code. (21) Contract failure handlers will likely be customized inside function main(). This means that it will be difficult (although not impossible) to customize these actions for contracts of constructors of global objects. This is a very small problem and N1962 also seems to suffer from it and in fact even C++ suffers from it, when it comes to installing terminate handler with set_terminate. (22) Some random type-os in the docs. (apologies that I bluntly paste my notes without editing them, but I am too tired to do it): * " In addition, the library implements" -- don't mention it in the first sentence. * " and increasing overall software quality" -- no meaning * "trailing column symbol :" -> "trailing colon symbol :" * "First, the class invariants and the function preconditions are checked." -> "First, the class invariants are checked, then the function preconditions are checked. "(split it) * "Differences with C++ Syntax" -> "differences from"?<http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp…> * "postconditions and class invariants cannot be weaken. " -> weakened * "This library implement this feature however" -> "This library implements this feature, however" * "A *free function* [8<http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp…> ] call executes the following steps: " -- mention throw * "Preconditions cannot access the object" -- "you shouldn't" or "it is not possible"? * "to ontract" in destructor tutorial === STANDARD REVIEW QUESTIONS === * What is your evaluation of the design? * What is your evaluation of the implementation? Unfortunately, the macro tricks are beyond my mental powers, so I am unable to evaluate the design and implementation. I could only try to break it or test if it behaves as documented on examples. I can see that the framework is customizable (broken contract handlers, disabling the compilation of handlers). One design flaw I can see is that it is a header-only library while it requires some globals to store the handlers. But this is already recorded as a confirmed bug: http://sourceforge.net/apps/trac/contractpp/ticket/60 * What is your evaluation of the documentation? Very, very good: easy intro for the beginners, very detailed, describes not only the library but also the problem domain, lots of examples. * What is your evaluation of the potential usefulness of the library? It may be disqualified from production code by many parties due to the unusual syntax. But it is definitely useful for learning DbC, experiments, personal projects (where you need not convince others to use the interface they do not like) * 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? I played with the library for three evenings, running basic tests and trying to break it. I read the documentation. I also had some conversations with Lorenzo as he was developing the library, and reviewed previous versions of the docs. I am using VisualStudio 2010. * Are you knowledgeable about the problem domain? I know Contract Programming from Meyer's book and ISO C++ proposals (N1613, N1669, N1773, N1866, N1962) and Lorenzo's documentation. I haven't used it in practice on a dig scale. === FINALLY === The work Lorenzo did for this library is incredible. He already contributed to the knowledge of the limits and the power of the preprocessor. Supporting contracts in C++ without language extensions appeared (at least to me) impossible. It is a great piece of work. Regards, &rzej

3 9

[Review] Boost.Contract Review Period Extended
by Dave Abrahams 06 Sep '12

06 Sep '12

We've had lots of good discussion, and gotten three votes so far, but for a library of this scope I would like to see more. Therefore, we're extending the review period through Sept 7th. Please take the time to look at it, and *please vote for or against acceptance*. As noted below, everyone who looks at the library is qualified to vote, and every vote is valuable. Thanks, Dave ,----[ Important Notes ] | - Please post your review to the Boost Developers' list | (http://lists.boost.org/mailman/listinfo.cgi/boost) | - Please begin your review's subject line with "[Review:Contract]" | - Please do not post your review or discussion as a reply to this | message. | - Please feel free to note any individual issues in the issue | tracker at https://sourceforge.net/apps/trac/contractpp/report/3 | (you'll need to log in at Sourceforge to add a ticket) and make | reference to them from your review. | - Please see below for *further* important notes `---- THE LIBRARY Boost.Contract implements Contract Programming (a.k.a., Design by Contracts) for C++. In addition, the library implements virtual specifiers, concept checking, and named parameters. Documentation: http://contractpp.sourceforge.net Source: http://sourceforge.net/projects/contractpp/files/latest/download All N1962 requirements and Eiffel features are supported by the library, among others: 1) Support for preconditions, postconditions, class invariants, block invariants, and loop variants. 2) Subcontract derived classes (with support for pure virtual functions and multiple inheritance). 3) Access expression old values and function return value in postconditions. 4) Optional compilation and checking of preconditions, postconditions, class invariants, block invariants, and loop variants. 5) Customizable actions on contract assertion failure (terminate by default but it can throw, exit, etc). This library is implemented for C++03 and it does not require C++11. Obviously, if the library is accepted, all macros will be prefixed by BOOST_... and other symbols will go under the boost::... namespace. Potential Interactions with Existing Boost Libraries ==================================================== This submission potentially interacts with the following existing Boost libraries: * parameter - http://boost.org/libs/parameter * static_assert - http://www.boost.org/libs/static_assert * MPL - http://www.boost.org/libs/mpl * Concept - http://www.boost.org/libs/concept_check Reviewers should consider these potential interactions. What to include in Review Comments ================================== - Keep your criticism constructive. Constructive criticism usually comes with specific suggestions for improvement. - If you identify problems along the way, please note if they are minor, serious, or showstoppers. - Please *do* vote on whether the library should be accepted. Everyone who takes the time to look at the library is qualified to vote, and every vote is valuable. - Other 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? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

3 4

[asio]New feature: timeout for poll()
by Max Che 06 Sep '12

06 Sep '12

Hello. I want to use win_iocp_io_service::poll() with timeout. poll() + timeout = poll() functional and free waitable timer! GetQueuedCompletionStatus() (and epoll(), kqueue()) allows to use that. Somebody can add this feature?

1 0

[rational] Over/underflow checked update ready for comments
by Dan Searles 06 Sep '12

06 Sep '12

>> For those interested in the rational number class, see: >> https://svn.boost.org/svn/boost/sandbox/rational >> >> Requesting comments on the code, and review for >> inclusion in the next release. >> >> > >Hi, > >the enum type could follow the one defined in >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html >"When an overflow does occur, the desirable behavior depends on the >application, so programmers may specify the overflow mode with a value >of type |enum class overflow|. The possible values are: > >|impossible| > Programmer analysis of the program has determined that overflow > cannot occur. Uses of this mode should be accompanied by an argument > supporting the conclusion. >|undefined| > Programmers are willing to accept undefined behavior in the event of > an overflow. >|modulus| > The assigned value is the dynamic value mod the range of the > variable. This mode makes sense only with unsigned numbers. It is > useful for angular measures. >|saturate| > If the dynamic value exceeds the range of the variable, assign the > nearest representable value. >|exception| > If the dynamic value exceeds the range of the variable, throw an > exception of type |std::overflow_error|. 'impossible' and 'undefined' are effectively the same thing, and equivalent to the 'no check' currently implemented. 'modulus' makes more sense for the fixed point class that it's being described for than rational numbers. I'm not sure a useful definition can even be made for rationals. 'Saturate' sounds like it might be useful, but gets problematic quickly when there is under/overflow within the largest/smallest range limits. The point is that if a result of a calculation is not exactly representable, you will get an exception to notify you. And of course 'exception' is in the new implementation for just that purpose. > >BTW, I have no access to the link for the examples and the test. I have not changed those files. The existing examples and test are still valid for the original non-checked case. For the checked case, I have tests which run for hours. The tests for rational instantiated with signed char is exhaustive (there are only so many normalized values. Pairing up each value with every other value on the binary operators doesn't result in much more that 2**32 combinations). For short/int/long long, sets of interesting values are created, and each value is paired up with every other value in the set. I can provide the test drivers if anyone is interested. > >Could you update the History section? The history section is missing about 6 earlier updates. It also has the problem that it's written in the 1st person by the original author. It might be best to leave that section alone, and just update the main doc body and the revision history of the header file (already done). > >In order to avoid breaking the existing interface, you could define a >class basic_rational that has the new template and define the current >rational using this basic_rational. > >template <typename Integer, overflow Ov> class basic_rational; > >template <typename Integer> class rational : >basic_rational<Integer,overflow::undefined> {...} The new implementation doesn't break the existing interface of the original rational class/header. > >Best, >Vicente Thanks > >P.S A link to a standard proposal >* http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3363.html. There are some interesting things in there to consider... My current goal, however, is to add over/underflow checking to the original implementation, rather than add new capabilities beyond that. Comments?

2 1

[coroutine] new location
by Oliver Kowalke 05 Sep '12

05 Sep '12

Hi, because some of the community members have had some problems to access the archive I've uploaded the library to a new location. docu: http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/ src: http://ok73.ok.funpic.de/boost.coroutine.zip I'd like to remember that the review starts at September 3, 2012. The library contains one example using boost.asio together with a stream reading from a socket (without blocking the application if newline was not received). regards, Oliver

7 15