May 2007 - Boost - lists.preview.boost.org

SVN repo structure... [was: Subversion structure in KDE]
by Rene Rivera 05 Jun '07

05 Jun '07

Ping... Any comments on this? It would be nice if people voice some comments on this subject now. Instead of later when we would have to move a bunch of directories around. -------- Original Message -------- Subject: Re: [boost] Subversion structure in KDE Date: Sun, 27 May 2007 17:54:20 -0500 From: Rene Rivera <grafikrobot(a)gmail.com> Henrik Sundberg wrote: > KDE is also a large project with separate subprojects. I thought it > might be a good idea to look at their structure. [snip] > Here is the repository: http://websvn.kde.org/ [snip] > How about a trunk with the two subdirectories Boost and Sandbox? The > Boost directory would contain libraries that are to be part of the > next official Boost release, and the Sandbox other libraries. If I'm understanding you, and the KDE docs, correctly, what you want is something like(**): [boost-svn] boost stable (full boost tree here) devel (full boost tree here) branches my_branch (full boost tree here) cmake_a (full boost tree here) cmake_b (full boost tree here) tags boost_1_33_1 (full boost tree here) boost_1_34_0 (full boost tree here) sandbox devel xml (partial boost tree here) explore (partial boost tree here) branches xml_b0 (partial boost tree here) explore_b0 (partial boost tree here) tags xml_for_review (partial boost tree here) explore_for_review (partial boost tree here) That seems like a reasonable arrangement to me. It has the beauty of being easy to explain, and it's not too far off from what we have now. The one drawback I can see is that one common case, of updating boost/stable and boost/devel can't be done in one go. But I think that's a reasonable aspect to give up (not that we had it in the first place) since hopefully working with both at the same time will be an infrequent task. (**) I'm ignoring the website tree because it's not the same kind of beast. Since it only has to deal with two versions, and doesn't need tags. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

12 21

GSoC: "Boost.Extension and Reflection" library [plugin]
by Janek Kozicki 04 Jun '07

04 Jun '07

The link from http://code.google.com/soc/boost/about.html states: Title: Boost.Extension and Reflection Student: Mariano Gabriel Consoni Mentor: Hartmut Kaiser "The project that I propose is centered in adding to Boost a library that allows the programmer to include extensions/plugins. Additionally this will be the start point to implement reflection concepts. [...]" I want to ask what is the progress with this library? I remember from GSoC 2006 conclusions that we all agreed that the progress during SoC should be advertised on boost mailing list to encourage participation from other people (especially looking at code during its evolution). I'm not even sure if SoC has already started, or will it start next month? Anyway I want to point out that I'm particularly curious about the progress in this area. PS: why this wiki webpage for GSoC 2007 is wiped out? http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summe… -- Janek Kozicki |

6 13

[soc 07] SoC 2007 Projects
by Jeff Garland 04 Jun '07

04 Jun '07

Hi All - I'm happy to announce that Boost will be mentoring 9 Google SoC projects this year. They are: Title Student Mentor ----------------------------------------------------------------------------- User-friendly graphs and their measures Andrew Sutton Jeremy Siek FastCGi and SCGI-compatible CGI library Darren Garvey Christopher M Kohlhoff Boost 'Big Integer' proposal Arseny Kapoulkine Jeff Garland Signal Network library Stjepan Rajko Douglas Gregor Evolutionary Computation Library Aaron Garrett Jaakko Järvi Application to extend Boost regex with recursive matching, named sub-expressions, and automata-based matching Hugh Wimberly John Maddock Visualization Of Arrays And STL Containers Jacob R>Voytko Joaquín L. Muñoz Boost.Extension and Reflection Mariano G. Consoni Hartmut Kaiser A Generic Geometric Library Huseyin Akcan Herve Bronnimann You can find the abstracts of these projects online here: http://code.google.com/soc/boost/about.html As with last year, there were many worthy students and projects that ultimately were not selected. So, for all the students that were not selected realize that the competition for a very few slots was immense. My main advice for students that might want to try again next year is to start participating now -- it really helps to hang out on the list, submit patches, and work on ideas well in advance of SoC. I'd like to thank the mentoring team that evaluated the ~220 applications we received this year. It takes a huge effort to go thru these, read, rank, clarify and give feedback. Note that in addition to the mentors above Andreas Huber, Rene Rivera, and Daniel Wallin all helped with evaluations. For those coming to BoostCon I'll be giving a presentation on Friday about Boost and SoC: http://www.boostcon.com/program/sessions#garland-summer-of-code And, if you aren't coming to BoostCon, well, you should ;-) http://www.boostcon.com/registration Jeff

5 5

noncopyable EBO problem?
by Gmane 04 Jun '07

04 Jun '07

Hi, as sparent(a)adobe.com pointed out in <http://svn.boost.org/trac/boost/ticket/979>, the EBO is not possible in some cases. I fixed the operators library, but now I wonder if we should fix boost::noncopyable as well. Consider: class A : boost::noncopyable {}; class B : boost::noncopyable { A a; }; now sizeof(B)==2 instead of the expected 1. To fix it, we have to change the interface (or at least allow an alternative interface). Example with the interface I'd like to suggest: class A : boost::noncopyable_<A> {}; class B : boost::noncopyable_<B> { A a; }; now sizeof(B)==1, as expected. The crucial point of such a change is IMHO the interface. Breaking noncopyable is bad, so I'd like to add noncopyable_<T> and make noncopyable a typedef to noncopyable_<void>. This should provide backwards compatibility and provides users with a better, but less brief alternative in case they need the additional EBO opportunity. Comments? Since it's so damn short, here's the suggested implementation: namespace boost { namespace noncopyable_impl // prevent unintended ADL { template< typename > class noncopyable_ { protected: noncopyable_() {} ~noncopyable_() {} private: noncopyable_( const noncopyable_& ); const noncopyable_& operator=( const noncopyable_& ); }; typedef noncopyable_<void> noncopyable; } using namespace noncopyable_impl; } Regards, Daniel

5 6

[1.34.1][pool] Open Issues
by Thomas Witt 04 Jun '07

04 Jun '07

There are two open tickets for pool in 1.34.1. http://svn.boost.org/trac/boost/ticket/284 http://svn.boost.org/trac/boost/ticket/991 Any takers? Thomas -- Thomas Witt witt(a)acm.org

4 5

[BoostCon] Presentation material
by Michael Marcin 03 Jun '07

03 Jun '07

Unfortunately I wasn't able to attend Boost Con this year. Is there any materials from the presentations? Videos, white papers, power points? Thanks, Michael Marcin

4 4

typo in boost header: date_time/time_defs.hpp
by Sunil Rao 02 Jun '07

02 Jun '07

Hello, I'm writing to report a small typo a colleague of mine has discovered in the time_defs.hpp header in the date_time library. [Apologies if this is a known issue: I wasn't able to find any specific reference to this in any of the list archives.] http://boost.org/boost/date_time/time_defs.hpp The specific issue is in the time_resolutions enum: "hundredth" is misspelt as "hundreth". Hope this helps -sunil

2 1

[regex] empty expression issue
by impulse9 02 Jun '07

02 Jun '07

Hi All, I've just started to use boost::regex I met with the following incompatibility with Perl regular expressions: It is impossible to use empty expressions, neither alone nor inside of another regex statement. Sample code: #include <iostream> #include <boost/regex.hpp> void check_regexp(const char * text) { try { boost::regex e("(\\d+)\\s*(kbit|)"); boost::cmatch what; if (boost::regex_match(text, what, e)) { std::string item1(what[1].first, what[1].second); std::string item2(what[2].first, what[2].second); std::cout << "matched. " << std::endl << "Value : " << item1 << std::endl << "Units : " << item2 << std::endl << std::endl; } } catch (boost::regex_error & e) { std::cout << "ERROR: " << e.what() << std::endl; } } int main(int argc, char** argv) { check_regexp("96 kbit"); } Program output: ERROR: Empty expression Such regular expressions are quite legal in Perl (e.g. /(Ann|Bob|)/) One possible (quick-n-dirty) workaround for this is to replace boost::regex e("(\\d+)\\s*(kbit|)"); with boost::regex e("(\\d+)\\s*(kbit|.{0})"); Program output would be: matched. Value : 96 Units : kbit Would it be considered as an issue for further improvement? Thank you. -- impulse9

3 4

[guid] - review results?
by Janek Kozicki 01 Jun '07

01 Jun '07

Hello Hartmut, Sorry about being pushy a bit, I'm just curious about the review results. I'd submit a review if I weren't moving from one country to another and defending my PhD during that week, sorry for that ;) -- Janek Kozicki |

13 26

#1013 and 1.34.1
by Vladimir Prus 31 May '07

31 May '07

Would it be possible to apply patch from http://svn.boost.org/trac/boost/ticket/1013 to 1.34.1? This issue has prevented a user from building Boost.Python, and the fix is as safe as possible -- it only changes signatures of two methods so that more than one include path can be passed. - Volodya

2 1