September 2011 - Boost - lists.preview.boost.org

Re: [boost] [Review:Algorithms] Comments about search algorithms
by dpxguard-boost＠yahoo.gr 29 Sep '11

29 Sep '11

> Phil Endecott wrote: > > - A user faced with these three (or four) algorithms will need to > > choose one. The docs should offer some guidance, e.g. benchmarks or > > rules-of-thumb, about which to use. > In particular, I've not yet found a case where KMP is the best choice. > BM seems better in all the cases that I've tried and has the same or > better complexity bounds. (Well, it might perform slightly better when > the pattern length is 1 but in that case, std::find could be used.) > Does anyone know of any cases where KMP is likely to be better than > BM? (If we can't find any, is it worth including it?) I will try to give a complete answer... The most notable (and common) techniques for improving the sequence searching performance are the bad-character shift (occurrence shift) and the good-suffix shift (matching shift). The Boyer-Moore algorithm implements both these techniques, while the Boyer-Moore-Horspool only implements the bad-character shift and the KMP is merely based on the good-suffix shift. (Although the Boost.algorithm documentation only states that Horspool "is a refinement of the Boyer-Moore algorithm that trades space for time", this is by no means the most notable difference between these two algorithms.) In general, bad-character shift performs very good when the search-pattern is relatively small and the alphabet relatively large. On the other hand, good-suffix shift helps more when the pattern is relatively large and the alphabet small. In the most common cases of text searching, the patterns are usually small and the alphabets large, (> 255) hence the KMP (which is only using good-suffix shift) will almost never outperform BM in usual text-searching situations. (Note that KMP has not been used in the original std::search implementation of the STL, because even the straightforward (brute-force) algorithm has been considered to be superior in the average case!) The only practical case that I could think of, where the KMP could possibly outperform the BM are the DNA searches, where the patterns can be very long and the alphabet has only four characters. And even then, I would recommend careful performance testing, in order to ensure that KMP can be significantly faster than BM. However, in my opinion the most interesting and useful property of the KMP algorithm is not its performance, but its ability to help in building very generic sequence searching algorithms. In fact KMP has helped me to build an efficient generic sequence searching algorithm, which actually works with ranges accessed by single-pass (input) iterators. (See http://www.codeproject.com/KB/stl/single_pass_search.aspx and also in boost-vault/Algorithms) Needless to say that I would be more than happy to submit this work to boost, whenever there is an interest. Best regards Jim Xochellis Homepage: https://sites.google.com/site/xochellis/

3 7

[threads] Problem static linking with boost.thread during cross-compilation
by Victor Leschuk 29 Sep '11

29 Sep '11

Hello all, I have just met the following problem: I am cross-compiling boost 1.47 using $ x86_64-w64-mingw32-g++ --version x86_64-w64-mingw32-g++ (GCC) 4.5.4 20110822 (prerelease) On Linux box with the following command: ./b2 -a toolset=gcc target-os=windows threading=multi threadapi=pthread runtime-link=static --layout=versioned --build-type=complete install user-config.jam contains the following: using gcc : mingw : x86_64-w64-mingw32-g++ ; After that a linkage failed when building my project. I reproduced it with simple test program: #include <boost/thread.hpp> #include <iostream> using namespace std; struct test { void operator()() { cout << "Called" << endl; } }; int main() { test test_obj; boost::thread thr(test_obj); thr.join(); } The output looks like $ x86_64-w64-mingw32-g++ -Wall test_boost.cpp -I ./3rdparty/boost/include/boost-1_47 -L ./3rdparty/boost/lib -lboost_thread-mgw-mt-s-1_47 -o test_boost.exe In file included from ./3rdparty/boost/include/boost-1_47/boost/thread/win32/thread_data.hpp:12:0, from ./3rdparty/boost/include/boost-1_47/boost/thread/thread.hpp:15, from ./3rdparty/boost/include/boost-1_47/boost/thread.hpp:13, from test_boost.cpp:2: ./3rdparty/boost/include/boost-1_47/boost/thread/win32/thread_heap_alloc.hpp:59:40: warning: inline function ‘void* boost::detail::allocate_raw_heap_memory(unsigned int)’ declared as dllimport: attribute ignored ./3rdparty/boost/include/boost-1_47/boost/thread/win32/thread_heap_alloc.hpp:69:39: warning: inline function ‘void boost::detail::free_raw_heap_memory(void*)’ declared as dllimport: attribute ignored /tmp/ccSmsBnO.o:test_boost.cpp:(.text+0xde): undefined reference to `__imp__ZN5boost6thread4joinEv' /tmp/ccSmsBnO.o:test_boost.cpp:(.text+0xfb): undefined reference to `__imp__ZN5boost6threadD1Ev' /tmp/ccSmsBnO.o:test_boost.cpp:(.text+0x1c3): undefined reference to `__imp__ZN5boost6threadD1Ev' /tmp/ccSmsBnO.o:test_boost.cpp:(.text$_ZN5boost6threadC1I4testEET_NS_10disable_ifINS_14is_convertibleIRS3_NS_6detail13thread_move_tIS3_EEEEPNS0_5dummyEE4typeE[boost::thread::thread<test>(test, boost::disable_if<boost::is_convertible<test&, boost::detail::thread_move_t<test> >, boost::thread::dummy*>::type)]+0xd5): undefined reference to `__imp__ZN5boost6thread12start_threadEv' collect2: ld returned 1 exit status The same scenario works fine when linking with dynamic libboost_thread. Both static and dynamic builds work fine for Linux. What could be the cause of the problem and where to look? Does it worse posting a defect in bug-tracker? Thanks! -- Victor

2 3

Re: [boost] Gauging interest in patch submissions
by Hongli Lai 29 Sep '11

29 Sep '11

GMan wrote: > My only concern with this is in a case like this, for example: > > while (/* reading lines from file, parsing integers, otherwise ignoring*/) > { > try > { > myInts.push_back(boost::lexical_cast<int>(currentLineStr)); > } > catch (const boost::bad_lexical_cast&) // (has stack trace) > {} > } > > Will the stack trace make such an operation noticeably slower? I know it's > easy to retort with "don't use exceptions for flow control" but I believe my > concern is valid, even if it's a bit contrived of a situation. > > Perhaps we'd like to make it opt-in, like BOOST_THROW_EXCEPTION_TRACED or > something. I don't know what one considers "noticeably slower", but there will be overhead for sure. In our implementation, the creation of a tracable_exception object copies the current stack trace into itself. This may or may not be large depending on how many stack traces are defined. We've done our best to optimize our implementation but it's still an O(n) operation. There is one concern that I have with BOOST_THROW_EXCEPTION_TRACED. Will it affect the ABI? Suppose I compile against a Boost library that's installed on the system, and it was compiled without BOOST_THROW_EXCEPTION_TRACED. If I define BOOST_THROW_EXCEPTION_TRACED now will this change the exception hierarchy, and thus, the ABI? - Hongli -- Phusion | Ruby & Rails deployment, scaling and tuning solutions Web: http://www.phusion.nl/ E-mail: info(a)phusion.nl Chamber of commerce no: 08173483 (The Netherlands)

1 1

[any] new version
by Martin Bidlingmaier 28 Sep '11

28 Sep '11

Hi, I've written a new version of boost::any. It does not depend on rtti and uses a static integer value instead of std::type_info to store type information. My version passed the unit tests included in boost 1_47_0 on vc++2010 express and gcc 4.5.(mingw) . With this mail, I'm sending the source and a small quick-and-dirty benchmark. On gcc, moving and copying performance seems to be roughly the same, any_cast however is about 400% faster. On msvc++, moving and copying times rise by ca. 50%, while any_cast is about 50.000% faster (although I guess the speed boost measured in a real benchmark would be in the order of magnitude of the gcc speed up). I would appreciate if somebody measured the performance with proper tools and tested it on more platforms. Sincerely, Martin Bidlingmaier -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

26 87

[Review:Algorithms]
by Thorsten Ottosen 28 Sep '11

28 Sep '11

Hi Marshall, Some minor comments based on reading the docs only. A. xxx_of_val should be named xxx_of_equal or something IMO, or the name should simply be overloaded. B. Documentation for clamb: I dislike the "iff". Just say "if", because this doesn't clash with the case v==lo/hi. Use the names low/high or lower_bound/upper_bound. The "High point" terminology may be replaced with "upper bound" IMO. C. (ordered) I think the cannonical way is to use range_iterator<const R> instead of range_const_iterator<R> D. write #include <boost/algorithm/search.hpp> instead of Header 'search.hpp' (and similar for other names) in the documentation. E. A small code example on each page would be nice. F. Why is there no range-based versions of Boyer-Moore etc.? G. You could consider to present the iterator version and the range version of all algorithms on the same page. H. I couldn't fine any details about detail::BM_traits<>. Do I need to know about these? That's it. I think this is a useful, minor addition to Boost. I vote "yes" for inclusion. regards Thorsten

6 8

Re: [boost] [contract] syntax redesign
by Andrzej Krzemienski 27 Sep '11

27 Sep '11

> I think option B (current) is still better than option A because A requires > (1) more parenthesis and (2) the extra assertion word spelled out all the > times but A doesn't require the trailing `,` which is a plus. > Do you have a strong opinion about which one is better between A and B? I'd > say B is better but I'm quite biased at this point ;) Hi Lorenzo, Since you ask about personal preference, I think mine is option A. I can think of the following reasons: * Given the fairly complicated syntax for Boost.Concepts, option A appears to me to add more structure to the declaration, and makes parsing it easier. Especially that I imagine you could further simplify it: instead: var(auto old_size = CONTRACT_OLDOF size()) could be: var( old_size = CONTRACT_OLDOF size() ) * Since you put each assertion (or declaration) in a separate line anyway option B appears also elegant, but if someone starts putting multiple assertions in the same line, I think option A would be clearer. Compare: postcondition( x - 1 == y + 2, y - 1 == z + 2 ) postcondition( assert(x - 1 == y + 2) assert(y - 1 == z + 2) ) * If anyone writes a tool for generating documentation from Contracts, I think parsing would be easier with option A. * In option A, it is easier to tell assertions from declarations, I can easily count how many things are asserted * I suspect that you can use commas more freely inside assertion(), which reduces the necessity of using "identity" function workaround. But I could hardly call it a strong opinion. It is just my preference, and I will like Boost.Contract with either syntax. Regards, &rzej

1 0

[Review:Algorithms] Order of args to clamp
by Phil Endecott 27 Sep '11

27 Sep '11

Dear All, Some quick comments about the proposed clamp() function: template<typename V> V clamp ( V val, V lo, V hi ); I have a clamp function that orders the args low - middle - high, which seems like a more natural ordering to me. Is there some rationale or precedent for this middle - low - high ordering? I think the confusion matters in this case because type checking won't help to detect mistakes, and in the most obvious applications (e.g. sanitising input) it might be hard to spot an error. (In contrast, max(low,min(mid,high)) is unambiguous and not much more typing...) I note that this function takes its args by value, while std::min & max take const references. What is the rationale for this? Like min & max, clamp has a single type template parameter; what are the implications of this? For example, if I pass a mixture of std::string and const char* arguments, what will happen? Ideally, (a) all combinations would compile, and (b) conversions from const char* to std::string will only happen when necessary, not unconditionally for all of the arguments. (Maybe that is asking too much, though.) Regards, Phil.

17 91

[signals1/2] Alternative approach
by Sebastian Karlsson 27 Sep '11

27 Sep '11

A while back we evaluated signals 1 & 2 and came to the conclusion that the performance is to poor for it to be viable for our use. I have an idea which nets very close to the same invocation performance as std::vector< boost::function< > > ( an extra shared_ptr<> per ), with the caveat that ordering within a priority group is unspecified. Another downside compared to the implementation used now is that it needs extra bookkeeping per distinct priority group ( although from the docs for signals1 it would seem it does the same ). The gist of it is that we maintain a vector< > ( preferably we let the storage be parameterized ) in addition to a separate map for the priority groups. The map is keyed on the priority type, and the bookkeeping is: vector offset, group length & shift. Offset & length gives us the region in the vector. Shift tells us how much the group is shifted from its start offset since it was created. So each area is maintained as a sort of sliding window meets circular buffer. With this information we need touch no more than the either the last or first element ( depending on connect / disconnect ) of the groups with a lower priority than the one the element belongs to. Our vector contains a std::pair< function< signature >, shared_ptr< unsigned int > >, the unsigned int is used both as a cookie for the signals::connection to make sure that the connection is still valid, as well as a shared offset in regards to the shift of the group. The arithmetic is very light weight and shouldn't pose a bottleneck. Although I haven't implemented blocking & consistent disconnect / connect behavior during invocation yet I'm fairly certain they can be done in the following way: For blocking we can either use an additional bool which we branch on when invoking, or we can simply let the connection temporarily remove itself from the vector and insert itself once it's not blocking anymore, second solution probably preferred. Disconnect / connect during invocation is a trickier one. The way I'm thinking is to let the signal maintain the iterator as a member. When we disconnect / connect we can see if it equals end ( we're not invoking ), or if it doesn't then we know both the position as well as we're in the middle of an invocation. This way we can let the disconnect / connect logic modify the "cursor" in order to make sure that we get the desired behavior while not polluting our invocation loop. Pros: More cache friendly Very close to ideal case for invocation Cons: Using std::vector<> as a base naturally means we'll suffer from the usual growth caveats. However, if this matters the user could use a paged container with a decent growth strategy and come extremely close to the ideal case anyway. Thread safety within an invocation seems like it might be costly to implement, especially for vector<>. Slower connect / disconnect. All in all I think it's a big win for what I personally believe to be the most common usage of the signals library. I've attached a proof of concept along with a fairly primitive benchmark. There's a fragmented list version which can be enabled by a def, but it's naturally slow as hell to setup so it's disabled by default. The fragmented versions does not use exactly the same random sequence as the others, but hopefully it's somewhat fair. The vector variants somewhat "cheats" in that they reserve the space straight up, this is something which I personally feel should be exposed in the interface in someway anyway however. Here's some results: i5-2500k @ 3.3 ghz, decent mem etc: Using numConnections = 100000 numCalls = 100 numGroups = 200 rndSeed = 0 fragSpread = 10 Generating random sequence takes: 0.002 seconds Connecting to unfrag list:< function<> >: 0.008 seconds Connecting to vector< function<> >: 0.007 seconds Connecting to unfrag signals2< function<> >: 0.051 seconds Connecting to unfrag signals1< function<> >: 0.166 seconds Connecting to test::signals< function<> >: 1.38 seconds ... ... ... vector< function<> > invocation: 0.026 signals< function<> > unfragmented invocation: 1.632 signals2< function<> >unfragmented invocation: 1.404 list< function<> > unfragmented invocation: 0.03 test::signals< function<> > invocation: 0.023 signals< function<> > fragmented invocation: 9.97 signal2< function<> > fragmented invocation: 15.04 PS3 @ PPU ( Power PC ): Using numConnections = 100000 numCalls = 100 numGroups = 200 rndSeed = 0 fragSpread = 10 Generating random sequence takes: 0.001942 seconds Connecting to unfrag list:< function<> >: 0.060645 seconds Connecting to vector< function<> >: 0.034558 seconds Connecting to unfrag signals2< function<> >: 0.367024 seconds Connecting to unfrag signals1< function<> >: 2.02785 seconds Connecting to test::signals< function<> >: 10.0817 seconds ... ... ... vector< function<> > invocation: 0.695916 signals< function<> > unfragmented invocation: 5.91057 signals2< function<> >unfragmented invocation: 4.90188 list< function<> > unfragmented invocation: 1.03532 test::signals< function<> > invocation: 0.952999 signals< function<> > fragmented invocation: 33.4202 signal2< function<> > fragmented invocation: 47.0125

1 1

Rationale for shared_ptr/array including both ptr to control and ptr to data in class
by Olaf van der Spek 27 Sep '11

27 Sep '11

Hi, I was wondering why shared_ptr/array include both a ptr to the control block and a ptr to the data (ptr) in the class itself. I assume it's for performance reasons, but I didn't find anything about that in the docs. Greetings, Olaf

7 13

[Review:Algorithms] - Small review
by Christian Holmquist 26 Sep '11

26 Sep '11

Hi Marshall and others, I vote Yes to accept the library. Comments follows as I've encountered them in the documentation. - Description and rationale- "Boost.Algorithm is a collection of general purpose algorithms. While Boost contains many libraries of data structures, there is no single library for general purpose algorithms" boost/algorithm has existed for a while, but only the algorithm/string is properly documented (I think). Will boost/algorithm/minmax.hpp boost/algorithm/minmax_element.hpp be incorporated in the documentation? - Future plans- "My goal is to run regular algorithm reviews, similar to the Boost library review process, but with smaller chunks of code." Maybe a short summary on how a submission should work? Email subject tags etc, and what is required by the programmer (docs, code and tests). Since the library is at git (great!), maybe proposals could be done as push requests, or submitters share a link to their github repo or so. Having even a rough outline on the process would be better than none at all :) Do you intend to maintain the library at git? * I think the style linking to the algorithm sections from the main page is not optimal (i.e. Header: 'all.hpp' ). Maybe <Suggestion> Algorithms All Clamp Ordered Search </Suggestion> will read easier. - Reference section * Complexity is missing on each algorithm's page. * I would like if the page for each algorithm contains a small example like in the SGI's STL docs. They can be very trivial, but to me they are always reassuring that I've understood the docs correctly. Example assert(boost::clamp(0, 1, 2) == 1); * Every algorithm in the ordered section, has their iterator typename spelled FI. It would read easier as ForwardIterator. Dito for R -> Range. - General - Is it necessary to have both Range and free Iterator support? all.hpp use #pragma mark, probably not portable. (indeed, MSVC 2005 complains..) all.hpp could use std::begin() if available from std, unless there's a specific reason to always use the Boost version (?) search.hpp checks for a macro B_ALGO_DEBUG. It should read BOOST_ALGORITHM_DEBUG or similar to avoid name clashes. *** What is your evaluation of the design? Straight forward. Only worries a bit on the Range vs Iterator interfaces. It's probably impossible to satisfy everyone without providing both interfaces as has been done though. *** What is your evaluation of the implementation? Looks good to me. Well commented code with easy to read style. I can't comment on the correctness of the search.hpp algorithms though, but the tests are not passing here. *** What is your evaluation of the documentation? Everything needed is in the package, but the examples needs to be linked into the docs. *** What is your evaluation of the potential usefulness of the library? Immediately useful. good potential to evolve further. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 2.5 hours reading the docs, reading the code, running some examples and some of the tests. * Are you knowledgeable about the problem domain? Somewhat. *** Did you try to use the library? With what compiler? Did you have any problems? Visual Studio 2005 with native std (Dinkumware), Windows XP 64, 32 bit target, boost 1.46. All examples starting with int main ( int /*argc*/, char */*argv*/ [] ) { gives a warning on this compiler. search_example.cpp: d:\code\tests\tests\clamp.cpp(23) : warning C4138: '*/' found outside of comment int main ( int /*argc*/, char */*argv*/ [] ) { ^--------------------- add space here between * and / to make MSVC happy. d:\code\boost.algorithm\boost\algorithm\search.hpp(238) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data There are few similar warnings, the warning log is about 75 lines so would be good to get rid of. Running search_example.cpp in debug mode gives assertion failure in MSVC's Debug iterator code. I've not investigated further, all_example.cpp d:\code\tests\tests\clamp.cpp(23) : warning C4138: '*/' found outside of comment warning C4068: unknown pragma clamp_example.cpp error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'std::string' (or there is no acceptable conversion) #include <string> fixes this search_test1.cpp Running 1 test case... Pattern is 8, haysstack is 37 chars long; unknown location(0): fatal error in "test_main_caller( argc, argv )": c:\program files (x86)\microsoft visual studio 8\v c\include\xstring(111) : Assertion failed: string iterator not dereferencable In Release mode, the output is Running 1 test case... Pattern is 8, haysstack is 37 chars long; unknown location(0): fatal error in "test_main_caller( argc, argv )": Invalid parameter detected by C runtime library .\clamp.cpp(71): last checkpoint *** 1 failure detected in test suite "Test Program" d:\code\tests\tests\clamp.cpp(71): last checkpoint *** 1 failure detected in test suite "Test Program" All tests pass except those related to search.hpp. I should point out that I just copied the source from each test into a toy visual studio project, but I've not had any troubles with that before. Sorry for a bit unorganized output of the tests, will take some time this evening to sort it out. Thanks to Marshall and Dave for the library and for managing the review - Christian

2 1

[property_tree] Primitive types for data not supported?
by Boris Schaeling 26 Sep '11

26 Sep '11

I just noticed that Boost.PropertyTree doesn't support primitive types for data (Boost 1.47.0). For example, this doesn't compile: boost::property_tree::basic_ptree<std::string, int> pt, pt2; pt.swap(pt2); The reason is this code in <http://svn.boost.org/svn/boost/trunk/boost/property_tree/detail/ptree_imple…>: template<class K, class D, class C> inline void basic_ptree<K, D, C>::swap(basic_ptree<K, D, C> &rhs) { m_data.swap(rhs.m_data); // Void pointers, no ADL necessary std::swap(m_children, rhs.m_children); } Primitive types like int obviously don't have a member function swap(). Is this an oversight or are primitive types intentionally not supported? Boris

2 2

[Review:Algorithms] Comments about search algorithms
by Phil Endecott 26 Sep '11

26 Sep '11

Dear All, Here are some observations about the proposed search algorithms: - I was confused as to whether the caller must keep the pattern pointed to by the iterators passed to the constructor after the constructor returns. My guess was that once the internal tables were built the pattern would not be needed any more - but that turns out to be wrong. At the least, the docs need to explain this. - The three algorithms have very similar interfaces. The docs could perhaps define a "searcher" concept and explicitly declare these algorithms' classes to be models of that concept. - std::search is similar to the three algorithms' free function versions (congratulations on getting the arguments in the same order!). For completeness, how about adding a searcher class that uses std::search? - A user faced with these three (or four) algorithms will need to choose one. The docs should offer some guidance, e.g. benchmarks or rules-of-thumb, about which to use. - It would sometimes be useful to have a variant of the constructor that takes a const char* pattern. - The tables store ints. For patterns shorter than 256 characters I think that uint8_t would be sufficient, and would reduce the size of a table from 1024 or 2048 bytes to only 256 bytes. Similarly uint16_t or uint32_t could be used for larger patterns. It is not obvious how to implement this, though; perhaps an optional max_pattern_length template parameter, making it the user's responsibility to ensure the supplied pattern is not too long. - The docs describe some methods that are private to the implementation; why? Regards, Phil.

3 5

Introduction : Being a Newbie to the Boost community
by avishek banerjee 26 Sep '11

26 Sep '11

Hi everyone, I am Avishek Banerjee.. I work as a software engineer at Google.. I graduated last year from college. I am quite passionate about coding in c++, but never got the chance earlier to be a community developer. I guess, thats why I am here. I want to be a part of this community and make contributions to the libraries.. I would be keeping track of the posts to see if I can associate myself on some existing project. Besides, it would really help if someone can give me certain pointers on some project(not so immediately important) that I can take up as starter to begin with and familiarize. thank you so much, Avishek -- Avishek Banerjee, Software Engineer, Google-BLR

2 1

Re: [boost] Persistency library
by Lifshitz, Yair 26 Sep '11

26 Sep '11

Message: 10 Date: Sun, 25 Sep 2011 22:53:12 +0200 From: Oliver Kowalke <oliver.kowalke(a)gmx.de> To: boost(a)lists.boost.org Subject: Re: [boost] Persistency library Message-ID: <4E7F94B8.7030706(a)gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > I assume resuming from a checkpoint would also require to restore the > registers, flags, stack (pointer), instruction pointer etc. - I'd like > to know if your lib supports only intel or some other architectures too. > > Oliver Your assumption is correct. However, the actual implementation is done via getcontext()/setcontext(), so it is not hard-wired to a specific hardware architecture. We use assembly only in one case, and that is to avoid a glibc issue. PID is being cached in user-space and therefore isn't correct after restore, and glibc does not provide a simple way to invalidate this. Right now, the library has only been validated on x86-64, but I can of course validate it on other architectures (given the right hardware :)). Yair --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 5

Re: [boost] Persistency library
by Lifshitz, Yair 26 Sep '11

26 Sep '11

Date: Sat, 24 Sep 2011 14:29:44 -0400 From: Dave Abrahams <dave(a)boostpro.com> To: boost(a)lists.boost.org Subject: Re: [boost] Persistency library Message-ID: <m2litdrdyf.fsf(a)pluto.luannocracy.com> Content-Type: text/plain on Sat Sep 24 2011, "Lifshitz, Yair" <yair.lifshitz-AT-intel.com> wrote: > > Hi, > > > > Object-based persistency/serialization libraries often require > > significant modifications to the code. Would Boost consider adding a > > process-level checkpointing library to boost? > > > > This is obviously not easily portable, so I understand this is a long shot. > > If it is relevant, we might contribute a package used by my team that > > support multiple Linux platforms. > Can it, in principle, be ported to other known platforms? Yes, it can be ported. However, the porting requires low-level understanding of the target OS/architecture. While our Linux solution is rather portable, porting can (in theory) be non-trivial and require more than just recompilation on another platform. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 1

configuring the clang toolset
by Eric Niebler 25 Sep '11

25 Sep '11

I'm trying to get bjam and clang to play nice. I have Ubuntu linux running in an VM with boost trunk and the llvm+clang sources also from svn. I've built clang as described here: <http://clang.llvm.org/get_started.html>. I added the following line to my user-config.jam: using clang : : /home/eric/build/Debug+Asserts/bin/clang++ ; Now when I try to build, say, the Foreach tests, I get: In file included from cstr_byref.cpp:11: In file included from ../../../boost/test/minimal.hpp:37: In file included from ../../../boost/test/impl/execution_monitor.ipp:170: In file included from /usr/include/errno.h:36: In file included from /usr/include/bits/errno.h:25: /usr/include/linux/errno.h:4:10: fatal error: 'asm/errno.h' file not found #include <asm/errno.h> ^ 1 error generated. "/home/eric/build/Debug+Asserts/bin/clang++" -c -x c++ -O0 -g -fno-inline -Wall -g -fPIC -DBOOST_ALL_NO_LIB=1 -I"../../.." -o "../../../bin.v2/libs/foreach/test/cstr_byref.test/clang-linux-3.0/debug/cstr_byref.o" "cstr_byref.cpp" What have I done wrong? -- Eric Niebler BoostPro Computing http://www.boostpro.com

6 6

Re: [boost] Persistency library
by Lifshitz, Yair 25 Sep '11

25 Sep '11

From: Edward Diener <eldiener(a)tropicsoft.com> > On 9/24/2011 10:31 AM, Lifshitz, Yair wrote: > > Hi, > > > > Object-based persistency/serialization libraries often require significant modifications to the code. > > Would Boost consider adding a process-level checkpointing library to boost? > Why not explain what you mean by a "process-level checkpointing library" > and then others can comment if they might find it useful ? Process-level checkpointing is an approach where an entire process' memory image is dumped in binary format. The checkpointing library does not require any understanding of the saved application - it works by traversing the entire memory image and directly dumping that to disk. On Linux for example, this can be done by traversing all memory segments described in /proc/self/maps. This approach is highly robust, and generally considered good for very large applications where serialization is a challenge. Some examples can be seen here - http://checkpointing.org/ - though we had little luck with most of them when starting to work on persistency (~6 years ago). --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 1

Re: [boost] [Review:Algorithms] About a static clamp function
by Ahmed Charles 25 Sep '11

25 Sep '11

C++11 constexpr would handle the function case while also working for user defined types. This suggests that the template version is less generic. My phone doesn't allow bottom posting. :( From: Vicente J. Botet Escriba Sent: Sunday, September 25, 2011 7:13 AM To: boost(a)lists.boost.org Subject: [boost] [Review:Algorithms] About a static clamp function Hi, Sometimes the bound values are know at compile time. Could we ensure that the compiler could optimize the following code auto res = clamp(val, 1, 100); If this is not the case, I was wondering if it is worth adding a static clamp function that has its bounds defined as template parameters. auto res = static_clamp<1,100>(val); Best, Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[Review:Algorithms] About a static clamp function
by Vicente J. Botet Escriba 25 Sep '11

25 Sep '11

Hi, Sometimes the bound values are know at compile time. Could we ensure that the compiler could optimize the following code auto res = clamp(val, 1, 100); If this is not the case, I was wondering if it is worth adding a static clamp function that has its bounds defined as template parameters. auto res = static_clamp<1,100>(val); Best, Vicente

1 0

[system] Boost.Timer replacement
by Beman Dawes 25 Sep '11

25 Sep '11

"The best is the enemy of the good." Voltaire's famous bon mot applies to a replacement for Boost.Timer. I've had a "good", although not "best", replacement ready since circa 2006. It has always been set aside waiting for something better. The data-time, std::chrono, boost::chrono, boost::stopwatch, and probably others, were all candidates. I'm tired of waiting. http://beman.github.com/timer/ documents a useful replacement for Boost.Timer. The full library has been in the sandbox for years, but current development is on GitHub. See https://github.com/Beman/timer I'd like to move the header into boost/system/pending or boost/system/detail, and the rest into the appropriate libs/system subdirectories. The library will be proposed for a full review, or a mini-review if enough other Boost libraries start using it. If Endian gets accepted, for example, it certainly needs timing benchmarks. Comments? --Beman

7 13

[preprocessor] PP_CAT with symbols
by lcaminiti 25 Sep '11

25 Sep '11

Hello all, I just want to confirm that the following: BOOST_PP_CAT(old_size =, =) correctly (and always) expands to: old_size == I tested it on MSVC and GCC and it works. Plus from GCC documentation says about ##: Usually both will be identifiers, or one will be an identifier and the other a preprocessing number. When pasted, they make a longer identifier. This isn't the only valid case. It is also possible to concatenate two numbers (or a number and a name, such as 1.5 and e3) into a number. Also, multi-character operators such as += can be formed by token pasting. http://gcc.gnu.org/onlinedocs/gcc-3.2.3/cpp/Concatenation.html I am asking because ## has some limitation (x ## = is not valid, etc) so I want to confirm my understanding is correct. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-preprocessor-PP-CAT-with-symbols-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

Overload resolution speed
by Mathias Gaunard 25 Sep '11

25 Sep '11

As part of the Boost.SIMD effort, another library was developed, Boost.Dispatch, which relies heavily on overload resolution. Before submitting this library for review, however, I did some compile-time benchmarking, and it's not looking very good. I'm therefore asking the Boost community if 1) this is expected, 2) if there is a workaround to this problem and 3) if compilers should be made to deal with this better. Boost.Dispatch essentially overloads a single free function, with, as arguments, a tag identifying the function followed by tags identifying properties/categories of the arguments (in an attempt to make a transparent tag dispatching system). The scripts from the link below [1] (the shell script is POSIX/GCC-only but should be easily adaptable) performs two tests: - Resolving a call with 1,000 function tags, overloaded 10 times each, everything implemented by overloading the same function as described above, - Resolving a call with 1,000 function tags, overloaded 10 times each, but with each function tag using a different functon. It takes 30s in the first case, 160ms in the second one. Unfortunately, the second solution is very restrictive and doesn't play very nice with generic programming. C++ apparently lacks a mechanism to define overloadable free functions with template parameters in their name. Back to the benchmark, making the number of functions vary show an apparent exponential increase in compile time. It's reasonably fast for 100 functions, but not at all for 1,000. On the other hand, changing the depth of the inheritance tree used for the category tags doesn't seem to affect it much. Any suggestions? [1] http://dl.dropbox.com/u/26902324/dispatching_bench.tar.gz

6 14

Persistency library
by Lifshitz, Yair 24 Sep '11

24 Sep '11

Hi, Object-based persistency/serialization libraries often require significant modifications to the code. Would Boost consider adding a process-level checkpointing library to boost? This is obviously not easily portable, so I understand this is a long shot. If it is relevant, we might contribute a package used by my team that support multiple Linux platforms. Thanks, Yair --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

3 2

Re: [boost] [Review:Algorithms] is_ordered name
by Brent Spillner 24 Sep '11

24 Sep '11

On Sat, 24 Sep 2011 09:34:59 joaquin wrote: >>Isn't this the same as the C++11 is_sorted_until? > >Yes! C+11 had is_sorted_until and is_sorted (equivalent to is_sorted_until(first,last)==last). I think the names here should be the same for >consistency reasons, and probably the functions should be just aliases to the c++11 ones where applicable. With the RV convention change that I proposed on github (always point before the first element that is out-of-order with respect to its predecessor, rather than the first that is out-of-order with respect to its successor), it would be exactly the same, so I think we may be stuck with this name, even though I agree that it sounds like it should return a bool. If we were starting from scratch my first impulse would be end_of_ordered_prefix(), but that too seems wordier than the ideal.

5 8

XInt library primality test
by Jorge Lodos Vigil 24 Sep '11

24 Sep '11

Hi The recently reviewed (and rejected) XInt library includes prime number functionality. To evaluate primality it uses Miller-Rabin test iterating 5 times. For "small" primes this is way insufficient, while for "large" primes it is more than needed. This last case have an important speed impact for numbers with more than 1024 bits . In its current state the library cannot correctly evaluate primality for numbers with less than 400 bits. You may consult "Damgaard, Landrock, Pomerance: Average case error estimates for the strong probable prime test. Math. Comp. 61 (1993)". Additionally, it seems that efficiency may be gained using boost/math/special_functions/prime.hpp instead of calculating the first 2000 primes. If there will be any further work on this library I'm willing to provide patches and tests. Thank you. Best regards Jorge

2 3