February 2010 - Boost - lists.preview.boost.org

[Regex & ICU] boost::regex & icu compilation warnings: missing #pragma pack(pop)
by Henry Tan 23 Feb '10

23 Feb '10

Wondering if this is a known issue and there is a solution to fix this build warning when you are compiling boost::regex with ICU library. >warnings in directory d:\ >d:\boost_1_41\boost\regex\v4\u32regex_iterator.hpp(25) : warning C4103: 'd:\boost_1_41\boost\regex\v4\u32regex_iterator.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) >d:\boost_1_41\boost\regex\v4\u32regex_iterator.hpp(187) : warning C4103: 'd:\boost_1_41\boost\regex\v4\u32regex_iterator.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) >d:\boost_1_41\boost\regex\v4\u32regex_token_iterator.hpp(38) : warning C4103: 'd:\boost_1_41\boost\regex\v4\u32regex_token_iterator.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) >d:\boost_1_41\boost\regex\v4\u32regex_token_iterator.hpp(368) : warning C4103: 'd:\boost_1_41\boost\regex\v4\u32regex_token_iterator.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) Cheers, HT

2 1

[exception] help needed diagnosing Sandia-intel-10.1/11.0/11.1 failures
by Emil Dotchevski 23 Feb '10

23 Feb '10

See the following logs, which seem identical, and it isn't clear to me what's wrong: http://tinyurl.com/yzjo8v4 http://tinyurl.com/ygooqj7 http://tinyurl.com/yjp3n68 Ideas? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

4 3

[thread][config] VC10RC fails compiling when using thread library (BOOST_NO_RVALUE_REFERENCES)
by Hartmut Kaiser 23 Feb '10

23 Feb '10

Hey all, the new 'un-definition' of BOOST_NO_RVALUE_REFERENCES for VC10 breaks compilation of code using the thread library. Is it a problem of VC10 or the thread library? Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

7 16

Re: [boost] Boost Graph library - r_c_shortest_paths
by Andrew Sutton 23 Feb '10

23 Feb '10

> I checked the files I sent you and they were the correct versions (all > three code files: the test file, the example file, and > r_c_shortest_paths.hpp). The test and example files both run without any > problems on my system (WIN XP 32 SP 3, MS Visual C++ 2008). > I've finally had some time to go through the resubmission. There are/were a number of issues that need to be addressed. First, property maps, functors, and visitors are virtually always passed by value. If those objects need to maintain complex state between calls, it's typically done by building a functor (visitor, etc) that has a reference to an external state object. I fixed this. Second, I removed the ks_smart_ptr class, which turned out to be not very smart. It only wrapped the pointer, but didn't manage it in any way. I also cleaned up some of the allocation/deallocation code by moving the calls to two new functions create and destroy. Inidentally, valgrind shows that this implementation leaks memory. I put cout's in create and destroy to count allocations and deletions (16646 allocs to 15994 deallocs). My guess is that one of the rarer code paths in the dispatch doesn't actually delete. This needs to be investigated. Third... just a style point... some of the identifiers are a little long. I think the readability could be improved by shortening them. Fourth, and I'm hoping to get Jeremiah's input on this... I'm not a fan of passing vector<vector<>>& or vector<>& as top-level parameters. It might be better to require a template parameter that is essentially a matrix- or vector-like object. That would simplify the call interface and allow a little more freedom w.r.t. parameter types. Thoughts? Fifth... and Final... The interface to the algorithm is changing which can break backwards compatibility. Maybe we need to give the new module a different name. Thoughts? Here's a tarball with the code ready to be dropped into Boost. You should refer to this version since its what I'm going to be merging. http://www.cs.kent.edu/~asutton/rcsp.tar.bz2 Andrew Sutton andrew.n.sutton(a)gmail.com

2 5

Re: [boost] [msm] scalability
by Christophe Henry 22 Feb '10

22 Feb '10

David Abrahams wrote: > The idea would be to do all parts that are “hard on the compiler” > at runtime. I don't see why you should have to sacrifice features. I promised to make an analysis of which feature costs how much compile-time and test your point. I hope to bring a beginning of an answer and hope you will enjoy the trip to VC++ world ;-) I took the iPod example from the last BoostCon and compile it with VC8 and VC9 in Debug and Release. I think it is an interesting example: submachines, orthogonal regions, a good number of states. I also took the MPLLimitTest example (80 transitions, 80 states) to check a wide state machine not factored into any submachines. Both can be found in the sandbox in libs/msm/doc (/iPod or directly for the MPLLimitTest). So, the results: VC9 (Release): 60s VC9(Debug): 79s VC8(Release): 64s VC8(Debug): 183s (!!!) Notice how debug takes so much longer, as rightly noticed by Jeff. Part1: we now move the submachines into different headers, simply included in the main application. Should change nothing, right? First small surprise, it helps VC8 in Debug: VC9 (Release): 65s VC9(Debug): 80s VC8(Release): 68s VC8(Debug): 166s I didn't see why Debug took so much longer, so I played a bit with the compiler options until I found the culprit. If we now deactivate the /Gm option ("Enable minimal rebuild") in Debug (not activated in Release), we now see a big difference: VC9(Debug): 58s VC8(Debug): 62s Waow! 20s better for VC9, 102 for VC8. This could explain Jeff's problems. This is what I call a successful optimization from the compiler to create a minimal rebuild. Now Debug builds are faster than Release (due to shorter link time if you ask). Part2: This is nice but we did not add any new policy for faster compiling yet. I now add one. Unfortunately, reducing the number of template instantiations proved to be a hard business as most of removed instantiations which were "hard on the compiler" were still done somewhere else and VC is clever enough not to repeat itself. On the MPLLimitTest it gives: Before: VC9(Release): 134s VC9(Debug): 135s (without /Gm. Otherwise count 275!) VC8(Release): crash :( (ok this is really a hard test) VC8(Debug): I stopped after the compiler used up 3,5GB of my 4GB... after: VC9(Release): 84s VC9(Debug): 84s VC8(Release): crash :( VC8(Debug): 153s Ok better. It can be also better for the iPod example as the policy allows you to move some of the metaprogramming for submachines to other TUs and compile with 3 cores (one fsm, 2 submachines) using /MP (available on VC8 and VC9). See in the doc the example in iPod/Part2. We now have the following compile time (using 3 cores): VC9(Release): 44s VC9(Debug): 37s VC8(Release): 50s VC8(Debug):40s This looks much better as it allows the clever user to build submachines and enjoy better compile times. For cases where performance is needed, simply omit the submachines' cpp files from build. The trick works using a boost::any to contain the event, thus allowing you to avoid instantiating a process_event inside the main machine process_event. The only feature you lose with this policy is the new possibility to make a derived event fire his basis event's transition (any can recognize only strict types). So this is the current state. But it can be better. We still pay for the instantiation of submachines into the main machine, which still costs you time. I made a test using a proxy for submachines. The proxy containing only a void* to the real submachine, instantiating it is cheap. It's not finished but we now build on 5 cores (the main fsm, 2 for each submachine, 2 submachines). Yes we can now build a submachine on 2 cores :) This gives us the possible future compile-time: VC9(Release): 34s VC9(Debug): 27s VC8(Release): 40s VC8(Debug):30s I hope this will make the compile-time problem more manageable. Again, more to come on this later. Jeff, if you could give it a try, it would be really great! Christophe PS: I am using a Q6600, 4 cores, 2.4GHz, no hyperthreading. We can soon use the new hexacore with hyperthreading :)

2 1

[geometry] Documentation prototype for review
by Mateusz Loskot 22 Feb '10

22 Feb '10

Hi, I'm working on documentation of Boost Geometry based on Quickbook and I've prepared a prototype: http://mateusz.loskot.net/tmp/ggl/qbk/ What I'm doing is manually porting the content from Doxygen-based (http://geometrylibrary.geodan.nl/) plus restructuring, reformatting and completing it with missing details. I'd like to ask everyone who is interested in Boost Geometry library for comments, impressions and suggestions of improvements. Note, nodes marked with (?) are not finished and empty, but included to give impression about the overall structure. I'd be especially interested comments about the structure, if it's accessible to new users and usable for advanced users at the same time. The Reference is one of the most important section I'd like to master, so please share your comments on the form and completeness of the concepts specification, for example: http://mateusz.loskot.net/tmp/ggl/qbk/geometry/reference/geometries/concept… types description, for example: http://mateusz.loskot.net/tmp/ggl/qbk/geometry/reference/geometries/types/p… and functions description: http://mateusz.loskot.net/tmp/ggl/qbk/geometry/reference/arithmetic/add_poi… Thanks in advance for your feedback. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

3 4

[build] summary at end
by Vladimir Prus 22 Feb '10

22 Feb '10

FYI, Previously, I've made the build process to print information as to where the headers and libraries are to be found. However, that was printed at the start of the build, and many used missed that. I've now checked in a patch to print the message at the end of the build (if there are no errors). You need trunk bjam for this to work. Older bjam will not print that message but otherwise work. The sample wording is as follows: The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: /home/ghost/Work/Boost/boost-svn The following directory should be added to linker library paths: /home/ghost/Work/Boost/boost-svn/stage/lib Comments are appreciated, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

1 0

[exception][msvc-7.1] regression and use of member template friends
by JOAQUIN M. LOPEZ MUÑOZ 22 Feb '10

22 Feb '10

Hi, In its current state in trunk, boost/exception/exception.hpp is generating regressions with MSVC 7.1 as shown in: http://tinyurl.com/yckdxrc The problem has to do with some (correct) member template friends declarations that MSVC 7.1 is not able to handle. Lines 222 and ff. of boost/exception/exception.hpp read: #if defined(__MWERKS__) && __MWERKS__<=0x3207 public: #else private: template <class E> friend E const & exception_detail::set_info( E const &, throw_function const & ); [...] To solve the problem the nicest solution would be to replace this by: #if defined(BOOST_NO_MEMBER_TEMPLATE_FRIENDS) public: #else private: template <class E> friend E const & exception_detail::set_info( E const &, throw_function const & ); [...] But exception.hpp, presumably to speed up compilation times, does not include any other header, so seems like including <boost/config.hpp> just to get this macro could be unacceptable. If this is the case, I suggest that the code be changed so as to simply go public and omit the member template friend declarations altogether. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Status of Boost.Polygon
by Anders Dalvander 22 Feb '10

22 Feb '10

According to the announcement (http://comments.gmane.org/gmane.comp.lib.boost.announce/240) Boost.Polygon library was accepted into Boost on 5 November, provided some of the most critical concerns are addressed first. I cannot find it in the 1.42 release of Boost. When can I expect it to exist in a Boost release? Regards, Anders Dalvander

2 1

[getting started] mention boost.build options for abi tages
by Vladimir Prus 21 Feb '10

21 Feb '10

Often, users are asking how they can get "boost_whatever... mt-s ...", or something like that. The attached patch augments with ABI tags table in the getting started guide with corresponding Boost.Build options. Note that I have more suggested changed (in particular to say that naming on Unix is now different), but wanted to split into individual patches for easier review. I've also dropped stlport iostream option, since it's deprecated and in my understanding nobody uses it any longer. OK to commit? Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

2 1

sp_convertible<> on MSVC10
by Zachary Turner 20 Feb '10

20 Feb '10

I'm using 1.42, not trunk, so I don't know if this has already been addressed, but sp_convertible fails with some errors for me. 2>C:\dev\boost\1.42.0\boost/smart_ptr/detail/sp_convertible.hpp(49): error C2070: 'void': illegal sizeof operand 2> C:\dev\boost\1.42.0\boost/smart_ptr/detail/sp_convertible.hpp(68) : see reference to class template instantiation 'boost::detail::sp_convertible<Y,T>' being compiled 2> with 2> [ 2> Y=error_info_tag_t, 2> T=boost::exception_detail::error_info_base 2> ] 2> C:\dev\boost\1.42.0\boost/exception/info.hpp(159) : see reference to class template instantiation 'boost::detail::sp_enable_if_convertible<Y,T>' being compiled 2> with 2> [ 2> Y=error_info_tag_t, 2> T=boost::exception_detail::error_info_base 2> ] 2> C:\dev\boost\1.42.0\boost/exception/detail/exception_ptr.hpp(170) : see reference to function template instantiation 'const E &boost::operator <<<boost::unknown_exception,boost::tag_original_exception_type,const type_info*>(const E &,const boost::error_info<Tag,T> &)' being compiled 2> with 2> [ 2> E=boost::unknown_exception, 2> Tag=boost::tag_original_exception_type, 2> T=const type_info * 2> ] 2> C:\dev\boost\1.42.0\boost/exception/detail/exception_ptr.hpp(137) : see reference to function template instantiation 'void boost::unknown_exception::add_original_type<std::exception>(const E &)' being compiled 2> with 2> [ 2> E=std::exception 2> ] 2>C:\dev\boost\1.42.0\boost/exception/info.hpp(159): error C2664: 'boost::exception_detail::error_info_container::set' : cannot convert parameter 1 from 'boost::shared_ptr<T>' to 'const boost::shared_ptr<T> &' 2> with 2> [ 2> T=error_info_tag_t 2> ] 2> and 2> [ 2> T=boost::exception_detail::error_info_base 2> ] 2> Reason: cannot convert from 'boost::shared_ptr<T>' to 'const boost::shared_ptr<T>' 2> with 2> [ 2> T=error_info_tag_t 2> ] 2> and 2> [ 2> T=boost::exception_detail::error_info_base 2> ] 2> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called The line it's pointing to is this: enum _vt { value = sizeof( f( static_cast<Y*>(0) ) ) == sizeof(yes) }; and in particular it's having a problem determining the return type of f( static_cast<Y*>(0) ). It's thinking that whatever overload it's finding for f() here returns type void. Which doesn't make sense neither one returns void. Any ideas? Zach

5 8

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

20 Feb '10

> > 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? > The library follows Eiffel semantics for constructor which is {Default > AND Pre}Body{Post AND Inv} where Default is default initialization of > members (similar to C++ member initialization list). That said, it > would be difficult to implement a different semantics (like the one > you suggest) in C++ because of the lack of delegating constructors. The sole fact that other language implements it this way is not sufficient an argument. I can think of the situation when "Eiffel order" may cause damage that the inverse order might have prevented: Type::Type( int & counter ) precondition{ counter < MAX; } : handle( irreversibleChange(int--) ) { ; } Suppose the constructor of Type is called, and the value of counter is MAX. This value is invalid, but by the time the precondition is checked, the irreversibleChange is executed, and the value of counter is reduced, so the assertion concludes that everything is fine. Now, the argument that it is difficult to implement is convincing; it may be that it is impossible at all. But I would call not having the {Pre->Init} order a limitation of the library. Let me be clear: one tiny limitation in the great library, because out of many attempts to provide contract programming to C++ I have seen, this is the only one that really looks good. Regards, &rzej

2 1

[mpi] Documentation patch
by Number Cruncher 19 Feb '10

19 Feb '10

Attached is a patch (against 1.42) to fix a couple of minor errors with the Doxygen documentation for some headers in the boost/mpi library. The errors relate to Doxygen usage, not content. Simon.

1 0

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

19 Feb '10

Hi, two other questions that came to my mind, regarding the library design. (1) Sometimes the assertions execute longer than the function itself. For example: iterator find( iterator begin, iterator end, value v ) precondition { is_sorted( begin, end ); } { return find_sorted( begin, end, v ); } find_sorted has logarithmic complexity, whereas is_sorted has linear one. If I use function find like this: sort( begin, end ); process( find(begin, end, A) ); // call is_sorted process( find(begin, end, B) ); // call is_sorted process( find(begin, end, C) ); // call is_sorted is_sorted is called many a time. Even if I am in debugging mode but use a medium size range, the performance can kill me. I would like to disable checking of this assertion, but at the same time there is no reason to disable others. Would you consider providing a way to selectively disable asserts? some assertion level? (2). Usually public member functions would be used to express DbC assertions. Do you disable assertions in public functions that are called only to evaluate other assertions in order to avoid recursive calls? Regards, &rzej

2 1

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

"Software Development using the C++ Boost Library", book in preparatiion
by Daniel J. Duffy 17 Feb '10

17 Feb '10

Hello, We would like to announce news on our new book in preparation that is based on the Boost library. Below is a description of what the book is about and its focus. We discuss several applications such as computational finance, simulation, maths, engineering as well as examples for a wider audience. The book is pitched at intermediate level and upwards. We would be very interested in receiving feedback from Boost authors (and those who are workinng with the library) concerning the chapters in the book, especially the extensive functionality in the library and possibly examples from areas not discussed above. best regards and thank you! Daniel J. Duffy Robert Demming // Book Proposal "Software Development using the C++ Boost Library" Daniel J. Duffy (dduffy(a)datasim.nl) Robert Demming Datasim Education BV February 2010 Publisher: Datasim Press Ltd. Web site: http://www.datasimfinancial.com/ <http://www.datasimfinancial.com/> What is this book? This book introduces and elaborates the C++ boost library and applies it to creating code and applications for a range of domains such as engineering, computational finance, mathematical physics and other exact disciplines. We have written the book in such a way that the learning process is as seamless as possible; first, for each library we introduces its main features by discussing its syntax and by giving '101' examples to show to use it as quickly as possible. Second, we introduce some of the more advanced features in each library with a view to using and customizing them to suit application needs. Finally, we create small and medium-sized applications and test cases by integrating several libraries to show the usefulness and applicability of boost to support complex software systems. The book is structured into seven major categories, each one of which dealing one particular aspect of software development and its applications. For whom is this Book? We have tried to write the book in such a way that it is accessible to as wide a group of developers as possible (an impossible task!) by the appropriate use of examples at each level of developer expertise and test cases that are of direct relevance in a number of application areas. We assume that the reader has several years of experience of object-oriented and template programming in C++. Application Development using Boost Regarding the test cases and applications we try to model them in such a way that the reader understand the problem and design intent before we discuss the actual coding. To this end, we consider the use of UML class and component diagrams (in the appropriate dosage!) to be essential. In one sense, "UML is C++ in pictures". Some applications that we discuss in the book are: Using Lambda to simplify use of STL algorithms Using Signals to implement, MVC, Observer and PAC patterns (GOF, POSA) Using Bind and Function to semi-discretise partial differential equations (PDE) Random for Monte Carlo simulation, numerical integration and option pricing Any and data-independent parameter passing between modules Interval arithmetic and explicit modelling of numerical imprecision Various text-processing applications Compile-time arrays and matrices using Array Using multi_array to model n-dimensional PDEs uBLAS as data structures for numerical algebra Statistical functions and their applications Accumulators and time series applications Using Flyweight as default in applications Multi-threaded scientific applications Network programming and Asio Mapping GOF patterns to boost (i.e. using boost to implement design blueprints) /// Categories of Libraries 1. Higher Order Functions Function Bind Lambda Signals/Signals2 2. Data Types Any Integer Interval Parameter Rational Smart Pointer Tribool Tuple Variant 3. Text and String Processing Regex String Algo Tokenizer Xpressive 4. Data Structures and Searching Array Date Time Graph Multi-Array Multi-Index 5. Mathematics and Statistics Accumulators Math Common Factor Math/Special Functions Math/Statistical Distributions Random uBLAS 6. Utilities and other Libraries Conversion Dynamic Bitset Filesystem Flyweight Lexical Cast Numeric Conversion Program Options Test 7. Multithreading and Networking Asio Statechart Thread Timer Yours sincerely and thank you Daniel Duffy, PhD Ing. Robert Demming

9 14