- Boost - lists.preview.boost.org

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

[python] Making a Python tuple from a Fusion sequence
by Bruno Lalande 27 Feb '09

27 Feb '09

Hello, I have written a little function that converts any Boost.Fusion sequence into a Python tuple (boost::python::tuple). If a sub-sequence is nested in the sequence, the result will also be a nested tuple (for instance, boost::make_tuple(0, std::make_pair(1, 2), 3) will give (0, (1, 2), 3) in Python). The source code is attached to this mail. The principle is that any sequence previously adapted to Boost.Fusion will become a tuple in Python. So, by including the right boost/fusion/adapted/xxx header, one can convert a pair, a tuple, a boost::array, and obviously any of the sequences provided by Boost.Fusion. For example: #include <boost/python.hpp> #include <boost/fusion/adapted/std_pair.hpp> #include <boost/fusion/adapted/boost_tuple.hpp> #include <boost/fusion/container/generation/make_vector.hpp> #include "make_tuple_from_fusion_sequence.hpp" using namespace boost::python; tuple from_sequence() { return make_tuple_from_fusion( boost::fusion::make_vector( 1, std::make_pair("first", "second"), 2, boost::make_tuple('a', 'b', 'c'), 3 ) ); } BOOST_PYTHON_MODULE(mymodule) { def("from_sequence", &from_sequence); } In Python we get: >>> import mymodule >>> mymodule.from_sequence() (1, ('first', 'second'), 2, ('a', 'b', 'c'), 3) Is there any interest in adding this function into Boost.Python? If yes, I can write the doc and tests, clean the source and maybe improve the implementation (for example, I feel that I could avoid the use of m_iteration with a better use of Boost.Fusion...). Regards Bruno

5 9

another approach to memory management that solves the referential cycles problem
by Achilleas Margaritis 27 Feb '09

27 Feb '09

Dear boost members, I have placed in the boost Vault, under the section "memory", the file 'mm.zip' which contains: 1) a file "readme.txt" with a little documentation. 2) a file 'main.cpp' which contains a reference implementation and test. This (I wouldn't not call it new, but certainly interesting) approach to memory management solves the problem of cycles and it can also provide a sort of garbage collection, without the issues of other approaches (explained in the readme). Suggestions, comments, ideas, etc are welcomed.

3 10

Re: [boost] [geometry] area, length, centroid, behaviour
by Mika Heiskanen 27 Feb '09

27 Feb '09

I wrote: > However, I'd hate to have to produce a certain winding rule for the > exterior and the holes in order to use the same data for more > complicated GIS calculations such as logical operations and buffering. > IMHO it should be just as easy as choosing to use the even-odd filling > rule instead of the winding rule. To which Barend Gehrels replied: > It cannot be called from the algorithms themselves: to > verify the winding rule the area has to be calculated beforehand. This > will drastically decrease performance. Certainly area calculation is significantly faster than logical operations and buffering. > The solution might be a traits class telling the winding rule the > polygon type has. Agreed. [Sorry about the unorthodox quoting, I rebuilt the reply by googling] --> Mika Heiskanen

1 0

Interest check: factory patterns
by Tor Brede Vekterli 27 Feb '09

27 Feb '09

Hi all I've been working on a "Modern C++ Design"-inspired factory/abstract factory pattern implementation for a while now, and was wondering if there was any interest in having it as a Boost library at some point? If my understanding of the existing Boost.Functional/Factory is correct, then this should not really clash with its area of operation. Factory features - Configurable identifier, mapping, error policy types - Function storage type can be overridden by the user on a per-factory basis Abstract factory features: - Auto-generation of class hierarchies (a-la Loki)--allows passing as individual factory fields - Passing of construction-arguments to the concrete type "creators" (operator new by default, but extensible) - Prototypes - Easy (re-)binding of constructor arguments - Boost.Functions if none of the above are appropriate or flexible enough - Mixing and matching creators for concrete factories. i.e., allows to use a prototype for one concrete type, Boost.Function for another, operator new for the third and so on - Easily specify if the created object should be returned as a raw pointer or a smart pointer (any type with a nested element_type is automatically recognized) - Almost everything is policy-specifyable Somewhat contrived example: typedef abstract_factory< // Want object created with no args, returned as raw pointer abstract_foo* // Want object created with std::string const ref, float by value args; returned as auto_ptr , std::auto_ptr<abstract_bar>(const std::string&, float) > abstract_factory_t; concrete_factory< // Concrete factory for abstract_factory_t abstract_factory_t // Concrete creator for abstract_foo; prototype , prototype<> // Concrete creator for abstract_bar; operator new creator (default when it's a regular type) , bar_impl > cf; // Set prototype for abstract_foo (takes ownership of raw pointers) cf.prototype<abstract_foo>(new fancy_foo_impl); const abstract_factory_t& af = cf; // By default invoke clone() on the stored prototype abstract_foo* foobj = af.create<abstract_foo>(); // Forward args to creator, in this case operator new --> constructor of bar_impl std::auto_ptr<abstract_bar> barobj = af.create<abstract_bar>("hello boost", 1234.5f); Preliminary documentation and download link can be found here: http://arcticinteractive.com/static/boost/libs/factory/doc/html/index.html I've yet to request any vault/sandbox access, because I first would really like to get some input on what people who are far more knowledgeable and experienced in C++ and software design than myself think of it :). Critique, comments, suggestions etc. are very welcome on all aspects of the library (code, design, documentation,...) Regards, Tor Brede Vekterli

1 0

Sandbox structure in subversion (was Re: [move] Library uploaded to sandbox)
by Daniel James 27 Feb '09

27 Feb '09

2009/2/17 Ion Gaztañaga <igaztanaga(a)gmail.com>: > > http://svn.boost.org/svn/boost/sandbox/libs/move_semantics/index.html [snip] > > For those that don't like svn sandbox (I'm one of them) I've also put the > code and the documentation here: Most people nowadays are putting their libraries into subdirectories of sandbox, instead of mixing it up with the stuff that's already there. It's much easier to check out and browse online. For example, there's chrono at: https://svn.boost.org/svn/boost/sandbox/chrono https://svn.boost.org/trac/boost/browser/sandbox/chrono It is messy having this in the middle of the old sandbox layout. We could separate out the two although doing this without disrupting development would be tricky. Maybe we could create a new space in subversion and let people migrate to it if they wish. We could use a more traditional subversion layout, perhaps something like: /svn/boost/projects/chrono/trunk /svn/boost/projects/chrono/branches /svn/boost/projects/move_semantics/trunk /svn/boost/projects/move_semantics/branches Daniel

6 10

[iostreams] detecting io errors
by Johan Grafstrom 27 Feb '09

27 Feb '09

Hello, I use boost:iostreams for reading and writing a binary data format. There is currently no use of filters, but the reason for using boost was to try using compression by adding a filter. I have run into some problems/questions regarding the boost:iostreams::stream class though, and was hoping that someone here might give me a hint. The files I save is project files, and the users use a versioning system to lock the files while editing. Occasionally they forget to lock and would get an error when trying to save, since the files in write protected unless locked. My first (and worst) problem was that i did not get any error at all when the write failed, I found out that this was my own fault since I used: bio::stream<bio::file_sink> outs(tstFileName, std::ios_base::out); // ... write etc... if (outs.is_open()) // error ... instead of if (outs->is_open()) // ^^ '->', not '.' must be used here // error ... but it seem like an easy pitfall for newbies like me. A different method name or at least a warning in the documentation maybe? The second problem is that I cannot find any way to get information on the nature of the write error. E g is it an access permission problem or a hardware error? The third problem is that seem to be no way to detect an error when closing the file. I have attached a short c-file to illustrate what I would want to know. I pause and remove the USB-stick with the open file before closing. c-runtime streams will give me error on close, but I cant get the same information out of boost::iostreams. Any help, directions or opinions would be appreciated. Best regards, Johan Grafström /* -*- mode: C++; coding: utf-8-dos; -*- */ /* ========================================================================== * boost_test2.cpp * * Problems: * * * Boost only reports false for outs->is_open() after error but gives no * details (write failure, invalid handle, access violation) * * * An error on file close cannot be detected * * * The worst problem was my own: * using outs.is_open() (always returns true) * instead of outs->is_open() returns false after error * * ========================================================================== */ #include <stdio.h> #include <conio.h> #include <boost/iostreams/device/file.hpp> #include <boost/iostreams/stream.hpp> void boostWriteTestFile(); void streamsWriteTestFile(); void userInteract(); namespace bio = boost::iostreams; char tstFileName[] = "write_test.txt"; int main(int argc, char *argv[]) { // DebugBreak(); if (argc == 2 && strcmp(argv[1],"streams") == 0) { printf("Write using c-runtime stream i/o\n"); streamsWriteTestFile(); } else { printf("Write using boost:iostreams\n"); boostWriteTestFile(); } return 0; } void boostWriteTestFile() { char streamText[] = "Written by boost iostreams api\n"; int msgSize = strlen(streamText); // write using boost bio::stream<bio::file_sink> outs(tstFileName, std::ios_base::out | std::ios_base::binary); int bytesWritten = outs->write(streamText, msgSize); if (bytesWritten != msgSize) printf("Error boost writing\n"); if (!outs->is_open()) printf("Error boost file closed\n"); userInteract(); // Problem: how to get error status from outs.close() ?? // returns void // in boost/iostreams/device/file.hpp:175 // template<typename Ch> // void basic_file<Ch>::close() { pimpl_->file_.close(); } // returns void thus ignoring the return value from // basic_filebuf.close() in c++ runtime <fstream> outs.close(); } void streamsWriteTestFile() { char streamText[] = "Written by c-runtume streams api\n"; int msgSize = strlen(streamText); // write using c-runtime streams FILE *fh = fopen(tstFileName, "w"); if (fh == NULL) { perror("on fopen()"); return; } size_t countWritten = fwrite( streamText, // const void *buffer, 1, // size_t size, msgSize, // size_t count, fh // FILE *stream ); if (countWritten != msgSize) { perror("On fwrite()"); return; } userInteract(); int status = fclose(fh); if (status == 0) { // ok } else { // status == EOF perror("on fclose()"); return; } } void userInteract() { printf("Please remove the file %s, in some apropriate manner e g \n" "remove the floppy or usb-drive, delete with Unlocker or equivalent.\n" "Then press any key to continue.\n", tstFileName); _getch(); }

1 0

[c++0x][trunk testing] regression tests broken
by David Deakins 27 Feb '09

27 Feb '09

Looking at the output from our regression test system, it appears that the recent cpp0x changes have broken regression testing on the trunk. From a cursory review, it looks like some of the .cpp test files now mentioned in libs/config/test/all/Jamfile.v2 did not get merged over from branches/cpp0x. I noticed that the 'no_char16_t_pass.cpp' and 'no_char16_t_fail.cpp' files are missing, along with the char32 tests, the decltype tests, the extern template tests, the long long tests, and possibly more. Beman, do you have time to take a look at this and see which additional files need to be merged over? If not, I could probably take a look but not until tomorrow. And if this has already been noticed and mentioned, my apologies for the redundant post. Thanks, -Dave Deakins

1 0

Formal Review: Boost.RangeEx
by Thorsten Ottosen 26 Feb '09

26 Feb '09

Dear Developers and Users, It's my pleasure to announce that the review of Neil Groves' RangeEx library starts today and lasts until March 3, 2009. What is it? +++++++++++ The library provide two very useful extensions to the range library 1. Range-based algorithms. E.g. boost::sort( rng ); which is a convenient wrapper of instead of std::sort( boost::begin(rng), boost::end(rng) ); But the new interface also allows for more expressive code because (on the fly) composition of algorithms suddenly is possible. 2. Range adaptors. E.g. std::vector<int> vec = ...; boost::copy( vec | boost::adaptors::reversed, std::ostream_iterator<int>( std::cout ) ); where the expression "vec | boost::adaptors::reversed" wraps the iterators of the range on the left in reverse iterators. The library provides a wide range (no pun intended) of Range adaptors, and they are a powerful way to create ranges on the fly and pass them to algorithms. Getting the library +++++++++++++++++++ The library may be downloaded from http://www.cs.aau.dk/~nesotto/boost/range_ex.zip or from the Boost vault under "Algorithms". The docs may be browsed online here http://www.cs.aau.dk/~nesotto/boost/libs/range/ Please note that the documentation is integrated with the current Range ilbrary. Therefore the relevant sections for the review is http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/adaptors.html and http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/algorithms.html The code may be browsed here: http://www.cs.aau.dk/~nesotto/boost/boost/range/ Notice the library is header only (exception: the adaptor tokenized() depends on Boost.Regex). Writing a review ++++++++++++++++ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - 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. Special considerations ++++++++++++++++++++++ Various RangeEx like libraries have been implemented in the past. You might want to compare with those libraries when you form your oppinion: 1. John Torjo's range lib http://rangelib.synesis.com.au/libs/boost-rangelib-20040913.zip http://torjo.com/rangelib/index.html 2. Adobe's ASL libraries include range-based algorithms: http://stlab.adobe.com/group__algorithm.html I'm looking forward to your review. best regards Thorsten, Review Manager

6 12

Crash in boost::gregorian::from_simple_string in BOOST 1.36
by ak1mbox-boost＠yahoo.ca 26 Feb '09

26 Feb '09

Hello, I am using date_time library from Boost 1.36. When running this code: #include <boost/date_time/gregorian/gregorian.hpp> void RunDates() { boost::gregorian::date today(boost::gregorian::day_clock::local_day()); std::string todayString=boost::gregorian::to_simple_string(today); boost::gregorian::date todayFromString(boost::gregorian::from_simple_string(todayString)); } I get a reproducible crash when calling from_simple_string command on the last line of the function. Here is the backtrace: #0 0x961c9a12 in __gnu_debug::_Safe_iterator_base::_M_attach () #1 0x00003029 in __gnu_debug::_Safe_iterator_base::_Safe_iterator_base (this=0xbffff3ac, __seq=0x100698, __constant=false) at debug/ safe_base.h:89 #2 0x00006796 in __gnu_debug ::_Safe_iterator<std::_Rb_tree_iterator<std::pair<std::string const, unsigned short> >, __gnu_debug_def::map<std::string, unsigned short, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned short> > > >::_Safe_iterator (this=0xbffff3ac, __i=@0xbffff35c, __seq=0x100680) at debug/safe_iterator.h:110 #3 0x000068a2 in __gnu_debug_def::map<std::string, unsigned short, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned short> > >::find (this=0x100680, __x=@0xbffff4a4) at debug/ map.h:220 #4 0x00006f11 in boost::date_time::month_str_to_ushort<boost::gregorian::greg_month> (s=@0xbffff4a4) at date_parsing.hpp:68 #5 0x000071cb in boost::date_time::parse_date<boost::gregorian::date> (s=@0xbffff51c, order_spec=0) at date_parsing.hpp:142 #6 0x00007445 in boost::gregorian::from_simple_string (s=@0xbffff51c) at parsers.hpp:35 #7 0x00001f85 in RunDates () at /dates.cpp:18 #8 0x00001e18 in main (argc=1, argv=0xbffff568) at /main.cpp:8 The code was compiled on OSX, gcc version 4.0.1 (Apple Inc. build 5490) with Debug flags, I am linking against dynamic data_time library. Is this a known issue in 1.36 that was fixed in 1.38? going through the list of fixes did not uncover it. The same example compiled with release flags works without problems. I am not certain if this means that I am missing some defines or that release compile misses errors that debug catches. Any help with this is really appreciated! Thank you, Alex

1 0

Question about Spirit architecture
by Bernhard Merkle 26 Feb '09

26 Feb '09

Hi boost developers, The architecture for spirit is documented under http://www.boost.org/doc/libs/1_38_0/libs/spirit/classic/doc/organization.h… my question: should all modules of Core (scanner, primitives, composite, non_terminal) also be independent of each other ? so should they be independent subsystems or are they allowed to have dependencies (within the Core layer) ? thanks for your help kind regards, Bernhard.

3 5

[lambda] warning supression
by Steven Watanabe 26 Feb '09

26 Feb '09

AMDG The attached patch allows Lambda's tests to compile with warnings=all warnings-as-errors=on with gcc-4.3.0 msvc8.0express and msvc-9.0express. Ok to commit? In Christ, Steven Watanabe

3 2

[tuple] gcc warnings
by Steven Watanabe 26 Feb '09

26 Feb '09

AMDG I've tested the fix for #2388 and it looks ok. Okay to commit? In Christ, Steven Watanabe

3 2

best way to remove duplicates from forwardIterator [startIter, endIter]
by Sandeep Gupta 26 Feb '09

26 Feb '09

Hi, Given a collection in terms of [startIter, endIter] how can obtain [uniqBeginIter, uniqEndIter] that represents unique elements of the original container. I can always explicitly instantiate a set S of [startIter, endIter] and use [S.begin(), S.end()]. Is it possible to express this in terms of algorithms. Please note that I won't be able to use std::sort as startIter does not conform to RandomAccessIterator. Its a forward iterator. Thanks Sandeep

3 3

Re: [boost] [convert] Default Syntax Idea
by Vladimir.Batov＠wrsa.com.au 26 Feb '09

26 Feb '09

> From: "Stewart, Robert" <Robert.Stewart(a)sig.com> > I was thinking a bit about syntax for the default value for the > notional boost::convert() and kin. How about the following: > > int const i(3); > string const s("something"); > int const j(convert<int>(s) | 5); Yes, this idea is similar to int j = convert<int>(s).or_default(5); but does not introduce new vocabulary (my main hesitation). With the suggested op|, as I am reading it, it makes perfect reading just like I'd read English. And that is usually my criterion for an interface. So, I am voting 'yes'... in principle. See further below. > convert<DestType,SourceType>(SourceType) can return a type which > throws on failure in operator DestType(), but has an operator > |(SourceType) which returns a second type constructed with the > SourceType value. The second type provides its own operator > |(SourceType) which returns that value in its operator DestType() on failure. When the user does not want comprehensive result, it works. The problem as I see it is when the user wants the comprehensive report -- we return two different types, convert1<string, int> j1 = convert<string, int>(s); convert2<string, int> j2 = convert<string, int>(s) | 5; Sometimes I feel we need that as I might like to explicitly check if the call failed without relying on the default convert1<string, int> j1 = convert<string, int>(s) & boost::nothrow; convert2<string, int> j2 = convert<string, int>(s) | 5; if (j1 == 0 && !j1.good()) j1 = 0 but conversion failed if (j2 == 5 && !j1.good()) j2 = 5 but conversion failed Unless we convert both convert1 and convert2 to convert<string, int>::result as convert<string, int>::result j1 = convert<string, int>(s) & boost::nothrow; convert<string, int>::result j2 = convert<string, int>(s) | 5; if (j1 == 0 && !j1.good()) j1 = 0 but conversion failed if (j2 == 5 && !j1.good()) j2 = 5 but conversion failed Or we might simplify that as convert::result<int> j1 = convert::to<int>(s) & boost::nothrow; convert::result<int> j2 = convert::to<int>(s) | 5; if (j1 == 0 && !j1.good()) j1 = 0 but conversion failed if (j2 == 5 && !j1.good()) j2 = 5 but conversion failed The reason I am sticking 'to' in again is that I need the 'convert' as a namespace... or rather as a namespace-like structure: struct convert : mimic_namespace /*I have such a class*/ { template<class TypeOut> struct result { TypeOut value_; bool good_; }; struct internal_with_default { ... }; struct internal_with_no_default { ... }; template<class TypeOut, class TypeIn> internal_with_default<TypeOut, TypeIn> to(TypeIn const&); }; With namespace-like convert structure people will not be able to shortcut 'convert'. I.e. they'll always have to say convert::to which is darn close to convert_to with the advantage of having a dedicated namespace-like place instead of messing inside the boost namespace. Now it seems like I am back where I started. :-) > Returning a default value in lieu of an exception is a special case; > it ought not be treated like formatting. I have an impression that throwing/not-throwing and providing/not-providing the default have to be configured independently. Like I *might* need to throw even if I provide the default: direction dir = convert<string, direction>(str, direction::up) & boost::dothrow; Above I provide the default because I have to (direction does not have the def. ctor). However, I still *might* like to throw on failure. > Thus, while Boost. > Parameter might be appropriate to package the extra information > desired for formatting, I don't like the idea of writing "default_ = > 5" in the call, and I don't think ", 5" in the argument list is as > clear as it could be. I tend to agree with you on both. > The syntax above is obvious and concise while > being distinct from whatever may be done for formatting. You meant to say "laconic", right? Oh, just kidding. Thanks for pointing it out BTW. BTW, what do you think of convert<string, int>(s) & boost::dothrow; instead of convert<string, int>(s) >> boost::throw_t(); People seem to get put off by op>>. Best, V.

7 11

[optional_io] InputStreamable refinement
by Andrew Troschinetz 25 Feb '09

25 Feb '09

This is a spin off from the thread "[lexical_cast] A suggestion" While trying to get lexical_cast and optional to play nice I've run up against some problems with the InputStreamable solution for optional types in optional_io.hpp. The crux of the problem is that I think any given optional type should behave as much like the type it wraps as possible. For example I think this: stringstream sin ("1.2.3.4.5"); optional<double> token; while (sin >> token) cout << token << endl; Should have the same output as this: stringstream sin ("1.2.3.4.5"); double token; while (sin >> token) cout << token << endl; And that this shouldn't fail: stringstream sin ("test"); optional<string> token; sin >> token; // token shouldn't be empty The current InputStreamable solution for optional does not pass these tests. But that's not all, I also believe that there is room for even more improvement here! Since it's semantically valid to have an un- initialized optional type, I think failure to extract something off a stream should return an empty optional type _without_ setting the failbit on the stream. Here's a usage example that demonstrates what I mean by that: // output is "1 nan nan nan nan 5.5 nan nan nan nan nan nan nan -3.2 nan " istringstream sin (" 1 this 5.5 is a test -3.2 a"); optional<double> token; const double nan = numeric_limits<double>::quiet_NaN (); while (sin >> token) cout << token.get_value_or (nan) << " "; // output is "1 " istringstream sin (" 1 this 5.5 is a test -3.2 a"); double token; while (sin >> token) cout << token << " "; I did submit a ticket with the final comment proposing code that is (maybe?) a solution to this refinement. ( https://svn.boost.org/trac/boost/ticket/2659 ) Please pardon any guffaws I made in replies to that ticket, I'm still learning about the nuts and bolts of streams and boost as I go. However there is still one problem, and this brings us back to lexical_cast. Consider this example: int an_invalid_uint = -1; unsigned i = lexical_cast<optional<unsigned> > (an_invalid_uint).get_value_or (0); I believe we should expect this to store 0 in i, but instead it will throw a bad_lexical_cast exception even with my proposed revision to optional_io.hpp. A possible solution is a specialization for optional<Target> somewhere in lexical_cast.hpp that would replace code that looks something like this (pseudocode): do lexical_cast if failed to cast: throw exception With something like this: do lexical_cast if failed to cast: return optional<Target>() So is there any interest in this sort of refinement of optional's InputStreamable implementation or lexical_cast? -- Andrew Troschinetz Applied Research Laboratories

2 2

Extending asio (SCTP support)
by Hal Finkel 25 Feb '09

25 Feb '09

Hello, I've started implementing SCTP support in asio. I would like some feedback on what methodology is preferred. Although I had originally wanted to provide SCTP support as a pure add-on to the current framework, unfortunately, I don't think that can be done. For example, SCTP supports multi-homed endpoints, and the standard API provides a function sctp_bindx which can add and remove endpoint addresses from an active association (connection). While I can provide a subclass of socket_acceptor_service with this extended interface, there is no way of changing the wrapper (detail::reactive_socket_service) used to implement socket_acceptor_service's service_impl_type, and since socket_, protocol_, etc. are private members of detail::reactive_socket_service, I think that there is no way a subclass of socket_acceptor_service can access the underlying socket object. This seems to leave two options: 1. Patch the missing functionality into the existing classes. What worries me is that this approach does not seem to "scale" well with respect to the addition of new protocols. (what happens if someone needs TIPC support, for example). 2. Provide some kind of protocol-specific extension mechanism (templated base classes for example) for detail::reactive_socket_service and other such classes so that it is possible to provide protocol-specific extensions to the base asio interface. Does anyone have a preference on how I proceed? (or is there an option I've missed?) And if some extension mechanism is desired, is there a preference on the technique used for its implementation? Thank you in advance, Hal Finkel P.S. For anyone looking for a quick introduction to SCTP and its associated socket API, I've found HP's SCTP Programmer's Guide (http://docs.hp.com/en/5992-4578/index.html) to be pretty good.

2 2

[geometry] gtl review pre-announcement
by Simonson, Lucanus J 25 Feb '09

25 Feb '09

Fellow geometry authors and interested reviewers, My abstract for gtl has recently been accepted to boostcon. I was unable to put together a geometry panel discussion, however. I am also working on completing documentation for the library by April. I would like the gtl library to be under review during boostcon because I may get the opportunity to meet and talk to some of the reviewers in person. To that end I'd like to ask for volunteers to be review manager and reviewers of the library now so that it isn't a surprise and things can proceed smoothly when the documentation is ready in a few weeks. I especially want other geometry authors to be aware of my plans and schedule. I have the utmost respect for the authors of the other two serious geometry proposals. It is my hope that we can work together during the review process and after to improve and converge our libraries toward the ideal boost::geometry library that all of us can feel proud of. Eventually it is my hope that algorithms in boost::geometry come for a variety of sources selected based upon quality such that there is no single owner of the library, but rather a community. I look forward to your reviews. Thanks, Luke

1 0