January 2011 - Boost - lists.boost.org

How to specify return policy for object returned as part of a tuple in boost python
by Eddie C. 31 Jan '11

31 Jan '11

Hi all, I have a function that creates a C++ object. Before the refactor, I was returning a pointer from the C++ function, and in the boost python wrapper declaration, I would use boost::python::return_value_policy<boost::python::manage_new_object>. Now I need to return not only just the object, but also some error messages, and the refactor basically changes the C++ function to let it return a tuple: boost::python::tuple create_object_from_description(std::string& description) { ... return boost::python::make_tuple(myObject, errmsg); } How should I specify the return policy with this change? Thanks, Eddie

1 0

[1.46.0 beta 1] Release 1.46.0 beta 1 available
by Beman Dawes 31 Jan '11

31 Jan '11

Boost release 1.46.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/ This release contains one new library, Interval Containers, and numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://beta.boost.org/users/news/version_1_46_0. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

9 13

[Boost Graph Library] larger neighborhood in grid_graph
by Hannes Schulz 31 Jan '11

31 Jan '11

Hi all, i recently discovered grid_graph and found it quite useful so far. However, I would prefer a larger neighborhood in the graph (e.g. 8 instead of 4 for 2D; 26 instead of 6 in 3D). I already started looking into copying and modifying grid_graph.hpp accordingly, but cannot entirely anticipate the complexity of the problem. Therefore I decided to ask here first: - Why did the developers restrict grid_graph to "orthogonal" neighborhoods? - Is a modification of grid_graph worth it, or am I going to throw away everything anyway and should start over anew instead? (without the wrapping overhead, which I do not need) Thank you very much! Hannes

2 1

Git vs SVN - review
by Robert Ramey 31 Jan '11

31 Jan '11

Here's my take on Git vs SVN All VCS systems are an extra layer of hassle. Once I learn enough about them to do the job, I'm happy to forget about them. I'm mostly happy with SVN. I only commit/update occasionally. Most of my time on boost is spent testing on my own machine with windows VC and gcc. I love the windows interface - it's great for someone with my attitude about this. I hate the merging process - it's slow and cumbersome and wastes a lot of my time - when I do it which is only once every three months. So - I don't really have strong feelings about this topic and I'm happy to go along with what ever is decided. I'm just hoping that those who make the decision take into account those of use who are VCS luddites. Robert Ramey

6 9

Testing procedure
by Robert Ramey 31 Jan '11

31 Jan '11

John Maddock wrote: > * I think we could organize the testing more efficiently for faster > turnaround and better integration testing, and much to my surprise I'm > coming round to Robert Ramey's suggestion that we reorganize testing > on a library-by-library basis, with each library tested against the > current release/stable branch. +1 of course, > * I think the release branch is closed for stabilization for too > long, and that beta's are too short. I would hope that implementing the above would make this a non-issue. > Here's a concrete suggestion for how the testing workflow might work: > > * Test machine pulls changes for lib X from version control (whatever > tool that is). > * Iff there are changes (either to lib X or to release), only then > run the tests for that library against current release branch. > * The testers machine builds it's own test results pages - ideally > these should go into some form of version control as well so we can > roll back and see what broke when. > * When a tester first starts testing they would add a short > meta-description to a script, and run the script to generate the test > results index pages. ie there would be no need for a separate machine > collecting and > processing the results. > * The test script should run much of the above in parallel if > requested. > The aim would be to speed processing of testing by reducing the cycle > time (most libraries most of the time don't need re-testing). > +1 to all of the above. Robert Ramey

2 2

[GSoC] Conservancy encourages member projects to apply for 2011
by Dave Abrahams 31 Jan '11

31 Jan '11

This message is forwarded from our umbrella nonprofit, the Software Conservancy:

1 0

[bind] class template 'value' can corrupt compilability of sound code: Ticket #5141
by Joachim Faulhaber 31 Jan '11

31 Jan '11

Hi Peter, list, two days ago I encountered the following situation For a new project I combined some code like: #include <boost/my_lib/my_robust_portable_code.hpp> with some other code #include <boost/malicious/side_effect_code.hpp> #include <boost/my_lib/my_robust_portable_code.hpp> with the effect, that 'my_robust_portable_code.hpp' did not compile anymore. Although I found a fix, applicable to 'my_robust_portable_code.hpp', I think that such a <boost/malicious/side_effect_code.hpp> should generally not be acceptable for independent components of boost. In the concrete case <boost/tread.hpp> has this malicious potential to confuse msvc-[8..10] when it preceded some of my boost/icl code. <boost/tread.hpp> has the potential to break the code of any other boost library and any user code, if those accidentally use certain legal expressions. As the example below shows the corrupted code is not extremely nuts and might occur else were. Fortunately I was able to locate the problem: It's at boost/bind/bind.hpp(112): namespace _bi{ ... template<class T> class value { ... }; ... } //namespace _bi This is a minimal program to demonstrate how 'class value' can confuse msvc: //========================================================= #include <boost/config.hpp> //--- from boost/bind/bind.hpp(112) namespace _bi{ template<class T> class value{}; } //--- affected code --------------------------------------- template <class Type> struct some_attribute { BOOST_STATIC_CONSTANT(int, value = 0); }; template <class Type> struct some_predicate { BOOST_STATIC_CONSTANT(bool, value = ( some_attribute<Type>::value < 0) //error C2059: syntax error : ')' //IF class template value defined before ); }; //========================================================= Although I frankly don't know, how exactly msvc is derailed, it seems to have problems with 'value' in some_attribute<Type>::value < 0 a construction that is extremely frequent due to meta programming conventions introduced by Dave's and Aleksey's boost::mpl. So for a fix I tried to rename 'class value' by something else like 'class _value'. Fortunately this is possible, because the class template is a local implementation object used in boost/bind/bind.hpp only. After renaming, I successfully ran all tests from boost/bind. Find the patch file attached. I have also filed a ticket https://svn.boost.org/trac/boost/ticket/5141 Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

4 9

Interest in a simple buffer abstraction?
by Boris Kolpackov 31 Jan '11

31 Jan '11

Hi, While working on the Boost profile for ODB C++ ORM[1], I was looking for a Boost type to map the database BLOB type to. I hoped to find something that would encapsulate the memory management and provide basic operations like copy (memcpy), append, set all bytes in a buffer to a specific value (memset), etc. Something that I could use like this: class packet { address to_; boost::buffer payload_; public: packet (const address& to, const void* data, std::size_t size) to_ (to), data_ (data, size) { } const boost::buffer& payload () const { return payload_; } }; class socket { public: void send (const packet& p) { ... s_.send (p.payload ().data (), p.payload ().size ()) } }; I found a number of buffer types in asio (asio/buffer.hpp) but they don't do memory management. I also found auto_buffer in implementation details of signal2 (signal2/detail/auto_buffer.hxx) and buffer in implementation details of iostream (iostream/detail/buffer.hxx). But they appear to be purpose-built for the libraries in question. So, unless I missed something obvious, I would like to propose a simple buffer abstraction for inclusion into Boost. Here are some additional motivations: - Seeing that there is a number of library-specific implementations, it is quite clear that such a class is often needed. - If we have a "top-level" buffer class, various i/o libraries could use it in their interfaces which would lead to better library interoperability (i.e., one could receive data from a socket into a buffer using asio and then pass that buffer to iostream or interprocess without any conversions). - A top-level buffer class will be fairly light-weight (perhaps even header-only). Right now, if I am to use a buffer implementation from say, asio, I need to install and potentially link to that library. If the community believes this is a good idea, I will next send the buffer interface for review/discussion. Let me know what you think. [1] http://www.codesynthesis.com/products/odb/ Boris

7 29

Process discussions
by Christophe Henry 31 Jan '11

31 Jan '11

> As of recent, we had quite a lot of discussion about process. In true > open-source spirit, it was a fairly open discussion, with everybody > offering their perspectives and experience. However, while we surely > learned many things, it does not seem like we're going anywhere. > > For a quick experiment, I tried to assess whether the discussion actually > reflects the needs of Boost developers, so I created a table of Boost > developers sorted by the number of commits in 2010. It is here: > > http://tinyurl.com/5suwfbn > > It seems that 5 top Boost comitters did not participate much in recent > discussions. And going down the list, it seems like many of active developers > did not say anything, while most of discussions is fueled by folks who > don't commit much. > > Of course, everybody can offer valuable thoughts, but if the goal is to fix > things for Boost developers, it would make sense if developers say that needs > fixing, as opposed to other people doing it for them. > > Maybe I suggest that for some time, we outright ban freeform discussion about > process, and instead, we restrict them to threads started by a Boost developers > and saying this: "I am maintainer of X, and had N commits and M trac changes > in the last year. I most hate P1, P2 and P3. I would propose that we use T1, > T2, and T3 to fix that". Then, everybody could join to suggest better > way of fixing P1, P2 and P3 -- without making up other supposed problems. > > Thoughts? *sigh* I usually try to stay out of this kind of discussions like svn vs git for 3 reasons: - I very fast stop following what it is about as it goes into depth without explanations. Actually I have the feeling it is more about "being right" than explaining for dolts like me. - I have no problem with svn - I have no time. Really. I don't. But it seems I have to say my word to avoid being faced with a matter decided without me. So my situation is simple. I have no time (I might have mentioned that already ;-) ). And the time I have is costly because any distraction goes at the cost of MSM. I use all my free time to code or imagine cool new features I can add. So either someone can make me get what I'd gain by investing time in switching to git (I repeat, I have no problem with svn, it does what I need with little cost) or for all practical matters, count me against switching. Right now, all I do is commit my development changes into the trunk, then once every 3 months start a long merge operation (which I do in the background, so no cost). How simpler than that can it be? If all I gain is avoiding getting all of boost on my (big) hard disk, then I will happily prefer paying the 1$ / 10GB and keep the time, thanks.

3 3

template-defined regexp proposal
by Vit Stepanek 31 Jan '11

31 Jan '11

Hi, I've implemented the basic regexp functionality using few simple template classes. Any regexp can be created by inserting the template classes one into another in the required order. Although it's in the design state, I'd like to find out if there's any interest in providing this functionality. Let me present you some short introduction to the topic. Some basic classes include - String Match (full string matching) - Is-in Match (matches any character in the list) - Or Match - Quantity and so on. These are the "building blocks" of the regexp. Each class does a very little bit but when combined in the specific order, you gain a clearly defined string matching algorithm of any kind and any complexity. In addition, it's quite simple to add any missing functionality. You just need to define you're desired algorithm and mix it with the others. I add few examples that should describe how's it all done. Regexp: ^[a-z]+ is implemented as: Quantity< Range< char_a, char_z >, 1 > re; (sorry if you don't like the indentation, but that's just to ease the reading) Regexp: ^0(x|X)[a-fA-F0-9]+ (matching the hexadecimal number) The required strings are hardcoded using macro "STRHOLDER", which generates a simple struct containing the given string (to avoid the need of pushing strings in the runtime and thus splitting the matching logic into two levels). STRHOLDER( 0, "0" ); STRHOLDER( xX, "xX" ); MultiTie< StrMatch< StringHolder_0 >, IsIn< StringHolder_xX >, Quantity< OrMatch< DigitChar, OrMatch< Range< char_a, char_f >, Range< char_A, char_F > > >, 1 > > re; The "MultiTie" ties the match parts to the consecutive sequence. Some other examples I tested include - email address regexp - quoted string matching (containing escaped quoting chars) Currently the implementation counts 21 template classes, which are enough to implement (I hope) almost any regular expression. Each "brick" is called using operator ()(). That allows to pass it as an argument to the standard algorithms (like std::replace_if etc). I've already implemented the availability to push parameters to the regexp in the runtime (but that's not the major feature). Some rationale for the defense: String matching is widely applied part of the coding. Often it's also one of the problematic domains (especially when using self-implemented matching functions without any general solution). Once it's done, it can be hard to change it, because all what can be seen is HOW is the match done, but not WHAT does it do. Even when using some higher-level methods, it still isn't self-descriptive. Template-defined regexp provides one solution for this issue by hiding the HOW under the mask of WHAT, and taking the advantage of compile-time check. Only to mention that - the performance is not touched by any kind of interpreting - everything is prepared after compilation (but I don't want to touch anybody's baby here!). Please don't look at: - the proposed name "template-defined regexp", I use it as the temp. name - the naming of the classes - implementation details (yes, they aren't here, because it's not necessary for now) - term "regexp" - I'm not sure if this can be called so... Your opinions are welcomed! Vit Stepanek ------------

3 7