- Boost - lists.boost.org

RPC library in the sandbox
by Jon Shuler 02 Mar '09

02 Mar '09

Does any know if the author(s) of this library are still around and plan to make any more updates to it? Jon

2 1

[config] borland/codegear problems with C++0x macros
by Beman Dawes 01 Mar '09

01 Mar '09

* trunk/boost/config/compiler/borland.hpp: It looks like John Maddock and I independently added C++0x macros. The resulting inconsistencies need to be reconciled. The BOOST_CODEGEAR_0X_SUPPORT macro doesn't appear to be documented, by the way. John, do you want to take a whack at this? * trunk/boost/config/compiler/codegear.hpp: Doesn't have the negative C++ macros yet. I'd like to borland.hpp finished before trying to do codegear.hpp. Thanks, --Beman

2 2

RangeEx review
by Phil Endecott 01 Mar '09

01 Mar '09

My RangeEx review follows. I'm afraid that I have not been following much of the ongoing discussion of this library on the list so apologies if I simply repeat what other people are saying. Algorithms ---------- I have always found the verbosity of things like std::sort(container.begin(),container.end()) to be an embarrassing misfeature of the std library so it's good to be able to now write the much more sensible sort(container). Just a couple of comments: - It would be good if the docs were explicit about this being a thin wrapper around your existing std::sort, and identifying those algorithms that are not so thin. - Do we really want this in the top-level boost:: namespace? There have been discussions about sorting libraries for Boost who might also want boost::sort. Would it not be better to put these algorithms in a boost::range namespace? Then we move on to the algorithms where you can select what is returned using a template parameter. This is an interesting idea, but it's a little verbose and I can't think of any precedent for it in the std library or elsewhere in Boost. Being unfamiliar increases the learning curve for a feature. I was wondering if it would be possible to have something more like: boost::unique(rng).found instead of boost::unique<boost::return_found>(rng) Or maybe not; just a thought. You then have this example for sorting and removing duplicates: boost::erase( vec, boost::unique<boost::return_found_end>( boost::sort(vec) ) ); Err... yuk. Why can't I write: unique(vec); Or maybe unique(sort(vec)); or sort(vec); unique(vec); My point is that std::unique only has its "move duplicates to the end" behaviour because the conventional interface with a pair of iterators doesn't let you change the size of the container. Now that we have a unique() that takes a container we don't need that restriction. I recently tried to write a starts_with algorithm: template <typename CONTAINER> bool starts_with(const CONTAINER& a, const CONTAINER& b) { // does a start with b ? return std::equal(b.begin(), b.end(), a.begin()); } The problem with this is that it will crash if a is shorter than b, because std::equal takes only three not four iterators. The fix is to add an additional test: return a.size() >= b.size() && std::equal(b.begin(), b.end(), a.begin()); Unfortunately, for containers where size() is O(N) this makes the algorithm O(N+M), which is especially problematic if the common case if for a difference to be found early in the sequences. So I was curious to see if range::equal addresses this problem: it has the potential to do so since it has access to all four ends of the containers. According to the docs the complexity is "Linear. Exactly distance(rng) comparisons." which doesn't look hopeful, but what "rng" is it referring to? Looking at the source, however, it seems that it does have an optimal implementation. I think this needs a documentation fix. This also makes me wonder if these would be useful algorithms: bool longer(rng1,rng2); bool equal_length(rng1,rng2); bool size_greater_than(rng,size_t); bool size_equal_to(rng,size_t); Adaptors -------- The author seems to be very enthusiastic about chaining functions using operator|. I'm not inherently opposed to this idea but I don't think it should be the role of this library, RangeEx, to provide it. In my opinion this feature should be a general-purpose one. Example: y = sqrt ( sin (x) ); In natural language we may choose to describe that as "the square root of the sine of x" or "take the sine of x and then take the square root of that". If the second of those seems more "natural" to you then you may prefer to write: y = x | sin | sqrt; or maybe even y = (sin | sqrt) (x); I guess that someone who is better at metaprogramming than me could write a general-purpose operator| that can be used in this way. Here's a start: template <typename T1, typename T2, typename T3> struct chained_func { typedef function<T1(T2)> f1_t; typedef function<T2(T3)> f2_t; f1_t f1; f2_t f2; chained_func(f1_t f1_, f2_t f2_): f1(f1_), f2(f2_) {} T1 operator()(T3 arg) { return f1(f2(arg)); } }; template <typename T1, typename T2, typename T3> chained_func<T1,T2,T3> operator|(function<T1(T2)> f1, function<T2(T3)> f2) { return chained_func<T1,T2,T3>(f1,f2); } template <typename T1, typename T2, typename T3> T1 operator|(T3 val, chained_func<T1,T2,T3> cf) { return cf(val); } This feature could then be available for any purpose that the user prefers, including range adaptors, and RangeEx users who don't want to use it can ignore it entirely. (For all I know, maybe this already exists somewhere.) Even if you choose to keep operator| I suggest making the documentation less "evangelical". Quote: "Why do I prefer the operator| syntax? The answer is readbility:" and you go on to show one version that uses operator| and one that doesn't. I would argue that the version using operator| is _less_ readable simply because it uses operator|, and the reader will wonder why you're doing a bitwise OR between a vector and a, umm, a something else. Of course anyone who reads the documentation will understand it, but one of the best features of this library is that, as in the example of sort(container), the functions do "exactly what they say on the tin", and a casual reader of code using it doesn't need to have digested the docs first. Quote: * boost::copy_if( rng, pred, out ) * boost::count_if( rng, pred ) These algorithms are not defined and the reason is that both of them can be expressed by using the original algorithm togther with a Adaptor Generator: The fact that something can be expressed using a combination of other things is not a sufficient justification for leaving it out. For example, sort(container) could be expressed as sort(container.begin(),container.end()) yet you have still provided it. Why should I have to write: int n_zeros = count( container | boost::adaptors::filtered(_1==0) ); instead of int n_zeros = count_if(container, _1==0); ? Summary ------- - What is your evaluation of the design? I would prefer that operator| be factored out. Otherwise I am satisfied with the design. - What is your evaluation of the implementation? I have not properly studied the implementation, but I have not seen any problems in the code that I have looked at. - What is your evaluation of the documentation? Good. - What is your evaluation of the potential usefulness of the library? The basic feature of being able to pass containers to algorithms makes it useful enough to justify inclusion. - Did you try to use the library? With what compiler? Did you have any problems? I did some very basic experiments with gcc 4.1 on linux, with no problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A couple of hours. - Are you knowledgeable about the problem domain? Not especially. - Do you think the library should be accepted as a Boost library? I would prefer to see the operator| stuff factored out, as described above. But given the choice between including the library as-is or not including it at all I would choose to include it as is, since the algorithms alone are sufficiently useful to justify inclusion. Regards, Phil.

2 3

[thread] static thread_specific_ptr?
by k-oli＠gmx.de 01 Mar '09

01 Mar '09

Hello, can I create an static thread specific pointer for class which will initalized by different threads? struct X { static thread_specific_ptr< U > tss_ptr_; }; in some threads: X::tss_ptr_.reset( new U); And for each thread X::tss_ptr_ will point to a different object in the freestore? Oliver

6 8

rule cpp-pch unknown in module Jamfile</D:/boost/trunk/libs/math/build>?
by Peter Dimov 01 Mar '09

01 Mar '09

I'm trying and failing to run the smart_ptr tests because of: D:\boost\trunk\libs\smart_ptr\test>bjam ..\..\..\libs\math\build\Jamfile.v2:8: in modules.load rule cpp-pch unknown in module Jamfile</D:/boost/trunk/libs/math/build>. D:/boost/trunk/tools/build/v2/build\project.jam:313: in load-jamfile D:/boost/trunk/tools/build/v2/build\project.jam:62: in project.load D:/boost/trunk/tools/build/v2/build\project.jam:742: in project.use D:/boost/trunk/tools/build/v2/build\project.jam:89: in load-used-projects D:/boost/trunk/tools/build/v2/build\project.jam:73: in load D:/boost/trunk/tools/build/v2/build\project.jam:115: in load-parent D:/boost/trunk/tools/build/v2/build\project.jam:448: in initialize D:/boost/trunk/tools/build/v2/build\project.jam:303: in load-jamfile D:/boost/trunk/tools/build/v2/build\project.jam:62: in load D:/boost/trunk/tools/build/v2/build\project.jam:168: in project.find D:/boost/trunk/tools/build/v2\build-system.jam:535: in load D:\boost\trunk\tools\build\v2/kernel\modules.jam:283: in import D:\boost\trunk\tools\build\v2/kernel/bootstrap.jam:138: in boost-build D:\boost\trunk\boost-build.jam:17: in module scope -- Peter Dimov http://www.pdplayer.com

4 7

[graph] kolmogorov_max_flow color map, gray state
by Sebastian Nowozin 01 Mar '09

01 Mar '09

Hello everybody, I use the boost graph library to find the linear min-cut of a directed graph with exactly one source and one sink node (s-t min-cut). For this, I setup a linear max-flow problem and solve it using kolmogorov_max_flow. The color_map property is supposed to be usable to recover the edge cut set from the max-flow solution, see the description on http://www.boost.org/doc/libs/1_38_0/libs/graph/doc/kolmogorov_max_flow.html However, as long as there are no vertices colored "gray" I can simply tell which side of the cut a node belongs to by doing something like: std::vector<default_color_type> color(num_vertices(g_ab)); double flow = kolmogorov_max_flow(g_ab, alpha_vertex, beta_vertex, color_map(&color[0])); bool is_left = (color[node_desc] == tc_color_traits::white()); bool is_right = (color[node_desc] == tc_color_traits::black()); And this works just fine. For some problems I am solving there are gray nodes, and I do not know how to determine their position relative to the edge cut set. Is there a code example available in the boost repository or has anyone had this problem? It seems surprising to me that obtaining the edge cut set of a linear min-cut problem seems to be non-trivial using the boost graph library. I must be doing something wrong. Thanks, Sebastian

2 4

Spirit, semantic actions and C++ classes
by Claudio La Rosa 01 Mar '09

01 Mar '09

I am writing a class that implements a simple parser. In the costructor I created the rule and the parser...and I recall the functions for the semantic actions. I have implemented this function as member funcions and, for recalled it, I use a pointer to my member function in this manner: #include <boost/spirit.hpp> using namespace boost::spirit; class MYParser { private: //main rules rule<const char*> rLine, rComment; //This are the “semantic action” void AnnounceComment(char const*, char const*); // ...and this is the pointer to my “semantic action” void (SQLParser::*ptrAnnounceComment)(char const*, char const*); public: MYParser(void); //distuttore ͠ MYParser(); }; MYParser::MYParser() { //(SQLParser::*ptrAnnounceComment)();// = &SQLParser::AnnounceComment; //AnnounceComment is my Member functions ptrAnnounceComment=&SQLParser::AnnounceComment; //make the parser rLine = rComment; rSpazi = *space_p; rTerminal = !ch_p(';'); //commento SQL fino a fine riga rComment = str_p("#") >> (*anychar_p)[ this->*ptrAnnounceComment ]; //... } I obtain an error: “no match for ‘operator[]’ in ‘boost::spirit::operator* [with S = boost::spirit::anychar_parser](((const boost::spirit::parser<boost::spirit::anychar_parser>&)((const boost::spirit::parser<boost::spirit::anychar_parser>*)(& boost::spirit::anychar_p))))[((SQLParser*)this)->*((SQLParser*)this)->SQLParser::ptrAnnounceComment]’” on the line: rComment = str_p("#") >> (*anychar_p)[ this->*ptrAnnounceComment ]; But..why? I have only a little experience with C++ and spirit :-( Ciao Claudio -- View this message in context: http://www.nabble.com/Spirit%2C-semantic-actions-and-C%2B%2B-classes-tp2226… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Bug in intrusive_ptr,scoped_ptr,scoped_array
by Hansi 28 Feb '09

28 Feb '09

Hello, at least with VS2005 there is a bug in the three smart pointers... If you want to check if the pointer is empty (with unspecified bool) then you get also with NULL a true back. For this the following fix should work: #if defined( _MANAGED ) static void unspecified_bool( this_type*** ) { } typedef void (*unspecified_bool_type)( this_type*** ); operator unspecified_bool_type() const // never throws { return px == 0? 0: unspecified_bool; } #else .... #endif Best regards Hansjörg

2 2

[move] Library uploaded to sandbox
by Ion Gaztañaga 28 Feb '09

28 Feb '09

Hi to all, I've uploaded a new version of the move emulation library to sandbox. I've put it temporarily in "move_semantics" folder to avoid overwriting current move code. I've put some quickbook documentation whose introduction is based in the article "A Brief Introduction to Rvalue References" by Hinnant, Stroustrup, Kozicki. http://svn.boost.org/svn/boost/sandbox/libs/move_semantics/index.html The library needs specially modified Interprocess containers (and Intrusive because of dependences), which I've also uploaded to sandbox. The examples show how movable only values can be inserted into containers. For those that don't like svn sandbox (I'm one of them) I've also put the code and the documentation here: http://www.drivehq.com/web/igaztanaga/move_semantics.zip And online documentation also here: http://www.drivehq.com/web/igaztanaga/libs/move_semantics/ The documentation is not in english, it's in my own english dialect so be careful when reading ;-) Patches and corrections welcome. I've documented some functions to create a little boostbook reference. I've invested some precious time in the library and testing different approaches to see if it plays well with containers but I would like to hear some comments on whether the direction is acceptable and if I should spend more time on it. If someone else with more time wants to continue the library, please do it! ;-) I've personally added to the library all that I've seen useful for move-aware containers, so it might lack some features (move aware algorithms, for example). Anyway, my opinion is that we need some move library, better now than later even if it's too basic, so that we can unify all redundant move emulation that we already have in boost libraries. I hope this is a step in the right direction. Best, Ion

11 41

[threadpool] new version - with rescheduling of current task
by k-oli＠gmx.de 28 Feb '09

28 Feb '09

Hi, I've uploaded a new version of boost.threadpool. It contains a free function this_task_reschedule_until() which lets the current task reschedule until a condition (passed to the fucntion) becomes true. This allows to synchronize with other async events without blocking the worker-thread (thx to Vicente). I've also added two function in order to wait for multiple tasks (it uses Anthonies future lib wait_for_any()/wait_for_all() ). Oliver

2 8