- Boost - lists.boost.org

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