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

Review of Interval Template Library (ITL) for inclusion
by Eric Jonas 25 Feb '10

25 Feb '10

At the outset, I want to say that I enthusiastically support the inclusion of this library in Boost. I also encourage others without a specific application in mind to check out the library, as there are a lot of fun examples that you might later find useful in other coding projects. My Background -------------- My background: I develop combined hardware and software systems for recording from high-throughput neural systems. One of the primary challenges we face with such systems is the aggressive demands that 10 GB/hour of time-series data places on a typical workstation when you want to visualize it -- especially in real time, with appropriate historical context, at multiple zoom levels. I wrestled with this problem for a great deal of time before settling on various rendering and caching mechanisms. But the number one challenge was efficiently representing the temporal regions that had been viewed, those that had been rendered, and those that had been cached. Then I needed to propagate this state information through a complex dataflow pipeline. ITL solved this problem for me, in a way that honestly freed me from having to think about a lot of the unsavory low-level details. Specifics ------------ All of my work has been on Linux with a modern (4.3+) gcc. I have had collaborators build and use the resulting artifacts on OS X. I originally only anticipated needing interval_sets, but interval_maps became extremely useful as I started to keep track of metadata in my timing epochs. The segregation of interval_* and split_interval_*, while not necessary for my application, provides historical context that I can imagine being useful in some scenarios. What is your evaluation of the documentation? --------------------------------------------- I'd say the documentation was "Boost-quality", but some might see that as pejorative :) The tutorial had me up and running quickly, and the extensive examples helped me map my ideas to the library's primitives. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ------------------------------------------------------------------- I have used this library in production code that I have shipped to users, and have been working with it for several months. What is your evaluation of the potential usefulness of the library? ------------------------------------------------------------------- For my applications, it was crucial -- they would have been far less optimal (both from a software-engineering and asymptotic perspective) without ITL. The examples showcase a wider range of potential applications, especially the use of an example "Project" as a more complex example. Are you knowledgeable about the problem domain? ------------------------------------------------ As a consumer of many boost libraries for many years, from the simple (shared_tr) to more esoteric (variant) to completely crazy (fusion), I feel like I have a good sense of modern C++ API aesthetic. As someone who spends a great deal (too much) of his life working with time-series data structures, I am familiar with many of the underlying algorithms and data-structures. ...Eric Jonas Eric Jonas (jonas(a)mit.edu) PhD Candidate, MIT Brain and Cognitive Sciences

2 1

[math] long double autoconfiguration
by Vladimir Prus 24 Feb '10

24 Feb '10

Hi, at present, Boost.Math library always tries to compile long long versions of the function, unless explicit --disable-long-long is passed by the user. I have just checked in a patch that attempt to automatically determine if long long is available. Attached is a sample output of "bjam --with-math" build. The detection is done by compiling new file named libs/math/src/long_double_check.cpp -- if it compiles, it is assumed long double works. Unfortunately, I don't really know what kind of long double support Boost.Math needs. John, Paul, could either of you add some more content to that file? This change an SVN version of bjam as of today. If you use an older version, nothing should break, but no auto-detection will be performed. Also, if you need to look at compiler messages produced when compiling the test file, look at bin.v2/config.log Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2 Building the Boost C++ Libraries. Configuration checks summary - long double support : yes Component configuration: - date_time : not building - filesystem : not building - graph : not building - graph_parallel : not building - iostreams : not building - math : building - mpi : not building - program_options : not building - python : not building - regex : not building - serialization : not building - signals : not building - system : not building - test : not building - thread : not building - wave : not building ...patience... ...found 1584 targets... 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

4 5

virtual function templates
by strasser＠uni-bremen.de 24 Feb '10

24 Feb '10

Hi, is there interest in a boost utility to implement (pseudo-) virtual function templates? real virtual function templates are obviously not possible without a JIT-compiler, but if all derived types are known to the base type, something like the following is. I've used a non-generic form of this a couple of times: struct base : enable_vtemplate<derived1,derived2>{ template<class OutputIterator> void f(OutputIterator it){ BOOST_VTEMPLATE(f,(OutputIterator),(it)); it << "not overridden\n"; } BOOST_SUPPORT_VTEMPLATE(); }; struct derived1 : base{ template<class OutputIterator> void f(OutputIterator it){ it << "derived1\n"; } BOOST_SUPPORT_VTEMPLATE(); }; struct derived2 : base{ template<class OutputIterator> void f(OutputIterator it){ it << "derived2\n"; } BOOST_SUPPORT_VTEMPLATE(); }; the runtime overhead besides the virtual call is one switch().

6 9

shortest path between vertex A and B
by Alexandre de Morais Amory 24 Feb '10

24 Feb '10

Hi, I am starting to use BGL. I manage to read/write in dot format, add few attribs, etc. my next task is to get the set of vertex in the shortest path between vertex A and B. In a graph like this: a - b b - c c - d assuming 'a' and 'c', the result would be {a,b,c}. I know it sounds silly, but most similar examples I could find are much more complex than this. I guess breadth_first_search would solve the problem, but I am having trouble with the visitor concept... how to implement a visitor to get the set of vertex in the path between two points. Other features of the problem: I am assuming an undirected graph. all edges have unitary distances. If there are multiple shortest paths between A and B, any of the valid solutions can be returned. thanks in advance for any clue ! Regards, Alexandre Amory

2 1

[thread] compile errors on Sandia-intel-10.1/11.0/11.1
by Emil Dotchevski 23 Feb '10

23 Feb '10

The error below is detected building a couple of Boost Exception tests that use Boost Thread. Thanks Noel and Steven for helping diagnose the problem. "/opt/intel/Compiler/11.1/067/bin/intel64/icpc" -xc++ -w1 -O0 -g -inline-level=0 -vec-report0 -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_POSIX -I".." -c -o "/Volumes/Scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/intel-darwin-11.1/debug/link-static/threading-multi/pthread/thread.o" "../libs/thread/src/pthread/thread.cpp" ../libs/thread/src/pthread/thread.cpp(385): error: identifier "get_nprocs" is undefined return get_nprocs(); ^ Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

[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