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

[Review:Algorithms] is_ordered behaviour for singleton input, and name
by Phil Endecott 24 Sep '11

24 Sep '11

Dear All, The docs for the proposed is_ordered say: The function is_ordered(sequence, predicate) returns the point in the sequence where the predicate does not hold. It does that by comparing adjacent pairs of elements in the sequence to see if the predicate is satisfied. If all adjacent pairs satisfy the predicate, then it will return one past the last element of the sequence. OK. If the sequence has less than two elements, it returns the last element of the sequence. In other words, sequences of length zero and one are considered to be ordered - using any possible criteria. Shouldn't that say "it returns one past the last element"? Also, regarding the name: I would expect any "is_something" function to return a boolean. Since this returns an iterator I would have called it something like find_disorder. (There is a good chance that an iterator is convertible to bool, so one could mistakenly write "if (is_ordered(begin,end)) { ... }".) Regards, Phil.

7 10

Boost.Algorithms Review Begins today
by Dave Abrahams 24 Sep '11

24 Sep '11

The review period for the proposed Boost.Algorithms library, by Marshall Clow, begins today (September 22) and runs through Oct 1. I'm pleased to act as review manager. ,----[ Important Notes ] | - Please do not post your review or discussion as a reply to this | message. | - Please begin your review's subject line with "[Review:Algorithms]" | - Please feel free to note any individual issues in the GitHub issue | tracker and make reference to them from your review. | - Please see below for *further* important notes `---- You can find the library at https://github.com/mclow/Boost.Algorithm. If you don't want to use Git, you can get a .zip or tarball snapshot at https://github.com/mclow/Boost.Algorithm/archives/master Description =========== The Boost Algorithms library is a work in progress; it is not meant to be a complete set of general purpose algorithms for C++ programming; but rather a small collection of useful algorithms, and a structure for adding more over time. The algorithms here fall into three basic categories: 1. Searching - Boyer-Moore Search - Boyer-Moore-Horspool Search - Knuth-Morris-Pratt search 2. Sequence properties - Tests to see if a sequence is ordered - Tests for the elements of a sequence 3. Miscellaneous - Constrain a value between two 'boundaries' (minmax) Potential Interactions with Existing Boost Libraries ==================================================== This submission potentially interacts with all of the following existing Boost libraries: * foreach - http://boost.org/libs/foreach * minmax - http://boost.org/libs/algorithm/minmax * range - http://boost.org/libs/range * string_algo - http://boost.org/libs/algorithm/string_algo Reviewers should consider these potential interactions. What to include in Review Comments ================================== - Keep your criticism constructive. Constructive criticism usually comes with specific suggestions for improvement. - If you identify problems along the way, please note if they are minor, serious, or showstoppers. - Please *do* vote on whether the library should be accepted. Everyone who takes the time to look at the library is qualified to vote, and every vote is valuable. - Other questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

4 5

Re: [boost] [contract] extra type requirements for contracts
by Brent Spillner 23 Sep '11

23 Sep '11

On Fri, 23 Sep 2011 06:45:10 lcaminiti wrote: >In this case T = val has an operator== which is private. This causes both >the methods (1) using dummy::operator== and (2) the traits requirement >can_call_equal<val> to fail :( Exactly (at least for the default implementation of can_call_equal<>). This is in general the behavior you want (can't accidentally apply a generic operator== to a type with special semantics for which that wouldn't make sense), but in a contract-checking context I think most users would rather at least have the option to silently ignore the untestable constraint. >Ideally, can_call_equal<val>::value will return false instead of generating >a compiler-error when val::operator== is private or protected. A part from >such an (impossible?) improvement to can_call_equal, I have no solution for Hardly impossible... If you really want the constraint to be tested, you obviously have to friend the constraint checker class (which may not always be permissible.) If you're content to ignore it, just specialize can_call_equal<perverse_type> to make the nested ::value false. Note that some user intervention is still required (adding a friend to perverse_type, or adding a specialization of can_call_equal<>), so your contracts won't be silently compiling to no-ops, but the library user has full control with minimal effort. As far as I know, there's no way to offer both options without naming the test predicate something other than operator==. Along the same lines, I recognize that test_equality() isn't the only operation required or supported by the contract mechanism (although I'll bet it's the most common.) However, I still believe that a few test_equality(), test_not_equal(), test_less_than_or_equal(), operator_add(), etc. stubs, and perhaps a HAS_MEMBER_FUNC() macro to generate other custom stubs, would enable more readable code than a postN() method for each constraint. On the other hand, there is something to be said for straightforward mechanical generation, and if you already create 4 other member functions per constraint it's probably not a big deal. >What do you think? Honestly, I think it's a great library, and I hope I can be disciplined enough to make a habit of using it.

1 0

Cross-compiling: linux host, qnx target. Perhaps it's a bug?
by Félix Robles 23 Sep '11

23 Sep '11

Hi, I've got KUbuntu 64bits installed: Linux findeton-PC 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux I want to compile boost using qcc toolset (qcc versión 4.4.2) for a qnx target-os from a linux host, and I'm unable to compile python,serialization and test libs (the rest of them are fine). This is how I do it: $ ./bootstrap.sh And it goes fine, it uses the gcc compiler, not qcc, because I want to execute b2 in my linux machine. Then I use the following command: $ ./b2 --build-dir=/home/findeton/boost_1_47_0/ toolset=qcc target-os=qnx --build-type=complete -a And this is the kind of output I get: qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/numeric.o In file included from ./boost/integer_fwd.hpp:17, from ./boost/integer.hpp:18, from ./boost/function/function_base.hpp:21, from ./boost/function/detail/prologue.hpp:17, from ./boost/function/function_template.hpp:13, from ./boost/function/detail/maybe_include.hpp:13, from ./boost/function/function0.hpp:11, from ./boost/python/errors.hpp:13, from ./boost/python/handle.hpp:11, from ./boost/python/converter/arg_to_python_base.hpp:7, from ./boost/python/converter/arg_to_python.hpp:14, from ./boost/python/call.hpp:15, from ./boost/python/object_core.hpp:14, from ./boost/python/object.hpp:9, from ./boost/python/tuple.hpp:10, from ./boost/python/numeric.hpp:10, from libs/python/src/numeric.cpp:6: ./boost/cstdint.hpp:74: error: 'intleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:75: error: 'intfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:76: error: 'uintleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:77: error: 'uintfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:79: error: 'intleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:80: error: 'intfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:81: error: 'uintleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:82: error: 'uintfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:84: error: 'intleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:85: error: 'intfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:86: error: 'uintleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:87: error: 'uintfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:91: error: 'intleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:92: error: 'intfast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:93: error: 'uintleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:94: error: 'uintfast64_t' in namespace '::' does not name a type cc: /opt/qnx650/host/linux/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.4.2/cc1plus error 1 "QCC" -Wc,-ftemplate-depth-128 -gstabs+ -O0 -Wc,-fno-inline -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_STATIC_LIB -I"." -I"/usr/include/python2.7" -c -o "/home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/numeric.o" "libs/python/src/numeric.cpp" ...failed qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/numeric.o... qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/list.o In file included from ./boost/integer_fwd.hpp:17, from ./boost/integer.hpp:18, from ./boost/function/function_base.hpp:21, from ./boost/function/detail/prologue.hpp:17, from ./boost/function/function_template.hpp:13, from ./boost/function/detail/maybe_include.hpp:13, from ./boost/function/function0.hpp:11, from ./boost/python/errors.hpp:13, from ./boost/python/handle.hpp:11, from ./boost/python/converter/arg_to_python_base.hpp:7, from ./boost/python/converter/arg_to_python.hpp:14, from ./boost/python/call.hpp:15, from ./boost/python/object_core.hpp:14, from ./boost/python/object.hpp:9, from ./boost/python/list.hpp:10, from libs/python/src/list.cpp:5: ./boost/cstdint.hpp:74: error: 'intleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:75: error: 'intfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:76: error: 'uintleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:77: error: 'uintfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:79: error: 'intleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:80: error: 'intfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:81: error: 'uintleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:82: error: 'uintfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:84: error: 'intleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:85: error: 'intfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:86: error: 'uintleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:87: error: 'uintfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:91: error: 'intleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:92: error: 'intfast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:93: error: 'uintleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:94: error: 'uintfast64_t' in namespace '::' does not name a type cc: /opt/qnx650/host/linux/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.4.2/cc1plus error 1 "QCC" -Wc,-ftemplate-depth-128 -gstabs+ -O0 -Wc,-fno-inline -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_STATIC_LIB -I"." -I"/usr/include/python2.7" -c -o "/home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/list.o" "libs/python/src/list.cpp" ...failed qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/list.o... [ And after some of those, then I get some of this kind : ] qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_iarchive.o In file included from ./boost/serialization/extended_type_info_typeid.hpp:34, from ./boost/archive/detail/iserializer.hpp:47, from ./boost/archive/detail/interface_iarchive.hpp:22, from ./boost/archive/detail/common_iarchive.hpp:23, from ./boost/archive/basic_binary_iarchive.hpp:31, from ./boost/archive/binary_iarchive_impl.hpp:22, from ./boost/archive/binary_iarchive.hpp:20, from libs/serialization/src/binary_iarchive.cpp:14: ./boost/serialization/factory.hpp:28: error: '::va_list' has not been declared cc: /opt/qnx650/host/linux/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.4.2/cc1plus error 1 "QCC" -Wc,-ftemplate-depth-128 -O3 -Wc,-finline-functions -Wc,-Wno-inline -shared -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DNDEBUG -I"." -c -o "/home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_iarchive.o" "libs/serialization/src/binary_iarchive.cpp" ...failed qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_iarchive.o... qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_oarchive.o In file included from ./boost/serialization/extended_type_info_typeid.hpp:34, from ./boost/archive/detail/oserializer.hpp:38, from ./boost/archive/detail/interface_oarchive.hpp:23, from ./boost/archive/detail/common_oarchive.hpp:22, from ./boost/archive/basic_binary_oarchive.hpp:34, from ./boost/archive/binary_oarchive_impl.hpp:23, from ./boost/archive/binary_oarchive.hpp:21, from libs/serialization/src/binary_oarchive.cpp:14: ./boost/serialization/factory.hpp:28: error: '::va_list' has not been declared

1 0

FW: Boost.Units problem with user-defined units and dimensionless quantities
by Pieter 23 Sep '11

23 Sep '11

Thanks Steven. I now see the problem arises from using si::dimensionless with nautical::length (The error message I get depends on the included header files but is related to the operator+ (when absolute.hpp is included) or the lack of a specialized add_typeof_helper in case that for example si/area.hpp is included). I guess my misconception was that I silently assumed that the 'dimensionless' type was acting as a normal double, reinforced by the fact that the line with the pure multiplication (nm1 = d*nm2;) does compile OK. The documentation says that " Because dimensionless quantities have no associated units, they behave as normal scalars, and allow implicit conversion to and from the underlying value type or types that are convertible to/from that value type". I intended to use my TDimless type as a 'generic' type for dimensionless quantities, but I now understand these quantities still need to be related to a 'system' and every system would need its own dimensionless type, even though there is no relation to the base units that define the system. Would I need to explicitly define conversions (e.g. BOOST_UNITS_DEFINE_CONVERSION_FACTOR(nautical::dimensionless, si::dimensionless, double, 1.0); or is there a more elegant way to use dimensionless quantities across systems? Thanks again, Pieter -----Original Message----- From: Steven Watanabe [mailto:watanabesj@gmail.com] Sent: Friday, September 23, 2011 17:06 To: boost(a)lists.boost.org Subject: Re: [boost] Boost.Units problem with user-defined units and dimensionless quantities AMDG On 09/21/2011 12:29 PM, Pieter wrote: > I am having some trouble using user-defined units and dimensionless once. > Consider the example (taken straight from the documentation) that > defines nautical miles (added at the bottom). > > When I do the following on VS2010: > > typedef quantity<boost::units::nautical::length> TDistanceInNMI; > typedef quantity<dimensionless> TDimLess; > > TDistanceInNMI nm1,nm2,nm3; > TDimLess d; > > nm1 = nm2 + nm3; // compiles OK > nm1 = d*nm2; // compiles OK > nm1 = nm2 + d*nm3; // does not compile, claims there is no operator+ > defined > > I suppose I might have to add a dimensionless type to the 'nautical' > system, or have some misconceptions on how this should work. I tried > adding the following line (mimicking some of the internal stuff) but > that did not due to trick: > > typedef unit<dimensionless_type,system> dimensionless; > I'm surprised that this doesn't work. It seems to work when I try it. The attached compiles with MSVC 2010. > Could anyone tell me whether there is there anything I need to define > to make this work? > In Christ, Steven Watanabe

1 0

Re: [boost] More tests running with Boost.Test than registered
by Jon Black 23 Sep '11

23 Sep '11

On 23-9-2011 7:42, boost-request(a)lists.boost.org wrote: >> So I put a print statement in the test in each DLL and ran it again, and > You could have used --log_level=all to see what is being tested Thanks. That's much nicer. >> > The project for MyDll1 depends on the other projects. That can't be a >> > coincidence! I'm confused though, why is the console_test_runner >> > executing tests in other DLL's when I've only specified MyDll1 on the >> > command line? Each DLL has its own unit_test_init() function declared in > You probably are using automatically registered test units. These are registered > in single shared test framework as soon as you load these libraries and they are > loaded in memory as they are dependencies of the library you want to test. Thus > you end up with all test units in all loaded libraries. Yes, they are automatically registered tests. In the init_unit_test() method I also give the master test suite a unique name for each DLL. If there is on shared test framework, does this mean I'm just renaming the same master test suite each time? > You can specify the test case belonging to the Mydll1 using --run=TestMyDll1 and > you'll get only 1 test case being executed. Perfect! I've used run_test to limit to a test suite which I've auto registered per project. > I think this is correct behavior overall. What you got here is implicit > dependency between test units you can't be sure TestMyDll1 working until you > tested all of it's dependent test cases which are in this case reside in > corresponding libraries. Agreed. I'm running it as a post build step. Adding the run_test option to limit what is executed solves my problem. Thanks. > Gennadiy

2 1

Boost.Units problem with user-defined units and dimensionless quantities
by Pieter 23 Sep '11

23 Sep '11

LS, I am having some trouble using user-defined units and dimensionless once. Consider the example (taken straight from the documentation) that defines nautical miles (added at the bottom). When I do the following on VS2010: typedef quantity<boost::units::nautical::length> TDistanceInNMI; typedef quantity<dimensionless> TDimLess; TDistanceInNMI nm1,nm2,nm3; TDimLess d; nm1 = nm2 + nm3; // compiles OK nm1 = d*nm2; // compiles OK nm1 = nm2 + d*nm3; // does not compile, claims there is no operator+ defined I suppose I might have to add a dimensionless type to the 'nautical' system, or have some misconceptions on how this should work. I tried adding the following line (mimicking some of the internal stuff) but that did not due to trick: typedef unit<dimensionless_type,system> dimensionless; Could anyone tell me whether there is there anything I need to define to make this work? Any help is appreciated, Many thanks, Pieter --- The example --- namespace boost { namespace units { namespace nautical { struct length_base_unit : base_unit<length_base_unit, length_dimension, 1000> { static std::string name() { return "nautical mile"; } static std::string symbol() { return "nmi"; } }; typedef make_system<length_base_unit>::type system; typedef unit<length_dimension,system> length; // 'typedef unit<dimensionless_type,system> dimensionless'; static const length mile,miles; } } } // helper for conversions between nautical length and si length BOOST_UNITS_DEFINE_CONVERSION_FACTOR(boost::units::nautical::length_base_uni t, boost::units::si::meter_base_unit, double, 1.852e3); Pieter

2 1

Re: [boost] [contract] extra type requirements for contracts
by Brent Spillner 23 Sep '11

23 Sep '11

On Thu, 22 Sep 2011 08:03:09 lcaminiti wrote: >For example, the following code asserts back() == value only when >can_call_equal<T>::value is true. However, is there a better way to do this >that does not require the extra function call to post1? Unless I'm missing something, you should be able to replace the post1() calls with assert(boost::can_call_equal<T>::value && std::clog << "actual assertion\n" == std::clog && back() == value || std::clog << "trivial assertion\n" == std::clog);

3 5

structured exceptions for UNIXs -- the hard way
by Peter Foelsche 23 Sep '11

23 Sep '11

On UNIXs one does not get around signals. They are used for everything. E.g. using memory mapped io is impossible without dealing with signals. E.g. somebody may edit the file which is mapped into your process thereby truncating it and invalidating some part of the memory. Or one may be writing into a sparse file via memory mapped io and the result of "out of disk space" is also a signal. Then there are such sick solutions as setjmp()/longjmp(). Could they be packed into some class to enable some kind of structured exceptions on UNIXs? #include <setjmp.h> #include <vector> static std::vector<jmp_buf> s_sStack; static void signalHandler(void) { if (s_sStack.size()) { jmp_buf s = s_sStack.back(); s_sStack.pop_back(); longjmp(s); } } struct CSetLongJmp { CSetLongJmp(void) { s_sStack.push_back(jmp_buf()); if (setjmp(s_sStack.back())) throw "something"; } ~CSetLongJmp(void) { s_sStack.pop_back(); } }; This class would need to be part of anything which needs to be protected against signals: std::string s; CSetLongJmp s1; useString(s); Peter Foelsche

9 12

Re: [boost] Bugs in regression/library_status.cpp on Windows
by Robert Kawulak 22 Sep '11

22 Sep '11

Hi, Since there was no response to my emails with patches for two months now and the code is still broken as it was, should the tool be considered abandoned? If so, would it be acceptable if I apply the patches by myself? Best regards, Robert > -----Original Message----- > From: Robert Kawulak [mailto:Robert.Kawulak@gmail.com] > Sent: Monday, July 25, 2011 12:18 AM > To: 'boost(a)lists.boost.org' > Subject: RE: Bugs in regression/library_status.cpp on Windows > > Hi, > > Could anybody please apply that patch or suggest what can I do (or whom > to contact directly) to get this fixed? BTW, I wonder how it's possible > that most of the bugs were introduced in one commit half a year ago and > nobody even noticed - it would suffice to run this app on any platform > to get obvious errors while on Windows it wouldn't even compile. Am I > really the only person using this tool? :P > > I've also found another minor problems: > - when building it, "$(BOOST_ROOT)\tools\regression\build\bin" > directory is created but it's not marked with "ignore" in SVN; > - char_xlate functor only translates '/' character in URLs while on > Windows the character used is '\' (and it also causes problems in some > browsers). The solution is very simple - add "|| c = '\\'" in line 75. > > I'm attaching a patch file combining the previous fixes and the '\' > translation. > > Best regards, > Robert > > > > > -----Original Message----- > > From: Robert Kawulak [mailto:Robert.Kawulak@gmail.com] > > Sent: Saturday, July 09, 2011 11:35 PM > > To: 'boost(a)lists.boost.org' > > Cc: 'bdawes(a)acm.org'; 'blelbach(a)cct.lsu.edu' > > Subject: Bugs in regression/library_status.cpp on Windows > > > > Hello, > > > > I've stumbled upon several bugs in > > tools/regression/src/library_status.cpp when compiling on Windows > with > > gcc 4.5 and msvc 10.0. I'm attaching a patch file with all necessary > > fixes. The bugs are: > > > > - using path::native() instead of path::string() - the former is > > wstring on Windows, > > - calling path::string() twice to obtain begin() and end() iterators > - > > on Windows path::string() returns a temporary, so the iterators point > > to different objects, > > - using whole path for each node in build_node_tree() instead of only > > the directory name, > > - using whole path instead of only the test name in do_table_body(), > > - the link to links file is relative to test directory, not to the > > results output directory, > > - generation of closing "</a>" without opening "<a>". > > > > Best regards, > > Robert

1 0

More tests running with Boost.Test than registered
by Jon Black 22 Sep '11

22 Sep '11

I have a large solution in Visual Studio (100+) projects, of which most are dll's. The test code is in the DLL's and the tests are run using the provided console_test_runner. At the moment, each DLL has a single passing test. However, when I run the console_test_runner on a single dll, the output indicates that there are more tests. For example: D:\Projects\MyProject\console_test_runner.exe --test MyDll1.dll Running 5 test cases... *** No errors detected So I put a print statement in the test in each DLL and ran it again, and here's what happened: D:\Projects\MyProject\console_test_runner.exe --test MyDll1.dll Running 5 test cases... TestMyDll5 TestMyDll4 TestMyDll3 TestMyDll2 TestMyDll1 *** No errors detected The project for MyDll1 depends on the other projects. That can't be a coincidence! I'm confused though, why is the console_test_runner executing tests in other DLL's when I've only specified MyDll1 on the command line? Each DLL has its own unit_test_init() function declared in the pre-compiled header, so I'm really lost on what is happening here. Is it possible that the other dll tests are getting registered as well?

2 1

preprocessor programming challenge
by Eric Niebler 22 Sep '11

22 Sep '11

I have a PP interface such as the following: #define MACRO(x) \ typedef x type; \ typedef x::nested nested; struct D { struct nested {}; }; It is intended to be used as follows: struct foo { MACRO(D) }; Now the problem comes when x is a dependent type, because "typedef x::nested" needs a "typename" in there. I would like to additionally support the following syntax (or something like it): template<class DD> struct bar { MACRO(typename DD) }; The above doesn't work as is because "typedef typename DD type;" is ill-formed (although msvc eats it). Constraints are i/ the interface must be backwards compatible to avoid breaking existing clients, ii/ it should be done with PP only. No templates should be instantiated here, and iii/ it should be standard C++03. No PP variadics. Is this possible? I think not, but my PP-foo is weak. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 2

Name and Namespace for Potential Boost Extended Floating-Point
by Christopher Kormanyos 22 Sep '11

22 Sep '11

Hello, We are seeking a good name for a potential boost extended precision floating-point library. This is a multiple precision floating-point type which *behaves* well in C++. The original thread announcing this potential library is here: http://lists.boost.org/Archives/boost/2011/06/182334.php Some very helpful boosters are assisting me with the preparation of this potential library. We've still got a lot to do, but are making good progress. In order to continue, we need a good name for a potential boost multiple-precision floating-point type. For the multiple-precision real type we have names like: * multiprecision_real * mp_real * extended_float_tOur current favorite is the second:mp_real. For namespaces, we have: 1. boost::mp::mp_real 2. boost::multiprecision::mp_real 3. boost::multiple_precision::mp_realOur current favorite namespace is number 2: boost::multiprecision. This new data type behaves like a drop-in replacement for a POD. It also has a collection of transcendental functions and a complex data type. So we are proposing: namespace boost { namespace multiprecision { class mp_real { ... }; // The real data type. class mp_complex { ... }; // The complex data type. mp_real sin(const mp_real&); // The sin function for the real data type. class mp_uint { }; // A potential future multiple-precision unsigned integer type. class mp_int { }; // A potential future multiple-precision signed integer type. } } We would appreciate comments (negative or positive) and/or alternative suggestions for names. Thank you. Sincerely, Chris.

15 56

[type_traits] has_member_function_callable_with
by Ion Gaztañaga 21 Sep '11

21 Sep '11

Hi to all, Trying to port C++11 code (allocator_traits) to C++03 (without decltype support), I needed to check at compile time if a member function can be called with some given parameters. Typical solutions I found on the net were based on specific signatures, say: const bool value = HAS_MEMBER_FUNCTION_FUNCNAME_WITH_SIGNATURE(MyClass, (int, char*)); However, it is not feasible to know the exact signature as I want to deal with conversions, const references, etc. Luckily, I found a very interesting explanation in Proto documentation: http://www.boost.org/doc/libs/1_47_0/doc/html/proto/appendices.html#boost_p… Based on this, I've tried to write my solution and I'd like to share it here with type traits experts, in case someone knows a better solution (see attached example). I know I don't take into account many issues for a truly generic utility (const member functions, etc.) but please let me know if you find this example interesting. Best, Ion

4 6

[BGL] container_gen
by Cromwell Enage 21 Sep '11

21 Sep '11

Hi, all. After a bit of a programming hiatus, I've managed to follow up on our container_gen discussion we had last May, archived here: <http://article.gmane.org/gmane.comp.lib.boost.devel/219238> I've created a branch in the sandbox called utility-container_gen that places the metafunction in Boost.Utility, changes detail::is_random_access to is_random_access_selector, provides an is_unique_associative_selector metafunction, and changes adjacency_list and parallel_edge_traits to use said utilities. Plus, there's Quickbook documentation. I've tested a few example programs in the BGL to make sure they still work, but I feel that's far from being thorough. No selectors for Boost.Intrusive have been implemented, yet. Feedback welcome! Cromwell D. Enage

2 2

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

21 Sep '11

> Comments are always welcome :) Hi Lorenzo, The number of examples is impressive. It is a pleasure to observe your library growing at this pace. I would like to suggest two things. I could not see from the examples, if the library is capable of supporting "function try blocks" in constructor and destructor definitions. This is what I mean. http://msdn.microsoft.com/en-us/library/e9etx778%28v=vs.71%29.aspx http://www.gotw.ca/gotw/066.htm Second, I have seen #ifndef pragmas in some of the examples, e.g., in the body of function myadvance_dispatch you have: { #ifndef CONTRACT_CONFIG_NO_LOOP_VARIANTS Distance n_max = n; #endif CONTRACT_LOOP( while(n++) ) { CONTRACT_LOOP_VARIANT( const( n_max, n ) n_max - n ) --i; } } I am not sure if the necessity to use this conditional code would occur often, but if so, perhaps the code would be slightly more clear if instead the conditional code would be wrapped in an additional macro, like MFC did with DEBUG_ONLY macro: { CONTRACT_CONFIG_LOOP_VARIANT_ONLY( Distance n_max = n ); CONTRACT_LOOP( while(n++) ) { CONTRACT_LOOP_VARIANT( const( n_max, n ) n_max - n ) --i; } } That is, macro CONTRACT_CONFIG_LOOP_VARIANT_ONLY is defined as: #ifndef CONTRACT_CONFIG_NO_LOOP_VARIANTS #define CONTRACT_CONFIG_LOOP_VARIANT_ONLY(ARG) ARG #else #define CONTRACT_CONFIG_LOOP_VARIANT_ONLY(ARG) #endif Although I am not sure if a similar trick would be possible with the definition like: CONTRACT_FUNCTION( template( typename T ) requires( Addable<T> #ifndef CONTRACT_CONFIG_NO_POSTCONDITIONS // Equality only for postconditions. , boost::EqualityComparable<T> #endif ) (T) (add) ( (T) x, (T) y ) postcondition( auto result = return, result == x + y ) ) { return x + y; } Regards, &rzej

3 2

[exception] get_error_info with dynamic libraries
by Pavel Lebedev 19 Sep '11

19 Sep '11

Hi, I believe there is a problem with boost::get_error_info when used to retrieve error info objects added to exceptions in a module (exe/dll) different from the one making the call to this function under MSVC++ 2010 SP1. The problem appears to be introduced in SVN revision 68792 with a fix for ticket #5178 that changed struct boost::exception_detail::type_info_ from storing a reference to type info to a pointer in member type_. There's an assertion in function boost::exception_detail::error_info_impl_container::get that checks these members for equality which now does pointer comparison instead of calling std::type_info::operator== (for the case of enabled RTTI). This fails when used on error info added in the different module from the one trying to access it because each module gets its own copy of std::type_info object for the same type with different addresses, even though std::type_info::operator= does string comparison of class names and would have returned true, as it did before this change. Other compilers/platforms that don't provide process-unique type info objects are most likely affected too. The following patch appears to fix this problem for me by reverting to compiler-provided way of comparing type info objects. Index: info.hpp =================================================================== --- info.hpp (revision 74465) +++ info.hpp (working copy) @@ -97,7 +97,7 @@ { shared_ptr<error_info_base> const & p = i->second; #ifndef BOOST_NO_RTTI - BOOST_ASSERT( BOOST_EXCEPTION_DYNAMIC_TYPEID(*p).type_==ti.type_ ); + BOOST_ASSERT( *BOOST_EXCEPTION_DYNAMIC_TYPEID(*p).type_==*ti.type_ ); #endif return p; } Is this fix correct? Thanks in advance. Pavel Lebedev

2 2

[utility] rvalue support in value_initialized
by "Claas H. Köhler" 19 Sep '11

19 Sep '11

Hi everybody! Recently I encountered a problem using the std:::unique_ptr within boost::spirit. The reason is apparently that value_initialized does not support rvalue assignment. Are there any plans to implement move semantics into value_initialized? Mainly I would be interested in making something like this work: std::unique_ptr<T> a= boost::get( boost::value_initialized< std::unique_ptr<T> >() ); Currently this fails due to the fact, that unique_ptr can be moved but not copied. Regards Claas

8 9

[move] [optional] Move constructors support
by Antony Polukhin 19 Sep '11

19 Sep '11

There is a feature request https://svn.boost.org/trac/boost/ticket/1841 with some patch. I'm just curious, when will be it applied? Shall this patch be applied, or some integration with Boost.Move must be done instead? Best regards, Antony Polukhin

1 0

Template metaprogramming libraries
by Ábel Sinkovics 19 Sep '11

19 Sep '11

Hi Boost developers, I am a PhD student at Eotvos Lorand University, Budapest. My research area covers C++ template metaprogramming. As part of my research I have developed four template metaprogram libraries based on Boost.MPL. On my conference appearances I was encouraged to submit my libraries to the Boost sandbox. Here is a short summary of the libraries: metaparse A tool for building embedded DSLs in C++. This is a compile-time parser generator library. Using it one can build parsers that take compile-time strings as input text and parse them as part of the C++ compilation process. One can think of it as using Spirit at compile-time. safe_printf Typesafe printf implementation using metaparse. It provides printf (sprintf, fprintf) functions taking the format string as a template argument and type-checking it at compile-time. It is a practical application of the metaparse library. metamonad Monad implementation for C++ template metaprograms. The library provides a framework for using monads in C++ at compile-time. The library provides an embedded language for C++ template metaprogramming similar to Haskell's do-notation. Using it, template metaprograms can be written with a syntax that resembles procedural code. Unlike the approach presented at this year's Boostcon, my library focuses on monads evaluated completely at compile-time. The library contains implementations for a number of monads available in Haskell (Maybe, Either, Reader, Writer, State, etc.). As an addition, the library contains a monad for error propagation in C ++ template metaprogramming. Based on the similarities of monadic error propagation and exception handling in runtime C++, the library provides an embedded language that resembles to exception handling. Using it, one can throw and catch "exceptions" at compile-time. metatest Unit testing library for C++ template metaprograms. If a metaprogram test case fails, it does not produce compilation error, but makes the result information available at runtime. Using this one can generate advanced reports and integrate the results into unit testing frameworks for runtime C++ code. The library contains code that integrates it with Boost.Test. The source code, unit tests and examples for the library are available at http://github.com/sabel83/mpllibs I've tested the libraries with the following compilers: - gcc 4.5 - clang 2.8 - Visual C++ 10 Full documentation of the libraries can be found at http://abel.web.elte.hu/mpllibs. Publications related to the libraries: http://abel.sinkovics.hu/?mod=kutat I would like to ask you for access to the Boost sandbox and I would appreciate all feedback from the Boost community. Best regards, Abel Sinkovics

13 31

De Brujin Bind and nested bind calls (was: Re: Template metaprogramming libraries)
by Thomas Heller 19 Sep '11

19 Sep '11

On Fri, Sep 16, 2011 at 7:09 PM, David Sankel <camior(a)gmail.com> wrote: > On Fri, Sep 16, 2011 at 6:30 AM, Thomas Heller > <thom.heller(a)googlemail.com>wrote: >> On Friday, September 16, 2011 06:17:00 AM David Sankel wrote: >> > On Fri, Sep 16, 2011 at 4:51 AM, Thomas Heller >> > <thom.heller(a)googlemail.com>wrote: >> > > On Thursday, September 15, 2011 12:31:50 PM David Sankel wrote: >> > <snip> >> > > <rant> >> > <snip> >> > > It should be noted though that phoenix users can get around >> > > > this somewhat by using _identifier syntax. >> > > > </rant> >> > > #include <boost/phoenix.hpp> >> > <snip> >> > auto flip = lambda(_a = _1)[bind(_a, _2, _1)]; >> > <snip> >> > > Thanks for your unqualified rant, David. >> > huh? >> >> Is this not what you were saying wasn't possible with phoenix? >> Having a De Brujin style syntax is perfectly possible in phoenix. It just >> hasn't been done yet cause, as you saw in my example, can be expressed by >> using phoenix local variables. > > Oh, my bad. When I said "_identifier syntax", I was referring to phoenix > local variables. I should have double-checked my phoenix vocab before I > wrote. > > Phoenix locals definitely help fill the coverage problem I referred to. I > don't know for sure, but I'd expect phoenix to cover all functions that can > be defined in lambda calculus. > > The reason I said that phoenix "somewhat" gets around the bind heritage > problems, which was obscure I admit, was because phoenix's use of > traditional bind syntax still leaves a semantic hole. Ok, misunderstanding on both sides, no offense intended. > If someone writes the following: > > template< typename F > > auto doSomething( F f ) -> decltype(...) > { > return bind( f, 15, _1) > } > > And then I call doSomething elsewhere like this, > > doSomething( bind( g, 12, _1, _2 ) ) > > , then the result is something most likely unexpected for the user who knows > what doSomething means (it returns a version of f that has 15 filled in as > its first argument (λx. λy. x(15,y))), but hasn't read its implementation. Now you got me interested, can you tell me how the DBB syntax solves this problem? Or is it just that your particular implementation solves it? FWIW, phoenix provides everything to introspect the given F and decide which action to take (wrap it into a lambda, "unlambda" it, leave it alone, etc.). One of the main design goals of the phoenix bind module was to be compatible to bind. So unlikely "bind" in its form will be changed. > Don't get me wrong, I think phoenix is an impressive feat. I'm just > advocating that we stop perpetuating the troubles caused by basing new > libraries on the traditional bind syntax. P.S.: I also like the DBB style syntax and think it would be a great addition, as JdG already mentioned, it is all implemented, what's missing is the frontend.

2 1

C++ Standards
by Jarrad Waterloo 19 Sep '11

19 Sep '11

What is the status of and where can one go for current information on TR2, decimal type and modules? Are these dead? Is the C++ standards body taking a 3-10 years siesta before starting on any of these or the next standard? Has there been any recent discussion on "stack trace", reflection, dll(s), overloading -> and other operators. There was a list of items in which there was not enough time to consider for this standard but potential for the next standard. I ask these questions because I found about the link to the C++ standards from the main page of the boost website. However that link has been rather quiet.

2 1

[fusion] boost::fusion::nil bug
by Jeroen Habraken 18 Sep '11

18 Sep '11

Hi, Clang 2.9 just pointed out what's probably an error in fusion in boost-trunk, the same one I ran into during the Conversion review yesterday it seems. Note that GCC doesn't complain even with -Wall -Wextra -pedantic. The error: In file included from fusion.cpp:1: In file included from boost-trunk/boost/fusion/include/vector.hpp:10: In file included from boost-trunk/boost/fusion/container/vector.hpp:11: In file included from boost-trunk/boost/fusion/container/vector/vector10.hpp:15: In file included from boost-trunk/boost/fusion/sequence/intrinsic/begin.hpp:17: In file included from boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin.hpp:11: In file included from boost-trunk/boost/fusion/iterator/segmented_iterator.hpp:13: In file included from boost-trunk/boost/fusion/container/list/cons.hpp:14: In file included from boost-trunk/boost/fusion/sequence/intrinsic/end.hpp:17: boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_end.hpp:33:70: error: invalid use of incomplete type 'fusion::nil' segmented_end_impl<Sequence, fusion::nil>::call(seq, fusion::nil())); ^~~~~~~~~~~~~ In file included from fusion.cpp:1: In file included from boost-trunk/boost/fusion/include/vector.hpp:10: In file included from boost-trunk/boost/fusion/container/vector.hpp:11: In file included from boost-trunk/boost/fusion/container/vector/vector10.hpp:15: In file included from boost-trunk/boost/fusion/sequence/intrinsic/begin.hpp:17: In file included from boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin.hpp:10: In file included from boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin_impl.hpp:11: boost-trunk/boost/fusion/container/list/cons_fwd.hpp:13:12: note: forward declaration of 'boost::fusion::nil' struct nil; ^ 1 error generated. The code to reproduce the error: #include <boost/fusion/include/vector.hpp> int main(int, char*[]) { return 0; } It seems nil is either only forward-declared or the include with the declaration is missing. Kind regards, Jeroen Habraken

4 6

Is there interest in unit testing both passing and failing BOOST_MPL_ASSERTs?
by Ben Robinson 17 Sep '11

17 Sep '11

This submission would make it possible to write a complete set of unit tests for meta-programs, to test both the positive, compiling statements, and the negative, non-compiling statements. These tests will all compile, and the negative tests can throw an exception instead of failing to compile. After reading the recent interest submission from Abel Sinkovics, it occurred to me that it should be possible to modify the four existing BOOST_MPL_ASSERT_* macros to achieve this capability. This behavior would only be enabled if a specific compile flag was defined. Here is a sample code fragment which I have compiled and tested to work as described: // This definition shuts off the BOOST_MPL_ASSERT compile errors, and enables the run-time errors. #define BOOST_MPL_UNITTEST_ASSERTS defined BOOST_AUTO_TEST_CASE(ordinary_passing_test_cases) { BOOST_CHECK_NO_THROW( integers_only<char> passing0; ); BOOST_CHECK_NO_THROW( integers_only<short> passing1; ); BOOST_CHECK_NO_THROW( integers_only<int> passing2; ); BOOST_CHECK_NO_THROW( integers_only<unsigned int> passing3; ); } // These test cases now actually compile, but then throw at runtime, which is unit-testable. BOOST_AUTO_TEST_CASE(fantastic_failing_test_cases) { BOOST_CHECK_THROW( integers_only<float> failing0;, boost::mpl_assert_false); BOOST_CHECK_THROW( integers_only<double> failing1;, boost::mpl_assert_false ); } As you can see, existing code which uses the four BOOST_MPL_ASSERT_* macros, can now be unit tested, without modification, for both positive, and negative use cases. Is anybody interested in this capability, and/or my modifications to the single file boost/mpl/assert.hpp which have enabled this capability? Regards, Ben Robinson, Ph.D.

8 32

Re: [boost] [Boost-docs] Getting CVS read/write access boost-sandbox.cvs.sourceforge.net
by Paul A. Bristow 16 Sep '11

16 Sep '11

> -----Original Message----- > From: boost-docs-bounces(a)lists.boost.org [mailto:boost-docs-bounces@lists.boost.org] On Behalf Of > Daniel James > Sent: Saturday, September 10, 2011 10:06 AM > To: Discussion of Boost Documentation > Subject: Re: [Boost-docs] Getting write access to boost-sandbox.cvs.sourceforge.net I would like to get read and write access to boost-sandbox.cvs.sourceforge.net (to put up some html docs)' I have tried to follow the instructions on Sourceforge.net and believe that I have stored a SSH key because I can login thus using PuTTY "login as: pbristow pbristow(a)boost-sandbox.cvs.sourceforge.net's password: Last login: Thu Sep 15 12:58:36 2011 from 53-133.radnet-kendal.kencomp.net Welcome to *.cvs.sourceforge.net This is a restricted Shell Account You cannot execute anything here." PuTTY Window says "Connection closed by remote host." If I repeat I get login as: pbristow pbristow(a)boost-sandbox.cvs.sourceforge.net's password: Last login: Thu Sep 15 12:59:41 2011 from 53-133.radnet-kendal.kencomp.net Welcome to *.cvs.sourceforge.net This is a restricted Shell Account You cannot execute anything here. whose changed last login date suggests that I am logging in OK - so I know my username and password OK. (or does the fact that I am asked for a password mean that my SSH authentication is wrong?) When I try to CVS checkout, (using a variety of module names (fetch modules list option is not available?) I get PuTTY Fatal error "Network error: connection timed out." cvs [checkout aborted] : end of file from server (consult above messages if any) - and there are no messages :-( Please can any Sourceforge CVS users advise? Thank you. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

2 6