- Boost - lists.preview.boost.org

[date_time] merge from trunk to release
by Vicente J. Botet Escriba 19 Sep '12

19 Sep '12

Hi, I have tried to merge (https://svn.boost.org/trac/boost/changeset/80051) Boost.DateTime from trunk to release to merge and I suspect that the svn merge tools has not been used since a long time. I'm getting a long diff with a lot of mergeinfo. Property changes on: boost/date_time/gregorian_calendar.ipp ___________________________________________________________________ Deleted: svn:mergeinfo Reverse-merged /trunk/boost/date_time/gregorian_calendar.ipp:r38329-41356,41778,41955,41983,42067,42076,42080,42141,42424,42988-42990,43112-43113,43209-43210,43799,44807,44825,44897,45097-45098,45264,45283,46445,46508,46544,46580,46632,46673-46674,46790,46801,46803-46804,46808,46819-46820,46826-46829,46832,46936,47024-47027,47058,47064,47086,47093,47254,47283,47301,47389,47392,47401,47456,47754,47768,47793-47794,47797,47938,47940,47942,47985-47987,47993,48089,48204,48226,48252,48280,48478,48496,48663,48695,48729-48730,48973,49111,49118,49121-49122,49131,49254,49333,49345-49346,49424,49433,49510,49586,49601,49620,49627-49628,49691,49693,49945,49970-49971,49980,49996-49998,50019-50020,50024-50027,50059,50237,50240,50244,50312,50413,50447,50486,50497,50516,50997,50999,51031,51045,51066,51104,51120,51171,51189,51210,51239,51253,51284,51311,51337,51400,51410,51413,51422,51448-51449,51862,51881,51909,51912,51961,52231,52258,52425,52773,52866,52879-52881,52937,53048,53050,53061-53062,53125,53141,53143,53187,53211-53212,53218-53219,53233,53261,53293,53343,53425,53462,53476,53478,53544,53577,53619,53648-53649,53651,53671-53672,53682,53699,53751,53780,53790,53800,53802,53888,54385,54594,54873,54914,55097-55100,55132,55138,55140,55146,55151,55159,55184-55185,55224,55370,55470,55473,55484,55500,55507,55528,55573,55656,55667-55670,55698,55718,55723,55728-55729,55749,55780,55838,55877-55902,55905-55917,55921-55922,55990-55992,56009-56010,56014-56017,56020,56028,56077,56089,56097,56116-56117,56125-56128,56140,56147,56202,56207,56300-56302,56319,56321,56328-56329,56339,56346-56349,56360,56362-56363,56374,56440-56441,56454,56461,56468,56473,56557-56563,56570-56571,56603,56633,56651,56654,56658,56682,56697-56699,56715,56717-56719,56732,56796-56797,56855-56856,56859-56860,56868,56922,56942,56988-56989,57005-57006,57008,57126,57139,57150-57153,57159,57170,57174,57177,57196,57249,57290,57346-57348,57388-57389,57393,57395,57412,57433,57479,57520,57525-57526,57542,57544,57559-57560,57580,57592-57593,57601,57613,57618,57631,57645-57646,57663,57665,57670-57672,57694-57695,57703-57704,57706,57708,57710,57717-57718,57721,57724,57726,57730,57732,57734-57738,57748,57751,57757-57759,57782,57790,57826,57828,57830,57859,57863,57865,57869-57871,57875-57877,57892,57894-57896,57898,57901-57907,57909-57911,57913-57914,57923,57928-57930,57933-57934,57939,57944,57949,57951,57953-57955,57957-57958,57973-57974,57986,58005,58034-58035,58037-58039,58041-58043,58047-58049,58057,58061,58071,58073-58074,58082-58083,58086-58087,58090-58091,58093-58094,58105-58109,58114,58117-58118,58120-58121,58123-58125,58127-58129,58145-58146,58148,58171-58172,58179-58181,58183,58196,58219,58246,58270,58272,58275,58279,58295,58297-58298,58306,58310,58323,58333,58356,58375,58378-58379,58392,58400-58401,58407-58408,58412-58415,58427,58437-58439,58444,58452-58453,58467,58469,58491-58492,58501,58520,58531,58533,58555,58563-58565,58570,58574,58576,58588-58589,58598,58602,58611,58621-58630,58634-58636,58647-58652,58670-58671,58694-58695,58698-58699,58703-58708,58713-58721,58740,58761-58762,58768-58770,58772,58779,58782-58783,58793,58796-58799,58824,58850-58851,58859,58865,58870-58871,58876,58887,58900,58914-58920,58942-58943,58965-58966,58971,58994-58995,59005,59062-59063,59103-59106,59129-59134,59141-59142,59156,59163-59168,59241-59242,59244-59248,59256-59257,59277,59341-59344,59347-59361,59374-59376,59390,59407,59413,59416-59417,59420-59424,59440-59441,59486-59491,59496,59519-59522,59537-59538,59540-59543,59574,59583-59584,59618,59628,59662,59667,59713-59726,59729,59734,59742,59748,59761,59795,59854,59910,59928-59935,59937,59946,60078-60079,60126-60127,60141-60143,60152-60155,60164,60172,60178,60180-60181,60184-60185,60190-60192,60195-60199,60201,60210,60216-60218,60220,60225-60227,60256-60260,60279-60280,60282-60283,60295-60296,60313,60315,60335-60336,60339-60340,60343-60357,60359,60365-60366,60373,60380,60384-60385,60391,60395,60403,60451-60453,60455,60470-60472,60479,60485,60494-60496,60503,60526-60527,60608,60610-60611,60615,60619-60620,60624,60633,60639,60645-60646,60651,60657,60659,60669-60671,60681-60683,60685,60687,60689,60692,60705-60707,60717-60725,60738,60740,60743-60746,60750,60752,60756,60767,60769-60770,60775,60781,60788,60817-60820,60828-60829,60849-60850,60859-60861,60869,60874,60882-60885,60888,60899-60900,60916-60923,60925,60938-60941,60958,60961-60962,60995-61000,61002,61009-61010,61012-61013,61015-61016,61055-61064,61074,61076,61085,61100-61101,61104,61117,61122-61124,61127-61128,61131,61151-61152,61155-61156,61159,61165,61171-61172,61174,61179,61182-61183,61185,61190-61192,61194,61212-61214,61217-61225,61230-61232,61234-61240,61244-61251,61254,61257,61262-61266,61273-61276,61282-61287,61290-61292,61294-61299,61302-61303,61307-61308,61310-61312,61315-61326,61328,61330-61331,61333-61336,61338-61340,61342-61344,61347-61348,61350-61357,61360,61367-61369,61371-61373,61381,61384,61388-61392,61398,61405,61416,61421-61422,61424-61426,61435,61437,61445-61451,61460,61462,61465-61468,61471,61475-61481,61483,61489,61491-61492,61499-61503,61506,61510,61514-61515,61520-61521,61523-61525,61543,61547-61549,61551,61553,61564-61569,61573-61582,61606,61643,61645,61649,61668-61669,61674-61677,61679,61696-61699,61708,61717,61723,61726-61728,61748,61750,61764,61766,61769,61782-61783,61788,61795-61796,61824,61832,61838,61841,61843-61844,61856,61858-61859,61876,61881,61918-61919,61925,61928,62042,62046,62051,62074,62080-62081,62084,62098-62099,62116,62139,62142-62148,62150-62152,62165-62166,62176,62182-62184,62245-62246,62248,62251,62255,62259,62271,62368,62371-62373,62394,62404-62406,62426,62479,62497-62499,62506,62530-62533,62535,62545,62547-62550,62556-62558,62579,62592-62593,62595,62605-62607,62609,62611,62616-62620,62622,62626-62630,62660-62661,62671,62678,62683-62684,62686,62693,62698,62725-62727,62736,62753-62754,62781,62798,62811,62825,62827,62829,62897-62898,62909,62926-62927,62932-62935,62937,62951-62952,62957,62960-62966,62972,62984,62994,62998-63000,63002,63004,63006,63012,63016,63020-63021,63023-63024,63031,63033-63039,63048-63049,63057,63084,63086-63088,63091-63094,63097-63098,63101,63125-63128,63137-63147,63149-63155,63180,63188-63204,63217,63221-63225,63227,63234,63240-63241,63244,63247,63260-63261,63268-63270,63274,63276-63280,6328: and much more. Even if the modifications to merge were simple, the diff file is more that 200K lines. I have made a diff between the trunk and the release and the single differences are due to a $Date tag that includes the commit date. Hrrr. Could this merge be done? I could do it if permission is granted from the author or the release manager team. Best, Vicente

3 5

How to bind program termination with end-of-stream in Boost.Process 0.5?
by alfC 18 Sep '12

18 Sep '12

Hi, I have a simple question about the latest Boost.Process 0.5 library. Namely how to How to bind program termination with end-of-stream in Boost.Process 0.5? For example, in this example http://www.highscore.de/boost/process0.5/boost_process/tutorial.html#boost_… One can make a look to read the output of the process until the program finishes, but the stream is not invalid after program termination. ... while(std::getline(is, s)){ // is is an stream associated with a process (e.g. '/usr/bin/ls') std::cout << "read: " << s << std::endl; } std::clog << "end" << std::endl; // never reach ... I originally posted the question in http://stackoverflow.com/questions/12329065/how-to-bind-program-termination… but now I think it can be overlooked there. Since now there seems to be extra layers (Boost.Streams) it may be that I don't know how to set up the file_descriptor_source, etc. BTW, the solution to this question can be used to improve the example code in http://www.highscore.de/boost/process0.5/boost_process/tutorial.html Thanks, Alfredo -- View this message in context: http://boost.2283326.n4.nabble.com/How-to-bind-program-termination-with-end… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 10

VS2012 and bootstrap
by Pedro Larroy 18 Sep '12

18 Sep '12

Hi I'm trying to compile boost with VS2012 in the exact same way that it succeeds with VS2010. And get an error w32_getreg.c: fatal error C1083: Cannot open include file: 'windows.h' Anyone knows how to solve this? Thanks. Pedro.

1 0

[ANN] ODB C++ ORM 2.1.0 released, adds support for Uuid, Multi-Index
by Boris Kolpackov 18 Sep '12

18 Sep '12

Hi, I am pleased to announce the release of ODB 2.1.0. ODB is an open source object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. Major new features in this release: * Ability to use accessor/modifier functions and expressions to access data members. In most cases ODB is capable of discovering suitable accessor/modifier functions automatically. * Support for virtual (imaginary) data members that can be used to handle the C++ pimpl idiom as well as aggregate or dis-aggregate real data members. * Ability to define database indexes on data members. Multi-member indexes as well as indexes with database-specific index types, methods, and options are supported. * Support for mapping extended database types, such as geospatial types, user-defined types, collections (arrays, table types, etc.), key-value stores, XML, JSON, etc., to suitable C++ types. * The Boost profile library now provides persistence support for the Uuid and Multi-Index container libraries. * The Qt profile library now provides persistence support for the QUuid type. * Support for generating single (combined) database schema file from multiple C++ header files. This release also adds support for Visual Studio 2012 and Clang 3.1. Specifically, all the runtime libraries, examples, and tests now come with project/solution files for Visual Studio 2012 in addition to 2010 and 2008. A more detailed discussion of these features can be found in the following blog post: http://www.codesynthesis.com/~boris/blog/2012/09/18/odb-2-1-0-released/ For the complete list of new features in this version see the official release announcement: http://www.codesynthesis.com/pipermail/odb-announcements/2012/000018.html ODB is written in portable C++ and you should be able to use it with any modern C++ compiler. In particular, we have tested this release on GNU/Linux (x86/x86-64), Windows (x86/x86-64), Mac OS X, and Solaris (x86/x86-64/SPARC) with GNU g++ 4.2.x-4.7.x, MS Visual C++ 2008, 2010, and 2012, Sun Studio 12, and Clang 3.1. The currently supported database systems are MySQL, SQLite, PostgreSQL, Oracle, and SQL Server. ODB also provides profiles for Boost and Qt, which allow you to seamlessly use value types, containers, and smart pointers from these libraries in your persistent classes. More information, documentation, source code, and pre-compiled binaries are available from: http://www.codesynthesis.com/products/odb/ Enjoy, Boris

1 0

[contract] static_assert in contracts or not?
by Lorenzo Caminiti 18 Sep '12

18 Sep '12

Hello all, If static assertions make sense within contracts (preconditions, postconditions, and class invariants) is a questions that has been raised by both Vicente and Andrzej. I don't have a definitive answer so I'd like to discuss with the ML. On Wed, Aug 29, 2012 at 2:48 PM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > (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. I think we can break down the question in two parts. Let's assume N1962 is accepted into C++1x so we have both contracts and static_assert. 1) Would you expect to be able to use static_assert within contract assertions (preconditions, postconditions, and class invariants)? Note that only boolean conditions are allowed by N1962 within contracts, general code is not allowed, therefore this is not a trivial question. For example, would you expect to be able to do the following option A: template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); to; // pointer not null from; // pointer not null } { // ... } In this case, would it ever make sense to use static_assert in postcondition and/or class invariants even if that were allowed? Or would you just use static_assert in the body, option B: template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ to; // pointer not null from; // pointer not null } { static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); // ... } I don't like this because the assertions are about the specifications (they assert a requirement of the interface) so they should go in the declaration and not in the implementation. Or maybe the assertions should be represented as concept requirements on To and From, option C: template< typename To, typename From > requires SizeofGreaterEqual<To, From>, Convertible<From, To> To* memcopy ( To* to, From* from ) precondition{ to; // pointer not null from; // pointer not null } { // ... } (Only we don't have concepts...) 2) Let's assume, we answered option A to question 1): template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); to; // pointer not null from; // pointer not null } { // ... } Would you expect these static_asserts to be disabled when precondition compilation and checking is turned off at compilation time? I'd think so. Thanks. --Lorenzo

4 11

[contract] future directions
by Lorenzo Caminiti 18 Sep '12

18 Sep '12

Hello all, Now that Boost.Contract has been accepted :D, I couldn't help but to share where I see the library going next :) First of all, I'll have to put Boost.Contract in one of the upcoming Boost releases and I know that will be a lot of work! After that however, I see the library pursuing the following future directions: 1) Reduce compilation times (both preprocessor and template meta-programming optimizations) and possibly improve the (preprocessor) syntax error messages. IMO the x30 compilation time is the largest barrier for the lib adoption in production code, much more so than the strange syntax. I think the 2nd largest barrier is the cryptic syntax errors. The rationale is that you can learn a new syntax especially if that's the only way to program C++ contracts (assuming you actually need contracts) but if your projects takes 1 months instead of 1 day to compile and/or if the compiler errors don't help you understand what you did wrong, you will find it very hard to use the lib in large projects. 2) Support concepts similarly to Boost.Generic (N2081) and/or N3351. This will probably be for C++11 only but many of us wish concepts were part of C++11 and I think many people will favor a lib that supports them (e.g., many people were interested in Boost.Generic). 3) Refactor the macro parsing code so the syntax can be extended by the user. Ideally, this will result in something like Boost.Proto for the preprocessor, maybe "Boost.PreprocessorProto" (even if the actual API might be different and not necessarily equivalent to Boost.Proto API because dealing with macro expansions instead of the template expressions). I don't know if any of the above can actually be achieved but if I'll have time after the 1st Boost.Contract release I'll start working on these projects in the listed order of priority. Thanks. --Lorenzo

1 0

[graph] "get" bundled properties removed?
by Fabien Castan 17 Sep '12

17 Sep '12

Hi, The "get" function for bundled properties has been removed in the 1.51 release of boost and I don't know what is the new way to do this. This code doesn't compile anymore: > boost::write_graphviz( os, g.getGraph(), > make_simple_node_writer( get( &Vertex::_name, g.getGraph() ) ), > make_simple_node_writer( get( &ProcessEdge::_name, g.getGraph() ) ) ); https://github.com/tuttleofx/TuttleOFX/blob/master/libraries/tuttle/src/tut… The following code has been completely removed from "boost/graph/adjacency_list.hpp": " // Support for bundled properties #ifndef BOOST_GRAPH_NO_BUNDLED_PROPERTIES template<typename OutEdgeListS, typename VertexListS, typename DirectedS, typename VertexProperty, typename EdgeProperty, typename GraphProperty, typename EdgeListS, typename T, typename Bundle> inline typename property_map<adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, T Bundle::*>::type get(T Bundle::* p, adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>& g) { typedef typename property_map<adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, T Bundle::*>::type result_type; return result_type(&g, p); } template<typename OutEdgeListS, typename VertexListS, typename DirectedS, typename VertexProperty, typename EdgeProperty, typename GraphProperty, typename EdgeListS, typename T, typename Bundle> inline typename property_map<adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, T Bundle::*>::const_type get(T Bundle::* p, adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS> const & g) { typedef typename property_map<adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, T Bundle::*>::const_type result_type; return result_type(&g, p); } template<typename OutEdgeListS, typename VertexListS, typename DirectedS, typename VertexProperty, typename EdgeProperty, typename GraphProperty, typename EdgeListS, typename T, typename Bundle, typename Key> inline T get(T Bundle::* p, adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS> const & g, const Key& key) { return get(get(p, g), key); } template<typename OutEdgeListS, typename VertexListS, typename DirectedS, typename VertexProperty, typename EdgeProperty, typename GraphProperty, typename EdgeListS, typename T, typename Bundle, typename Key> inline void put(T Bundle::* p, adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>& g, const Key& key, const T& value) { put(get(p, g), key, value); } #endif " What is the replacement to this "get" accessor? Regards, Fabien

2 4

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

[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

[ublas] Trunk testing broken
by Belcourt, Kenneth 15 Sep '12

15 Sep '12

Someone forgot to commit a file? error: Unable to find file or target named error: 'test_ticket7296.cpp' error: referred to from project at error: '../libs/numeric/ublas/test'

2 1

[nowide] Library looks for a review manager
by Artyom Beilis 15 Sep '12

15 Sep '12

Hello, The project Boost.Nowide searches a review manager: What is Boost.Nowide: --------------------- Boost.Nowide is a library implemented by Artyom Beilis that make cross platform Unicode aware programming easier. The library provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. Documentation: http://cppcms.com/files/nowide/html/ Downloads: http://cppcms.com/files/nowide/ Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

3 7

[system] Patches to apply when BOOST_ERROR_CODE_HEADER_ONLY or BOOST_NO_EXCEPTIONS are defined
by Vicente J. Botet Escriba 15 Sep '12

15 Sep '12

Hi, I have added some simple patches for these two tickets https://svn.boost.org/trac/boost/ticket/7347:duplicate symbol while BOOST_ERROR_CODE_HEADER_ONLY is defined https://svn.boost.org/trac/boost/ticket/7149:system failed to compile with BOOST_NO_EXCEPTIONS defined when -fno-exceptions is NOT used Could I apply them to trunk? Best, Vicente

1 0

[system] Patches to apply when BOOST_ERROR_CODE_HEADER_ONLY or BOOST_NO_EXCEPTIONS are defined
by Vicente J. Botet Escriba 15 Sep '12

15 Sep '12

Hi, I have added some simple patches for these two tickets https://svn.boost.org/trac/boost/ticket/7347:duplicate symbol while BOOST_ERROR_CODE_HEADER_ONLY is defined https://svn.boost.org/trac/boost/ticket/7149:system failed to compile with BOOST_NO_EXCEPTIONS defined when -fno-exceptions is NOT used Could I apply them to trunk? Best, Vicente

1 0

[Review:Contract] Very late review
by John Bytheway 15 Sep '12

15 Sep '12

I was out of touch for most of the review period, but I wanted to submit a review of Contract anyway. The review manager is of course welcome to ignore my comments or otherwise give them short shrift as he sees fit as a consequence of this delay, but I hope Lorenzo will welcome more feedback :). Firstly, I would like to add my voice to those who are congratulating Lorenzo on the quite remarkable feat this library represents. It has obviously required extensive and careful thought and effort to reach this state. It is primarily because of this evident conscientiousness that I will vote YES, I think the library should be accepted into Boost. I concur with previous reviewers that it is unlikely to suit industrial use, but it is an important experiment, and one which will benefit from the additional exposure granted by inclusion in Boost. My review follows. Problems using the library ========================== I only experimented very briefly, but found one problem (which may well be a clang bug, but you should probably investigate). The following program I tried works with gcc-4.7.1 but not with clang r163674 (both in C++11 mode): #include <contract.hpp> CONTRACT_FUNCTION( int (postinc) ( (int&) value ) precondition( value < std::numeric_limits<int>::max() ) ) { return value++; } int main() { int i = std::numeric_limits<int>::max(); postinc(i); return 0; } The first few errors with clang all look like: In file included from contract-failure-test.cpp:1: In file included from .../contractpp_0_4_1/include/contract.hpp:14: .../contractpp_0_4_1/include/contract/broken.hpp:359:7: error: call to object of type 'thread_variable<broken_contract_handler>' is ambiguous { aux::broken_handlers<>::precondition(context); } ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .../contractpp_0_4_1/include/contract/aux_/thread_variable.hpp:42:5: note: conversion candidate of type 'void (*)(const contract::from &)' operator T() const { // Sync so must return object copy (by value). ^ .../contractpp_0_4_1/include/contract/aux_/thread_variable.hpp:49:5: note: conversion candidate of type 'void (*)(const contract::from &)' operator T() const volatile { // Sync so must return object copy (by value). ^ Minor issues in the docs ======================== (I'm not mentioning issues already raised in another review) Tutorial -------- - I think it's slightly unfortunate that your example function name ("postinc") shares a four-character prefix with "postcondition". This threw me a couple of times when I was reading too fast. - "specify both its type and its name (parameter names can instead by omitted in usual C++ declarations)" -- I found this phrasing confusing. I think you were planning to remove this constraint anyway so it doesn't matter, but FWIW I would recommend something like "specify both its type and its name (unlike conventional C++ declarations, where parameter names may by omitted)". - "and assigning it to the return keyword" -- also confusing. Perhaps "and assigning to it from the return keyword" - "destructors cannot specify neither preconditions nor postconditions" -- double negative; should be "destructors can specify neither preconditions nor postconditions" - The whole "Forward Declarations and Body Definitions" section is a bit odd. The code example doesn't seem to match up with the text. For example, you say "less and natural::get are defined together with their declarations", but in fact less is forward-declared at the top of the file with no definition. Advanced topics --------------- - "the postcondition result = n * factorial(n - 1) has factorial computation complexity" -- this is not true; the factorial function as defined here has linear complexity, not factorial complexity. (If it were using arbitrary precision integers it would be something like O(n^2 log(n)^2) but still certainly polynomial, not super-exponential!) - "preconditions cannot only be weakened" -- again s/cannot/can/ Named parameters ---------------- - By using "requires" here in the pseudocode example with a different meaning from the rest of the library you are further muddying the waters. If you change the "requires" keyword that is used by the library to something else (as discussed below) then this will no longer be a problem. - In footnote 61 (Boost.Parameter bug) could you please link to the bug so that future readers will know when it is fixed. Doxygen ------- You've mentioned a few times the the Doxygen preprocessor can't cope with your preprocessor metaprogramming. Have you submitted bugs to Doxygen? Do you know how receptive they are to improving their preprocessor conformance? This library might be a compelling incentive for them to do so. Design issues ============= The vast majority of the design is clearly well-grounded in existing practice and practicality. Nevertheless, I have a few issues to raise. Concepts -------- I agree with the earlier thread that you should not use the term "requires" in the way you currently are, because it has a different meaning in the Concepts proposal. Alternatives as discussed there such as "check" would be an improvement. Contract broken message ----------------------- The above example program generates the following broken contract report: precondition number 1 "value < std::numeric_limits<int>::max()" failed: file "contract-failure-test.cpp", line 8 I would like my editor (Vim, though this comment applies equally to others) to automatically take me to the line where the failure occurred. I could of course configure it appropriately, but it might make your users lives easier if you used a standard error format which editors will recognize by default, such as: contract-failure-test.cpp:8:precondition number 1 "value < std::numeric_limits<int>::max()" failed Furthermore, I suspect that it is quite likely that these contract broken messages might occur at odd times, such as when the program is in the midst of printing something else to stdout/stderr, so it might be a good idea to prefix all your messages with a newline. Best of all, perhaps, would be to provide a customization point for the message format (which doesn't entail changing all five broken handlers). This would allow me to make these changes to the messages without disturbing other users. Contract broken handlers ------------------------ Based on your example, I presume that if I install a custom handler for broken contracts, and that handler returns without throwing, then execution will simply continue merrily without regard to the detected contract violation. I can see why you might feel the need to provide such functionality ... but my first instinct is that if a custom handler returns the library should take over and call std::terminate anyway (this is similar to the way that a constructor function-try block will not allow you to swallow an exception thrown by a base or member constructor). But I don't feel strongly about this. At the least, you should document this turn of events more clearly; I only figured it out from the very last footnote in advanced topics. Configuration macros -------------------- This is my biggest concern with the library at present. You provide the various macros for configuration (CONTRACT_CONFIG_NO_PRECONDITIONS etc. as in <contract/config.hpp>). However, they are all essentially global constants. Suppose I am writing an application that depends on a library, and they both use contracts in their declarations. I would like to have only preconditions active for the library, but all contracts checked for the application. There is no way to achieve this. CONTRACT_CONFIG_DO_NOT_SUBCONTRACT_PRECONDITIONS causes a similar but different problem. If the library subcontracts preconditions then I can't disable them for my application. I think you need to provide a means to turn the various features on and off on a per-project basis. As one suggestion, suppose that you took extra arguments to your macros, so that the above example became: CONTRACT_FUNCTION( MYAPP_NO_PRECONDITIONS, MYAPP_NO_POSTCONDITIONS, int (postinc) ( (int&) value ) precondition( value < std::numeric_limits<int>::max() ) ) { return value++; } and then I define a wrapper macro for my app which substitutes these arguments for me, and therefore the example becomes: MYAPP_CONTRACT_FUNCTION( int (postinc) ( (int&) value ) precondition( value < std::numeric_limits<int>::max() ) ) { return value++; } Or perhaps rather than many variables it would be better to have a single MYAPP_CONTRACT_CONFIG value which contained all of them (as a preprocessor tuple, say) which was passed in similarly. Anyway, I'm sure you can think of something appropriate. Philosophical issues ==================== Finally, I'd like to go off on a bit of a tangent and talk about a philosophical problem with the design. It has been touched on by other reviewers but I'd like to go into more detail. Your library design is very syntactically invasive. As the docs indicate, this makes it unfamiliar, slow to compile, and potentially difficult to debug. But none of these is the worst problem. To worst problem is that only one library can do this. You've already seen this, and done your best to integrate the other Boost libraries that have similar requirements (Parameter and Concept) but this approach doesn't scale. I'm sure at least one of the many reflection libraries proposed to Boost does something similar. Will you integrate that too? What about non-Boost libraries. The only scalable solution is to write a framework for customized definitions. You've mentioned the possibility of using the knowledge your alternate syntax has to expose extra data (e.g. function access level) at preprocessor time. But that's not enough. It would have to allow other library authors to inject code into definitions in the way Contract or Parameter needs to; even provide whole new definition syntaxes as Property does. Given such a framework, each other library (Contract, Parameter, a reflection library, and whatever else) would be written using the framework. It should then be possible to use whichever a user desires, at the same time, for the same declaration, without those libraries having any knowledge of each other. Such a framework would be akin to the language customization features that some other languages have (and which have also been mentioned in other threads of this review). To be clear, I am certainly not demanding, nor even proposing, that you implement such a framework. I think it would be extremely difficult -- more trouble than it's worth. It would also be very dangerous (for all the same reasons that it is dangerous to be able to customize the language on the fly). So long as Contract remains a primarily experimental library the current design is perfectly adequate. I just think that this direction is the logical conclusion of your efforts, and wanted to bring it to your attention (though you've probably already had similar thoughts). Standard review questions ========================= * What is your evaluation of the design? Barring issues mentioned above, it is an excellent attempt to solve a very difficult problem. * What is your evaluation of the implementation? I did not examine it. * What is your evaluation of the documentation? I did not read the reference; the rest was very good, with minor nits as above. * What is your evaluation of the potential usefulness of the library? It has significant potential for use in small projects, to spread the idea of contract programming, serve as a proof of concept and influence future standardisation efforts. It is unlikely to see use in large scale industrial programming. * Did you try to use the library? With what compiler? Did you have any problems? Very briefly, with compilers and problems mentioned above. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent three evenings reading the docs and writing my review, and have been following the development of the library on the list since its first appearance. I would have liked to do more experiments, but my review was already late enough! * Are you knowledgeable about the problem domain? Not to any notable degree. Congratulations again to Lorenzo on achieving something I would have thought impossible; with luck it might inspire me to actually try contract programming. John Bytheway

2 1