- Boost - lists.boost.org

Boost and subdirectories named 'debug'
by Edward Diener 07 May '08

07 May '08

Boost has some subdirectories named 'debug' which contain static files used by some Boost libraries and their dependencies. In some build systems, like MSVC, the 'debug' directory is a directory where intermediate build files, such as object files, are put, and these directories are dynamic in the sense that there contents can always be regenerated from source. A common, if perhaps erroneous, technique of forcing rebuilds in these systems is to wipe out the 'debug' directories. If Boost is in some tree where the 'debug' directories are all being wiped out indiscriminately, then the Boost 'debug' directories get wiped out and source using Boost libraries and/or their dependencies which have 'debug' directories will fail to compile. Yes, I know in the age of IDEs that no one is supposed to build like that anymore, or that it is a very good idea not to put Boost in some tree where the end user decides to arbitrarily wipe out all 'debug' directories in order to force a rebuild, but these things can happen. Because of that this is a gentle suggestion that Boost in the future choose some other name for a subdirectory than 'debug' for those libraries using that name.

1 0

[build] symbolic vs hard library links
by Frank Mori Hess 07 May '08

07 May '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After building boost from svn on linux, I've noticed it produces a mix of symbolic and hard links for the built libraries (output of "ls -l" attached). I'm curious if this was intentional? Have I just configured my source tree in some strange way? - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIIbi+5vihyNWuA4URApvHAJ90L2JBOjvFyPtT1KKRXFS6zsxeigCg0hNH 2FTth+XYWEqSzHFccXRCq/0= =7Uzr -----END PGP SIGNATURE-----

2 1

[test] --catch_system_errors questions
by Juergen Hunold 07 May '08

07 May '08

Hi ! I'm using Boost.Test for quite a while and now I wonder if the behaviour of "--catch_system_errors" is correct. I've attached a simple test case which just triggers a simple "assert(false);". Running the testcases with trunk bjam yields one failure and two passing tests. See "test.log" for details. Running the testcases against 1.341. yields three failures with _different_ exit codes. See test_1_34_1.log When looking at the output of trunk "with_catch.test", I see --snip--- with_catch: assert_test.cpp:13: void test_assert::test_method(): Assertion `false' failed. <TestLog><TestSuite name="Master Test Suite"><TestCase name="test_assert"><Message file="assert_test.cpp" line="11">one</Message><Info file="assert_test.cpp" line="12">check true passed</Info><TestingTime>0</TestingTime></TestCase></TestSuite></TestLog><TestResult><TestSuite name="Master Test Suite" result="passed" assertions_passed="1" assertions_failed="0" expected_failures="0" test_cases_passed="1" test_cases_failed="0" test_cases_skipped="0" test_cases_aborted="0"></TestSuite></TestResult> EXIT STATUS: 0 --snap-- So, some observations: Obviously, the UTF succeds in catching the "assert". The resulting message is not in the XML-Log The return code is 0 (Success). A quick look at the new docs prototype at http://www.patmedia.net/~rogeeff/html/utf/usage-recommendations/command-lin… found "If you got fatal exception somewhere within test case, make program generate coredump by adding extra command line argument " This was not easy to spot since the real test cases succeeded with error code 0 and the message was hidden in the log file. I found this because msvc on windows fires up an annoying debug window instead. So it seems this is not working there. So, my questions/suggestions are: Is this a bug ? Or a feature ? And if its a feature, where can I find the rationale ? I think the caught assertions should lead to a non-zero exit code and a failing test suite. And it would be nice if they got properly XML-formatted (but after a quick scan through the source, this seems difficult...) Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

4 10

[phoenix][spirit] Phoenix 2 already in trunk?
by Dean Michael Berris 07 May '08

07 May '08

I see that there's a new version of Spirit in Boost trunk. I'm just curious though, does this version already have the (much awaited) Phoenix 2 library? If not, is there a good packaging of Phoenix 2 already available? Pointers would be very much appreciated. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://blog.cplusplus-soup.com] [mikhailberis(a)gmail.com] [+63 928 7291459] [+1 408 4049523]

2 2

[shifted_ptr][3.1] Works fine
by Phil Bouchard 07 May '08

07 May '08

Ok, I just uploaded a version that finally works fine. At this point I would doubt there is any bugs left in its functionality. Thanks, -Phil

2 7

[Random] Differing values from minstd_rand in v1.35.0
by Greg Landrum 07 May '08

07 May '08

Dear all, Sorry if this is an inappropriate forum, but neither a question I posted about this to boost.users almost a month ago (http://article.gmane.org/gmane.comp.lib.boost.user/34979) nor a bug report I submitted two weeks ago (http://svn.boost.org/trac/boost/ticket/1856) have evoked any response. The specific question/problem that I have is: After moving from boost 1.34.1 to 1.35.0 I have noticed that the sequence of values returned by the minstd_rand generator has changed. I'm curious to know if this was due to fixing a bug in the code, introducing a bug in the code, or me having incorrect expectations about boost::random (that results from the generators will remain constant across versions). Specific details, as well as code to reproduce what I've seen, are in the bug report. Please let me know if there is someone I should contact directly or a better forum for the question/problem. Thanks, -greg

1 0

Comparative efficiency of lambda versus bind
by Joe Gottman 07 May '08

07 May '08

I want to use either bind or lambda to create a small function object to pass to std::transform. Is one noticeable more efficient than the other? The call would either be like transform(a.begin(), a.end(), b.begin(), boost::bind(multiplies(), _1, x)); or transform(a.begin(),a.end(), b.begin(), _1 * x); Joe Gotttman

1 0

Catching async asio errors
by Billy Chasen 06 May '08

06 May '08

Do I need to do anything special to catch an error from a boost asio async method? Or can I just wrap the method (eg: async_write) in a try/catch? (Since the initial call may be fine, but later on, an async call fails and I'm already out of the try/catch block) thanks, billy

2 1

result_of usability
by David Abrahams 06 May '08

06 May '08

The difficulty of implementing the result_of protocol has always bothered me. I've often found myself writing a primary result<...> template and several specializations to handle different cv-qualifications, and I've still not felt that I was doing it quite right. It's lucky that operator() has to be a member function, or I'd be worried about capturing the r/lvalue-ness of the function object itself. Now I just ran into another issue, from the other side of the result_of interface. If I have a function template taking a function object argument by reference, and I want to use result_of with it, I need to do something special to account for the case where I've been passed a function reference. To wit: template <class F> typename result_of<F()>::type call(F const& f) { return f(); } int f() { return 0; } int x = call(f); The problem is that in the above case, F is deduced as int(), and we form an illegal function type (one that itself returns a function type) in result_of<F()>::type. To deal with this I need something more like template <class F> typename result_of< typename mpl::if_< is_class<F> , F , typename add_pointer<F>::type >::type() >::type call(F const& f) { return f(); } Is there an easier way? -- Dave Abrahams Boost Consulting http://boost-consulting.com

5 11

GTL redesign and review process
by Simonson, Lucanus J 06 May '08

06 May '08

I thought I'd update those who are interested in on my progress redesigning the generic interfaces of my geometry type system. After implementing compile time accessors in the point_concept class and noticing that specializing them required explicit specialization of all possible values of the template parameter I realized that this won't work for more general interfaces. Specifically, polygons require iterator semantics at their interfaces. That means that the arguments to the set() interface of a polygon_concept would need to be templated for the iterator type, since that function should take an iterator range. Since functions cannot be partially specialized I moved the accessors back into the point_traits<T> stuct, where it is the struct that is specialized, and the functions can keep their template parameter lists when the user specialized the traits for their type. This however led to a erroneous attempt to wrap the point_traits accessor with a templated function (such as a wrapper in the point_concept struct). In the example below, I show a free function wrapper. Directly instantiating and calling the point_traits<T>::get<int>(T) function compiles, but calling the free function wrapper does not compile and gives an error about operator<. //demo point type struct point_data { int coords_[2]; int get(int orient) const { return coords_[orient]; } typedef int coordinate_type; }; template <typename T> struct point_traits { typedef typename T::coordinate_type coordinate_type; template<int orient> static inline coordinate_type get(const T& point) { return point.get(orient); } }; template <int orient, typename T> typename point_traits<T>::coordinate_type get(const T& point) { return point_traits<T>::get<orient>(point); } int main() { point_data pt; //this line compiles int value0 = point_traits<point_data>::get<0>(pt); //this line does not compile int value = get<0>(pt); return 0; } Note, if the free function directly uses the API of the data type it compiles, but as I explained initially, I need the indirection of going through the point_traits struct to allow specialization without getting burned by the language disallowing partial specialization of functions. This leaves me in something of a pickle. Because it was what I wanted to do anyway in the first place, my solution is to take the orient parameter out of the template list and make it runtime. The compiler readily accepts that syntax. After rewriting the example code that way, and getting it compiling and working satisfactorily, I was very pleased to notice that all of the code that looked like: if(orient == HORIOZNTAL) return get<HORIZONTAL>(point); return get<VERTICAL>(point); was gone, and access through any path of indirection would result in no if statements needing to be executed. I did implement a compile time accessor in the point concept (it calls the runtime one in the point_traits struct) but it doesn't make a lot of sense to have it, since: template <typename T> typename point_traits<T>::coordinate_type point_concept::x(const T& point); is more concise. Since this isn't a tuple or some n-dimensional hyper-point there is no need for meta-programming its accessors. So, I also went ahead and implemented the pattern for polygon data types. I translated some of the algorithms that operate on a polygon to use the new interface to get a taste for what was in store for me. In the guts of the polygon_type related code is an algorithm (implemented as an iterator) for converting the "compact" representation of a manhattan polygon with one integer per edge to a sequence of points at its vertices. The increment operator looks thusly: inline iterator_points& operator++() { ++iter_; if(iter_ == iter_end_) { if(point_concept::get<HORIZONTAL>(pt) != firstX_) { --iter_; point_concept::set<HORIZONTAL>(pt, firstX_); } } else { point_concept::set(pt_, orient_, *iter_); orient_.turn90(); } return *this; } Note: that most of the time it updates a point pt_, which is a member of the iterator_points class based on the *runtime* value of orient_, and then changes the runtime value each time it is called. When executed in a loop this results in no branch instructions other than the ones checking for loop termination (and the special case for last vertex). If I used compile time accessors as the interface to the data type there would be an extra branch in that loop for no good reason when using my own point type (the common case.) Thoughts? Thanks, Luke

3 4