- Boost - lists.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