- Boost - lists.boost.org

Re: [boost] [fusion] for_each
by Christophe Henry 05 Oct '10

05 Oct '10

>> I have 2 fusion containers: a small vector (my_vec) and a bigger set >> (my_set). I want to overwrite the elements of the set with elements >> from the vector whenever they have the same type. Sounds simple: >> >> struct update >> { >> update(my_set_type& to_overwrite_):to_overwrite(to_overwrite_){} >> template<typename T> >> void operator()(T& elt) /*const?*/ >> { >> boost::fusion::at_key<T>(to_overwrite)=elt; >> } >> my_set_type& to_overwrite; >> }; >> >> boost::fusion::for_each(my_vec,update(my_set)); >> >> Except that this won't compile because the operator() is required to >> be const, which is sad, because it was very simple. > > And it won't compile *with* the const? I don't think the const'ness of > the member function affects the const'ness of the referent of to_overwrite. No, it won't compile ;-)

2 1

[serialization] assert missing
by Andrew Sutton 05 Oct '10

05 Oct '10

The header 'boost/serialization/item_version_type.hpp' seems to be missing an include on boost/assert.hpp (or cassert) that was causing some compilation failures in the graph_parallel tests (under GCC-4.4.3 on GNU/Linux x86_64). The test case brings this in by including serialization/list.hpp. My first thought was to simply stick an appropriate #include in the item_version_type. Would there be any problems committing this change? Andrew

1 0

[Review] Formal Review of Proposed Boost.Ratio Library Starts TODAY
by nimaca2001＠libero.it 05 Oct '10

05 Oct '10

> > - What is your evaluation of the design? > - What is your evaluation of the implementation? Take this as the review from an average C++ user that uses uses simple boost stuff like shared_ptr or bind but is scared of things like MPL or Spirit. > - What is your evaluation of the documentation? Well written, I would have omitted some appendixes (F and G). > > - Did you try to use the library? With what compiler? Did you have any problems? Tried the provided samples and some self written one on MSVC 9 without problems despite the fact I was using an old version of boost (1.41) as base. > > - How much effort did you put into your evaluation? A glance? A quick > - reading? In-depth study? About one hour to read the docs and compile a few tests > > And finally, every review should answer this question: > > - Do you think the library should be accepted as a Boost library? Yes

2 1

[fusion] [intro] ADAPT_STRUCT extensions
by Stefan Strasser 04 Oct '10

04 Oct '10

Hi, in the discussion about the library I called "Intro" at the time it has been suggested to use BOOST_FUSION_ADAPT_STRUCT of Boost.Fusion for data member access. based on that I'd like to propose two extensions to ADAPT_STRUCT, which I think are useful beyond my use case: 1) ADAPT_STRUCT can adapt public data members only. with the modifications I uploaded here: http://svn.boost.org/svn/boost/sandbox/intro/boost/fusion/adapted/struct/ all data members can be adapted. for example: class A{ private: friend class fusion::access; int a; }; BOOST_FUSION_ADAPT_STRUCT(A,(int,a) ) 2) adaption of a class including its base class members. for example: struct A{ int a; }; struct B{ int b; }; struct C : A,B{ int c; } BOOST_FUSION_ADAPT_STRUCT(A,(int,a) ) BOOST_FUSION_ADAPT_STRUCT(B,(int,b) ) BOOST_FUSION_ADAPT_DERIVED( C, (A)(B), (int,c) ) an instance of C is now a fusion sequence of size 3. http://svn.boost.org/svn/boost/sandbox/intro/boost/fusion/adapted/struct/ad… private inheritance is supported as above, virtual inheritance is not. I'm not sure if virtual inheritance can be supported.

8 30

Boost.SQL?
by Roland Bock 04 Oct '10

04 Oct '10

Hi, currently I am working on a set of header files which are supposed to make the life of C++ developers easier when in comes to interacting with databases (based on SQL). Goals are: * Stay close to SQL syntax * Do as much type checking as possible * prevent oversights and typical security holes, e.g. by forgetting to escape strings The basic idea is, that given a table definition, it should be possible to * offer a lot of checks at compile time for building a query * make it hard to misinterpret the results Until now, I have been concentrating on table definitions and select statements. Here's a very simplistic example, assuming a table definition "my_table" and a database connection "db": // ------------------------------------------------------------------------- using boost; typedef my_table<> t; typedef sql::select_record<t> record; std::string name("Peter"); ... std::vector<record> records = db.select<record>( sql::where(t::id() > 1000 && t::first_name() == name), sql::order_by(t::priority()(sql::desc)), sql::limit(17)); // the values can be accessed by their name // and are of the correct type, e.g. records.front().first_name_; // is a string records.front().middle_name_; // optional<string> because the table definition says that it can be NULL // In case of a select from more than one table, the values can also be accessed like this records.front().my_table_.first_name; // ------------------------------------------------------------------------- I wonder if there would be interest for such a library in boost.

17 44

[config] additions for gcc 4.0.1 and IBM V11.1.0.0duetoMSM compile errors
by Christophe Henry 04 Oct '10

04 Oct '10

John Maddock wrote: > The updated test is passing as well, looks like this may be a case of adding > a BOOST_WORKAROUND for Apple's GCC and see if it fixes things. I added some #if for Apple's gcc and the IBM compiler. A look at the regression tests (http://www.boost.org/development/tests/trunk/developer/msm.html) shows: - all problems with Apple's gcc 4.0.1 are gone (waow cool! Better than expected) - IBM's compiler manages a few test cases more (for others, it just crashes or gives a run-time error status 139 which does not bring me much further) This is in my eyes a proof that for these compilers, BOOST_NO_NESTED_FRIENDSHIP and BOOST_NO_MEMBER_TEMPLATE_FRIENDS should be defined. If these features only work sometimes, then they should not be seen as supported. We now have 2 possibilities: - we change boost.config to reflect this situation and I update my code accordingly - we don't and I have to keep my #if. Solution 2 is not great for me because I'm duplicating boost.config and it litters my code with stuff less clear than BOOST_NO_NESTED_FRIENDSHIP and BOOST_NO_MEMBER_TEMPLATE_FRIENDS. In any case, it'd be good if we could decide on it this week on it so that this makes it to the 1.45. Thanks, Christophe

1 0

[btree] build advice needed
by Phil Endecott 04 Oct '10

04 Oct '10

Dear Beman & others, At the risk of appearing ignorant and being told the RTM, can someone please help me to build btree? I am attempting to do this on a smallish ARM Linux box where building the whole of Boost is impractical (but which should otherwise be very similar to an x86 Linux system). So far: # apt-get install g++ (etc) # apt-get install boost-build # apt-get install bjam # apt-get install git $ git clone git://github.com/Beman/Boost-Btree btree $ cd btree/libs/btree/build $ bjam error: Could not find parent for project at '.' error: Did not find Jamfile or project-root.jam in any parent directory. As it says, there is no project-root.jam or Jamfile in any parent; this makes me think that perhaps it is expecting this to be part of a larger Boost tree. Or, maybe I just don't know the right incantations. What's the easiest way to go about this? If I do need to get other Boost source code, if there some git magic that will do it for me? Thanks, Phil.

3 3

[thread] Memory leak in Boost.Thread?
by Denis Arnaud 03 Oct '10

03 Oct '10

Hello, a Fedora user has reported a potential memory leak in Boost.Thread (see https://bugzilla.redhat.com/show_bug.cgi?id=627875 for details), detected with Valgrind in (at least) versions 1.41.0 and 1.44.0. Following is a code snippet allowing to reproduce the issue: ==================================== #include <boost/thread.hpp> void someWork() { double a; for(int i= 0;i< 1000;i++) { a+=log((double)i); } } int main() { for(int i = 0; i< 10; ++i) { boost::thread_group pool; for(int j = 0; j< 100; ++j) { pool.create_thread(someWork); } pool.join_all(); } } ==================================== Then, following is Valgrind's report: ==================================== ==6442== Memcheck, a memory error detector ==6442== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==6442== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==6442== Command: ./boost_leak ==6442== ==6442== ==6442== HEAP SUMMARY: ==6442== in use at exit: 8 bytes in 1 blocks ==6442== total heap usage: 5,967 allocs, 5,966 frees, 701,720 bytes allocated ==6442== ==6442== 8 bytes in 1 blocks are still reachable in loss record 1 of 1 ==6442== at 0x4C2615D: malloc (vg_replace_malloc.c:195) ==6442== by 0x4E3F989: boost::detail::get_once_per_thread_epoch() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E39923: ??? (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E39BC8: boost::detail::get_current_thread_data() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E3A528: boost::this_thread::interruption_enabled() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E3A548: boost::this_thread::disable_interruption::disable_interruption() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x404DC4: boost::shared_mutex::lock() (in /tmp/boost_leak) ==6442== by 0x40588D: boost::lock_guard<boost::shared_mutex>::lock_guard(boost::shared_mutex&) (in /tmp/boost_leak) ==6442== by 0x405DB5: boost::thread* boost::thread_group::create_thread<void (*)()>(void (*)()) (in /tmp/boost_leak) ==6442== by 0x403B91: main (in /tmp/boost_leak) ==6442== ==6442== LEAK SUMMARY: ==6442== definitely lost: 0 bytes in 0 blocks ==6442== indirectly lost: 0 bytes in 0 blocks ==6442== possibly lost: 0 bytes in 0 blocks ==6442== still reachable: 8 bytes in 1 blocks ==6442== suppressed: 0 bytes in 0 blocks ==6442== ==6442== For counts of detected and suppressed errors, rerun with: -v ==6442== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) ==================================== Is that really a memory leak? Kind Regards Denis

3 5

[filesystem] Issue with replace_extension
by cheesy4poofs 02 Oct '10

02 Oct '10

I've recently switched all our code to filesystem v3 and added BOOST_FILESYSTEM_NO_DEPRECATE on our builds for good measure. One of the changes I had to fix was our use of change_extension(), which was modified to use the replace_extension() method. However, some of our code started failing and I tracked it down to this example: boost::filesystem::path p("C:\\database\\test\\filename"); p.replace_extension(".db"); std::cout << p.string() << std::endl; // OUTPUT - C:\database\test\filename.db p = "C:\\database.1\\test\\filename"; p.replace_extension(".db"); // bug? std::cout << p.string() << std::endl; // OUTPUT - C:\database.db As you can see, in the second example, it truncates the path and assumes the directory name "database.1" has the extension that needs replacing. change_extension() did not behave this way. Is this the expected behavior? Thanks, Scott

2 1

[ratio] Mini-review of the proposed ratio library
by Beman Dawes 02 Oct '10

02 Oct '10

> The review of Vicente Botet' Ratio library starts October 2nd and lasts > until October 11th, 2010, unless an extension occurs. > > What is it? > ======== > Portable implementation of the C++0x Standard Library's compile-time > rational arithmetic working on C++03 and C++0x compilers. See the > current C++0x working draft at > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf > - What is your evaluation of the design? The question is essentially moot since Vicente followed the C++0x standard library design. The real question is "Does Boost need a library that every standard library vendor will be supplying anyhow?" For me, the answer is, yes, at least provisionally. The provisional part is because the library I'd really like to see in Boost in chrono. But we can't have <boost/chrono.hpp> without <boost/ratio.hpp>, so I'm in favor of ratio. The reason I'd like a Boost version is that I don't want to have to wait years and years to be able to use <boost/chrono.hpp> and <boost/ratio.hpp> in Boost libraries. I want to be able to use them with the compilers and standard libraries people are using today, not years from now. > - What is your evaluation of the implementation? I am familiar with the original source code, and worked on boostifying it. Vicente has done a lot of work to make the code more robust in the Boost environment. > - What is your evaluation of the documentation? I skimmed through it, and checked the header against the C++ standard. My impression is favorable. > - What is your evaluation of the potential usefulness of the library? Chrono needs it:-) > - Did you try to use the library? With what compiler? Did you have any problems? No. > - How much effort did you put into your evaluation? A glance? A quick > - reading? In-depth study? A quick skim through the docs. > - Are you knowledgeable about the problem domain? Some knowledge, but far from an expert. > And finally, every review should answer this question: > > - Do you think the library should be accepted as a Boost library? Yes. I'm hoping others will post more in depth reviews. My review is really just a mini-review, but maybe will help to keep the ball rolling. --Beman

3 4