- Boost - lists.boost.org

Re: [boost] [contract] Contract Programming Library
by Andrzej Krzemienski 19 Feb '10

19 Feb '10

> I am thinking to submit a library for Contract Programming (a.k.a. > Design By Contract (TM) ) for C++. > I have drafted some of the library documentation in Boost-like format: > http://dbcpp.sourceforge.net/boost/libs/contract/doc/html/ > Comments? Hi, I have a couple of questions/suggestions regarding the documentation of the library. (1) Does it execute postconditions when the function body ends with a thrown exception? Obviously it shouldn't. I can see one lie saying It is possible to describe the function postconditions. These are logical conditions that programmers expect to be true when the function has ended **normally**. So I guess it doesn't, but I believe this fact deserves some more room in the documentation, like "public member function is not required to satisfy the postcondition if it ends with exception." (2) Obviously, the expressions in assertions shouldn't change the behaviour of the program when executed. This requirement is stronger than having no side effects. You protect the object itself by allowing only const member functions. Are the function arguments (those passed by mutable reference also protected?). Is it allowed/recommended to refer to global or static data in the assertions? If you are using clever macros, perhaps there is a way to block the references to these. In C++0x lambdas you can specify a list of objects you want to refer to: [this, &max_value, &count, &cache]( int fact1, int fact2 ) {...} perhaps there is a way to do it with current C++ macros. (3) In a similar manner, what happens if one of postcondition's assertions throws an exception? I have troubles answering this question myself (I do not know what should ideally happen), but whatever your answer is, I believe it should be clearly documented. (Note that this is not only the issue of DbC; simple C-assertions also leave this question unanswered). (4) Do the assertions have access to objet's private/protected interfaces? (I believe they shouldn't). (5) Does the library allow defining preand postconditions for "free" functions or static member functions? The examples are so focused on objects/classes that I cannot tell the answer. (6) Similarly, does the library allow defining block invariants? (7) The documentation lists the following sequence for executing a constructor: 1. Initialize member variables via the constructor member initialization list (if such a list is specified). 2. Check preconditions (but not invariants). 3. Execute constructor body. 4. Check invariants. 5. Check postconditions. I believe, one of the reasons for validating arguments of a constuctor is to not allow the incorrect values to initialize objest's sub-objects (members). I believe the sequence of the first two items should be inverse. Am I wrong? (8) Since library usses macros that make the syntax a bit difficult to read/parse, perhaps it would be useful to augment every example with another one that would say how the same thing would be acomplished with fictitious "DbC C++" syntax if we had one. This was done for Boost Interface library (under construction, http://www.cdiggins.com/bil.html) and I think it helps a lot. Regards, &rzej

2 1

[type_traits] is_class not detecting C++0X lambda on Intel 11.1/Windows?
by Jesse Perla 19 Feb '10

19 Feb '10

The boost version of is_class doesn't seem to be compatible with lambdas in my target compiler. Am I missing something? Any patches/fixes you can think of? Sadly, I can't just use the tr1 version since this is being used internally within a boost library (boost::parameter in my case). BOOST_AUTO_TEST_CASE( test_is_class ) { auto f = [](double x){return x;}; // static_assert(boost::is_class<decltype(f)>::value, "Failure"); //Compiler failure line 81 of boost/type_traits/is_class.hpp static_assert(std::tr1::is_class<decltype(f)>::value, "Failure"); //Works using the built in tr1 for the compiler }

1 0

Formal review request: static size matrix/vector linear algebra library (Boost) LA
by Emil Dotchevski 18 Feb '10

18 Feb '10

Documentation and source code complete with comprehensive tests, released under the Boost Software License is available here: http://www.revergestudios.com/boost-la/ Thanks, Emil Dotchevski

18 50

[preprocessor]
by Баграт Асатрян 18 Feb '10

18 Feb '10

Hello. boost.preprocessor library is good, but it does not support in-place preprocessor metafunction composition and argument bindings. I have just implemented such a functionallity as in boost.mpl, and can say that it simplifies preprocessor metaprogramming greatly. If interested, contact me. С уважением, Баграт Асатрян. ---------------------------------------------- Тел.: +(374 94) 69-78-67, E-mail: bagrat_assatrian(a)mail.ru

6 10

[thread] Ticket #3748 ignored for boost-1.42?
by Oliver Kowalke 18 Feb '10

18 Feb '10

As I see the patch for the bug (is it?) was not applied for version 1.42. does somebody know why? Oliver

3 2

boost::property_tree is seriously outdated/incomplete
by Philippe Vaucher 18 Feb '10

18 Feb '10

Hello, Basically boost::property_tree documention is incomplete and outdated. There is simply no documentation on what a "Translator" is, only by digging the source you are able to understand it can be used to convert fetched values before returning them. Same goes for "stream_translator", still no idea what it's useful for. What's worse is that the documentation contains WRONG ways of doings things, like it says to change the default '.' separator one should use: pt.get<float>('/', "p.a.t.h/t.o/v.a.l.u.e"); But this is actually done like this: pt.get<float>(boost::property_tree::ptree::path_type("p.a.t.h/t.o/v.a.l.u.e", '/')); Then there are all the quickbook formatting bugs there and there, I made a ticket summing all I've found here https://svn.boost.org/trac/boost/ticket/3925 I hope someone will look after this because boost::property_tree has a great potential and it's a shame the documentation discourages people from using it. There's also obvious changes that ought to happen like being able to get the parent of a ptree node. My 0.02$ Philippe

3 6

Proposal for new variants of the Boost logo.
by Paul A. Bristow 18 Feb '10

18 Feb '10

After many discussions on the thread "Boost logo variants for use in unofficial or unreleased boost documentation" that many will have tired of, a few with more stamina have agreed the following proposal for wider agreement. Proposal for new variants of the Boost logo. =============================== There are many projects springing up, often with smart documentation using the Boost Logo, and there are many more products, for sale and for free, that use Boost libraries. Many are concerned at the 'Dilution of the Brand Identity': so we propose two new variant logos: 1 For projects that are written with Boost 'in mind', perhaps for submission, but are *not yet reviewed and accepted*. "For use with" - logo for projects having some association with Boost, but are *not 'official'*. (Many like red text to signal strongly that this is NOT (perhaps yet) a Boost approved library). 2 For projects that *use* Boost, and would like to acknowledge this - with thanks: "Powered by" - logo for all projects *using* Boost. (in addition to the 'Using Boost' listing on the website) To see the proposed logos: http://dbp-consulting.com/boostvariantslogo.html (produced by Patrick Hogan). (These logos will be available in bitmap, png and svg formats ready to be used in html and pdf docs). Paul PS Some were also in favour of a "Proposed for Boost" logo to be used only *for libraries in the review queue*, but not yet in a final release. Others felt this was unnecessary. So unless there is strong support for this, it does not form part of this proposal. --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

18 66

"Software Development using the C++ Boost Library", book in preparatiion Options
by Jesse Perla 17 Feb '10

17 Feb '10

Daniel: As a caveat, I am far from an expert. just a library user focused on scientific computing in economics... but here are a few more comments that I hope the experts can correct. > 2. type erasure: I looked this term up but it seems as if it is similar to interface/device independent/ programming. In the past we built homemade Function and used it in combination with OO specialisation with virtual functions, Now boost Function is so much > better. Mathematicians and engineers are used to functions and we adopt the same approach (e.g. using namespaces) boost::function certainly beats any home-spun solution. But type erasure is a way to bridge generic programming to give a common *runtime* interface. I think of it as akin to getting the benefits of dynamic polymorphism with arbitrary generic types - effectively creating a virtual function without inheritance. However, just as with dynamic polymorphism it is not without cost: The boost::function infrastructure puts in a dispatch which could drastically hurt performance if called in an inner loop (or have virtually no effect if the function itself is time consuming). The compiler can't inline the functions, etc. Also, the term "type erasure" should be taken literally. The functions which operate on the boost::function are not able to get any information on the type. For example, a common way to deal with a function and derivatives is to have a single function object with an operator() and a gradient() defined. But if you stuff this in a boost::function you lose the information and can only call a specific overload/template of operator(). You can see some old, stupid questions I had asked on this mailing list a while back about this topic: http://lists.boost.org/boost-users/2009/01/44253.php What I learned eventually was that I was trying to use type erasure when I didn't need it, and I was better off sticking with generic programming... So boost::function is very useful, but you run into the same tradeoffs and questions as static vs. dynamic polymorphism: If you don't need dynamic polymorphism, then consider sticking with compile time templates, etc. for better performance and genericity at the potential cost of code complexity. In the case of scientific computing, I find that almost everything is known at compile time and you are better off keeping the types generic/not using type erasure. If you are just using boost::function because the types of the function objects are complicated, consider the alternatives. See my comments in the previous post on the use of "auto" and "decltype" to make this manageable. > 3. Ideally, we would like TR1 and boost to be as seamless as possible. Check out: http://www.boost.org/doc/libs/1_42_0/doc/html/boost_tr1.html Just remember that boost::tr1 is intended to be used only if the vendor hasn't put in a tr1 library. > 4. Fusion: I think this is useful, especially with Any? While I have never used "any", I believe these are two different ways to deal with the problem. Using something like std::vector<boost::any> is another example of type erasure (just as std::vector<boost::function<double (double)> > would be). boost::fusion allows you to have a tuple-like vector of different types, but while retaining type information. The same types of tradeoffs apply as before... and fusion is only usable if you know the types at design-time. If you end up converting some of your code away from boost::function, you may need something like this. On the other hand, it can be pretty advanced so be careful... std::tr1::tuple is enough unless you need to apply an operation on the vector of types. For example, I have often had the case where I had a vector of functions I needed to evaluate. I was unable to use boost::function since I needed genericity so I had a boost::fusion::vector with the various function types. Then to evaluate the functions at the same point, I used a fusion::for_each, transform, or fold depending on what I was trying to do. Note that this should have very high performance: The fusion::for_each ends up doing something akin to loop unrolling at compiletime, and since I didn't lose any type information everything could be inlined. > 7. Numerical integration: I saw this extensive library in Vault. What is the status? These don't seem to be in active development. I have used http://www.coin-or.org/CppAD/ myself. When using AD you will find it extremely difficult to use boost::function because the function stops being generic when the type is removed (play with these libraries and you will understand quickly). This is a perfect example of why you should be wary of removing type information if you don't need to. I think that Robert is correct that you should make sure you study and work with type erasure/generic programming before writing those chapters, especially if you are intended this to be used for numeric computing. Efficiency is critical for these applications and dynamic polymorphism is often unnecessary. And don't be fooled by the name boost::function: Its primary purpose is to bridge dynamic polymorphism for generic callable types, and not to be a placeholder for mathematical functions. While using it can sometimes simplify code (when auto/decltype are not available), the cost should be considered. boost::phoenix, lambda, and bind do not erase type information and I believe all overhead of function adaptation could be optimized away with these. While a lot of the Template Metaprogramming book was beyond my needs, I found careful study essential reading(especially Chapter 9 which covers these topics) .... and that about exhausts my knowledge. Good luck with the book!

2 1

"Software Development using the C++ Boost Library", book in preparatiion
by Jesse Perla 17 Feb '10

17 Feb '10

Looks great to me. A few comments: ---------- Forwarded message ---------- From: "Daniel J. Duffy" <ddu...(a)datasim.nl> Date: Feb 15, 12:55 am Subject: "Software Development using the C++ Boost Library", book in preparatiion To: Boost Developers Archive > 1. Higher Order Functions I used to use boost::function a lot, but now find myself using templated classes with deduction of the function type instead and haven't used boost::function for a long time . I think when writing this section, it would be nice to have a good sense of when type erasure using boost::function is necessary. I found that the main reason I was using boost::function was not type erasure but rather that the types of the functions I was storing were complicated so it was easier to stuff in a boost::function and then have an easier way to reference the type. After I started using auto, decltype, and make_ functions, this became unnecessary. Of course, you can't count on people having "declype" or "auto", so my proposal would be to see if BOOST_AUTO, etc. should be suggested as a temporary solution for people without C++0X turned on. One other thing worth thinking about here is whether you should plan for standardizing on the tr1 namespace(and explain how to use boost::tr1). This might future proof the book as most mainstream compilers seem to have tr1 already. That said, I had a lot of problem with the tr1 library that comes with the Microsoft compiler mixing boost functional programming libraries and tr1::function/bind, so you might want to try things out before going down this route. > 6. Utilities and other Libraries I would love to see a short section on Fusion. I have found Fusion very useful and a good alternative to using type erasure for my applications. Of course, the numerical computing I do has almost everything known at compile time which may distort my view. Also consider type_traits and enable_if, and a minimalist use of MPL to support managing overloads (mpl::and, not, if, etc.). (a huge part of the superb C++ Template Metaprogramming book is about advanced features like iterators or your own sequences, which isn't necessary for most users)

3 4

define for 32/64 bitness?
by Oliver Kowalke 17 Feb '10

17 Feb '10

Does boost provide an preprocessor define telling if the boost lib is build for 32 or 64 bit? I need this info for the second parameter of posix_memalign(). regards, Oliver

5 7