May 2011 - Boost-users - lists.preview.boost.org

[range] filtered dereferences underlying range elements twice
by Nathan Ridge 01 Jun '11

01 Jun '11

Hello, It seems that the 'filtered' adaptor dereferences elements of the underlying range twice if they pass the filter. This is illustrated in the following example, where a range is first transformed and then filtered: #include <iostream> #include <boost/range/adaptor/transformed.hpp> #include <boost/range/adaptor/filtered.hpp> #include <boost/range/algorithm/copy.hpp> int transform(int i) { std::cout << "calling transform() on " << i << "\n"; return i + 1; } bool filter(int i) { return i % 2 == 0; } int main() { int a[] = {1, 2, 3, 4, 5, 6, 7, 8}; int b[8]; boost::copy(a | boost::adaptors::transformed(transform) | boost::adaptors::filtered(filter), b); return 0; } The output is: calling transform() on 1 calling transform() on 1 calling transform() on 2 calling transform() on 3 calling transform() on 3 calling transform() on 4 calling transform() on 5 calling transform() on 5 calling transform() on 6 calling transform() on 7 calling transform() on 7 calling transform() on 8 As you can see, the transform function is called twice for elements that pass the filter. Can this be avoided? In my real use case, the transformation performs a database lookup, and it should not be done twice. Thanks, Nate.

2 6

[Thread] this_tread::sleep won't compile with gcc, "no match for operator+"
by Alexey Malakhov 31 May '11

31 May '11

Hi! This is most probably a "newbie question", but I really don't see what exactly wrong I'm doing, so will appreciate any inputs. Basically, what I'm trying to do is: using namespace boost::posix_time; using namespace boost::this_thread; time_duration td = milliseconds(2000); sleep(&td); And it works ok with Visual Studio and Windows. Once I get it to linux and try to compile with gcc, this is what I get: g++ -c -Wall -I/home/gsed/boost/ main.cpp -o main.o In file included from /home/gsed/boost/boost/thread/thread.hpp:17:0, from includes.h:12, from main.cpp:1: /home/gsed/boost/boost/thread/pthread/thread_data.hpp: In function void boost::this_thread::sleep(const TimeDuration&) [with TimeDuration = boost::posix_time::time_duration*]: main.cpp:47:11: instantiated from here /home/gsed/boost/boost/thread/pthread/thread_data.hpp:138:13: error: no match for operator+ in boost::get_system_time() + rel_time /home/gsed/boost/boost/date_time/time.hpp:139:15: note: candidates are: time_type boost::date_time::base_time<T, time_system>::operator+(boost::date_time::base_time<T, time_system>::date_duration_type&) const [with T = boost::posix_time::ptime, time_system = boost::date_time::counted_time_system<boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config> >, time_type = boost::posix_time::ptime, boost::date_time::base_time<T, time_system>::date_duration_type = boost::gregorian::date_duration] /home/gsed/boost/boost/date_time/time.hpp:159:15: note: time_type boost::date_time::base_time<T, time_system>::operator+(boost::date_time::base_time<T, time_system>::time_duration_type&) const [with T = boost::posix_time::ptime, time_system = boost::date_time::counted_time_system<boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config> >, time_type = boost::posix_time::ptime, boost::date_time::base_time<T, time_system>::time_duration_type = boost::posix_time::time_duration] /home/gsed/boost/boost/date_time/posix_time/date_duration_operators.hpp:75:3: note: boost::posix_time::ptime boost::posix_time::operator+(const boost::posix_time::ptime&, const boost::gregorian::years&) /home/gsed/boost/boost/date_time/posix_time/date_duration_operators.hpp:31:3: note: boost::posix_time::ptime boost::posix_time::operator+(const boost::posix_time::ptime&, const boost::gregorian::months&) make: *** [main.o] Error 1 ie it's trying to perform a boost::posix_time::ptime + time_duration operation, but for some reason can't decide between operator+(boost::date_time::base_time<T, time_system>::date_duration_type&) and operator+(boost::date_time::base_time<T, time_system>::time_duration_type&) And I'm absolutely not sure why. Win version works well I guess because there's another include file used and the whole thing is arranged differently. Again, any inputs or advice are greatly appreciated. Thanks! -- Take care, Alexey Malakhov

3 5

running the test suite for a library
by Mathieu Champlon 31 May '11

31 May '11

Hello, I'm trying to build and run Boost.Test test suite on trunk. From a fresh checkout, using cygwin and targeting msvc-8.0 I did first from the boost root directory : ./bootstrap.bat This went fine, then just to be sure I did : ./bjam.exe toolset=msvc-8.0 --with-test Which also went fine. Then I switched to libs/test/test and did : ../../../bjam.exe toolset=msvc-8.0 Which failed with : ..\..\..\libs\test\build\Jamfile.v2:107: in modules.load rule boost-install unknown in module Jamfile</D:/dev/perso/cpp/boost/libs/test/build>. D:/dev/perso/cpp/boost/tools/build/v2/build\project.jam:314: in load-jamfile D:/dev/perso/cpp/boost/tools/build/v2/build\project.jam:62: in project.load D:/dev/perso/cpp/boost/tools/build/v2/build\project.jam:766: in project.use D:/dev/perso/cpp/boost/tools/build/v2/build\project.jam:89: in load-used-projects D:/dev/perso/cpp/boost/tools/build/v2/build\project.jam:73: in load D:/dev/perso/cpp/boost/tools/build/v2/build\project.jam:115: in load-parent D:/dev/perso/cpp/boost/tools/build/v2/build\project.jam:464: in initialize D:/dev/perso/cpp/boost/tools/build/v2/build\project.jam:309: in load-jamfile D:/dev/perso/cpp/boost/tools/build/v2/build\project.jam:62: in load D:/dev/perso/cpp/boost/tools/build/v2/build\project.jam:115: in load-parent D:/dev/perso/cpp/boost/tools/build/v2/build\project.jam:464: in initialize D:/dev/perso/cpp/boost/tools/build/v2/build\project.jam:309: in load-jamfile D:/dev/perso/cpp/boost/tools/build/v2/build\project.jam:62: in load D:/dev/perso/cpp/boost/tools/build/v2/build\project.jam:168: in project.find D:/dev/perso/cpp/boost/tools/build/v2\build-system.jam:570: in load D:\dev\perso\cpp\boost\tools\build\v2/kernel\modules.jam:283: in import D:\dev\perso\cpp\boost\tools\build\v2\kernel\bootstrap.jam:142: in boost-build D:\dev\perso\cpp\boost\boost-build.jam:17: in module scope What am I doing wrong ? Thank you, MAT.

1 0

[boost] [review] Heaps
by Andrew Sutton 31 May '11

31 May '11

All, I'd like to announce the beginning of the review of the Heap library, written by Tim Blechmann, and resulting from Tim's 2010 Google Summer of Code project The library implements a number of different heaps (or priority queues) including, a binary heap, d-ary heap, binomial heap, fibonacci heap, pairing heap, and skew heap. The library also provides an adaptor to make heaps mutable, allowing a programmer to modify a value and update its position within the heap. The library also also supports stability, ensuring that elements pushed into a heap with the same priority are popped in the same order. The library is not targeted in any specific domain nor directly related to any specific libraries, but intended to be a collection of general purpose data structures (not unlike the Boost.Unordered library). The documentation and source code can be downloaded from here: Documentation: http://tim.klingt.org/boost_heap Code: http://tim.klingt.org/git?p=boost_heap.git;a=snapshot;h=HEAD;sf=tgz Unlike previous reviews, this review will be assisted by a code review application, Code Collaborator (by SmartBear). The product was tested during a BoostCon session, and we are eager to see how well it scales to a community review. You can use the link below to access and review the Heap library. http://demo.smartbear.com/boost/go?page=ReviewDisplay&reviewid=4 The application allows line-by-line comments of the submitted source code in addition to providing features for general defect and issue reporting. If you are interested in using this system, we will have to register you as a user of the site. You can request access by replying to this message. I'm still learning my way around the system, so there are bound to be some missteps along the way :) If you are not interested in using the system, then feel free to send email like any other review. Reviews of the library should address the following questions. 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? And finally, every review should answer this question: Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Please note that some questions may be easier to answer in email than with the review tool. As always, reviews are important to the continued quality of the Boost C++ Libraries. Thank you in advance for your comments and contributions. Andrew PS. The review was slated to start on Sunday, but I was not able to make the announcement until today. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [Boost-users] Boost Unit Testing of DLL's
by Gennadiy Rozental 31 May '11

31 May '11

Tyler Weston <tyler.weston <at> gmail.com> writes: > If you add a "delay load" flag for the boost UTF DLL, you should be able > to ship testing code in your DLL without providing the UTF DLL to > customers. This instructs the compiler to only look for the UTF DLL when > the testing framework attempts to make a call. As long as your users > don't try to call your test hooks, it should work out. > http://msdn.microsoft.com/en-us/library/yx9zd12s%28v=VS.90%29.aspx This will not work if OP using auto test cases. These are generated at startup and will require UTF dll. Gennadiy

2 3

Is boost test thread-safe?
by edA-qa mort-ora-y 31 May '11

31 May '11

I searched a bit but was unable to find a reasonable answer. Is the test framework thread-safe? I am asking since when I do threaded tests I get weird and seemingly random output. By thread-safe I don't mean that I have multiple tests running at the same time, but simply that I have tests which involve multiple threads. For example: BOOST_AUTO_TEST_CASE( threaded ) { thread a( func_a ); thread b( func_b ); a.join(); b.join(); } void func_a() { ... BOOST_CHECK_EQUAL( 123, var ); } It appears that using the BOOST_CHECK tools from the thread causes problems. -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Sign: Please digitally sign your emails. Encrypt: I'm also happy to receive encrypted mail.

3 4

[Test] can one run a specific test first?
by Thorsten Ottosen 31 May '11

31 May '11

Hi, I know I can run a test by naming it on the command line or by creating an environment variable. However, I merely want a specific test to be run first to ease debugging, and then all the rest of the tests should be run. Is this possible? Thanks -Thorsten

2 3

question about fusion concepts/documentation
by Robert Ramey 31 May '11

31 May '11

I'm working on a personal project based on fusion. This project builds a library on I'm working on an experimental library which builds on fusion. As part of that I want to implement concept checking for this experimental library. Since this builds on fusion, I want to implement concept checking for fusion so my library can build on that. Since fusion seems clearly documented, I would hope that this would be a fairly straight forward exercise. This will also give me a better feel for concept checking and archtypes. Looking at fusion documentation on page: ..libs/fusion/doc/html/fusion/iterator/concepts/forward_iterator.html I find: Expression Requirments ====================== next(i) ... Meta Expressions ============ result_of::next<I>::type ... Expression Semantics =============== next(i) - An iterator to the element following i ... So the quesion is: Why is result_of::next<I>::type necessary? The expression symantics only make sense if next(i) if it returns the same type as it's argument. So why is the result_of::next<I>::type needed at all. That is won't it always be equal to I. If not, why not? The question I have applies to other functions as well but next illustrates my question. specifially I have the same question regarding advance, and advance_c. Also the espressions i == j should return a value convertible to bool. Then what is result_of::equal_to<I, J>::type to be used for? distance raises similar quesions. I'm actually having quite a bit of difficulty with this task - the above quesions are only the easiest one to formulate. Robert Ramey

4 8

boost::serialization problem with own defined primitive type
by Robert Bielik 31 May '11

31 May '11

Hi all, I've tried to define operator >> & << in order to make a juce::String serializable in the same manner as a std::wstring. Here is the question thread on StackOverflow: http://stackoverflow.com/questions/6126133/boost-deserialization-problem-of… Any ideas what might be wrong ? Thing is (as I say in the thread above), that it _has_ worked and I obviously have made a change but 2 hours of checking SVN repo diffsets I cannot find it. TIA /Rob

3 8

[range] cannot use lambda predicate in adaptor with certain algorithms
by Nathan Ridge 30 May '11

30 May '11

Hello, I get errors related to lambdas not being default-constructible or copy-assignable when using a lambda as a predicate with certain adaptors (e.g. filtered) and certain algorithms (e.g. min_element). The following code illustrates the problem: #include <boost/range/algorithm/min_element.hpp> #include <boost/range/adaptor/filtered.hpp> int main() { int a[] = {1, 2, 3}; auto is_odd = [](int i){ return i % 2 == 1; }; boost::min_element(a | boost::adaptors::filtered(is_odd)); } The errors are shown below. Is there a workaround for this? Thanks, Nate. Errors: In file included from algorithm:63:0, from /usr/lib/boost/boost/iterator/iterator_concepts.hpp:29, from /usr/lib/boost/boost/range/concepts.hpp:20, from /usr/lib/boost/boost/range/algorithm/min_element.hpp:15, from test.cpp:1: stl_algo.h: In function 'boost::filter_iterator<main()::<lambda(int)>, int *> min_element( boost::filter_iterator<main()::<lambda(int)>, int *> , boost::filter_iterator<main()::<lambda(int)>, int *> )': /usr/lib/boost/boost/range/algorithm/min_element.hpp:44:63: instantiated from 'boost::range_iterator<const T>::ame boost ::range_iterator<const T>::type = boost::filter_iterator< main()::<lambda(int)>, int * > boost::range::min_element( const boost::range_detail::filtered_range< main()::<lambda(int)>, int [3] > & )' test.cpp:8:61: instantiated from here stl_algo.h:6109:4: error: use of deleted function 'boost::filter_iterator< main()::<lambda(int)>, int * > & boost::filter_iterator<main()::<lambda(int)>, int *>::operator=( const boost::filter_iterator<main()::<lambda(int)>, int *> & )' In file included from /usr/lib/boost/boost/range/adaptor/filtered.hpp :16:0, from test.cpp:2: /usr/lib/boost/boost/iterator/filter_iterator.hpp:44:9: error: 'boost ::filter_iterator<main()::<lambda(int)>, int *> & boost::filter_iterator< main()::<lambda(int)>, int * >::operator=( const boost::filter_iterator<main()::<lambda(int)>, int *> & )' is implicitly deleted because the default definition would be ill- formed: /usr/lib/boost/boost/iterator/filter_iterator.hpp:44:9: error: use of deleted function 'main()::<lambda(int)> & main()::<lambda(int)>::operator=( const main()::<lambda(int)> & )' test.cpp:7:20: error: a lambda closure type has a deleted copy assignment operator In file included from /usr/lib/boost/boost/range/adaptor/filtered.hpp :16:0, from test.cpp:2: /usr/lib/boost/boost/iterator/filter_iterator.hpp: In constructor 'boost::filter_iterator<main()::<lambda(int)>, int *>::filter_iterator()': /usr/lib/boost/boost/concept_check.hpp:133:10: instantiated from 'boost::DefaultConstructible< boost::filter_iterator<main()::<lambda(int)>, int *> >::~DefaultConstructible()' /usr/lib/boost/boost/concept/usage.hpp:22:29: instantiated from 'boost::concepts::usage_requirements< boost::DefaultConstructible< boost::filter_iterator<main()::<lambda(int)>, int *> > >::~usage_requirements()' /usr/lib/boost/boost/concept/detail/general.hpp:38:28: instantiated from 'static void boost::concepts::requirement< boost::concepts::failed ************ boost::concepts ::usage_requirements< boost::DefaultConstructible< boost::filter_iterator<main()::<lambda(int)>, int *> > >::************ >::failed()' /usr/lib/boost/boost/concept_check.hpp:132:1: instantiated from 'boost::DefaultConstructible< boost::filter_iterator<main()::<lambda(int)>, int *> >' /usr/lib/boost/boost/range/concepts.hpp:169:16: instantiated from 'boost::range_detail::ForwardIteratorConcept< boost::filter_iterator<main()::<lambda(int)>, int *> >' /usr/lib/boost/boost/concept/detail/has_constraints.hpp:42:5: [ skipping 5 instantiation contexts ] /usr/lib/boost/boost/concept/detail/has_constraints.hpp:42:5: instantiated from 'const bool boost::concepts::not_satisfied< boost::ForwardRangeConcept< const boost::range_detail::filtered_range< main()::<lambda(int)>, int [3] > > >::value' /usr/lib/boost/boost/concept/detail/has_constraints.hpp:45:31: instantiated from 'boost::concepts::not_satisfied< boost::ForwardRangeConcept< const boost::range_detail::filtered_range< main()::<lambda(int)>, int [3] > > >' /usr/lib/boost/boost/mpl/if.hpp:67:11: instantiated from 'boost::mpl ::if_< boost::concepts::not_satisfied< boost::ForwardRangeConcept< const boost::range_detail::filtered_range< main()::<lambda(int)>, int [3] > > >, boost::concepts::constraint< boost::ForwardRangeConcept< const boost::range_detail::filtered_range< main()::<lambda(int)>, int [3] > > >, boost::concepts::requirement< boost::concepts::failed ************ boost::ForwardRangeConcept< const boost::range_detail::filtered_range< main()::<lambda(int)>, int [3] > >::************ > >' /usr/lib/boost/boost/concept/detail/general.hpp:50:8: instantiated from 'boost::concepts::requirement_< void (*)( boost::ForwardRangeConcept< const boost::range_detail::filtered_range< main()::<lambda(int)>, int [3] > > ) >' /usr/lib/boost/boost/range/algorithm/min_element.hpp:43:1: instantiated from 'boost::range_iterator<const T>::ame boost ::range_iterator<const T>::type = boost::filter_iterator< main()::<lambda(int)>, int * > boost::range::min_element( const boost::range_detail::filtered_range< main()::<lambda(int)>, int [3] > & )' test.cpp:8:61: instantiated from here /usr/lib/boost/boost/iterator/filter_iterator.hpp:54:25: error: use of deleted function 'main()::<lambda(int)>::<lambda>()' test.cpp:7:20: error: a lambda closure type has a deleted default constructor

4 8