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

[iterator] std::sort on zip_iterator (repost)
by Jeremiah Willcock 05 Jun '09

05 Jun '09

(Resubmitting to Boost list because I did not receive any answers on boost-users, nor any helpful answers on the Boost list.) I would like to sort two separate vectors of numbers, treating corresponding elements of the two vectors as tuples and sorting the tuples. In particular, I am only comparing the first elements of the tuples; that may or may not be relevant to my problem. An example program is: #include <vector> #include <algorithm> #include <iostream> #include <boost/tuple/tuple.hpp> #include <boost/iterator/zip_iterator.hpp> struct compare_first_elements_in_tuples { template <typename Tuple> bool operator()(const Tuple& a, const Tuple& b) const { return (a.template get<0>()) < (b.template get<0>()); } }; int main(int, char**) { size_t a_data[5] = {0, 2, 1, 2, 4}; size_t b_data[5] = {1, 1, 5, 3, 7}; std::vector<size_t> a(a_data, a_data + 5); std::vector<size_t> b(b_data, b_data + 5); std::cout << "Before:"; for (size_t i = 0; i < a.size(); ++i) { std::cout << " (" << a[i] << ", " << b[i] << ")"; } std::cout << std::endl; typedef std::vector<size_t>::iterator vec_iter; typedef boost::zip_iterator<boost::tuple<vec_iter, vec_iter> > zip_iter; std::sort(zip_iter(boost::make_tuple(a.begin(), b.begin())), zip_iter(boost::make_tuple(a.end(), b.end())), compare_first_elements_in_tuples()); std::cout << "After:"; for (size_t i = 0; i < a.size(); ++i) { std::cout << " (" << a[i] << ", " << b[i] << ")"; } std::cout << std::endl; return 0; } On gcc 4.0.1, the sort operation results in the element (2, 1) (a pair of corresponding elements in a and b) being duplicated, while the element (1, 5) does not appear in the result at all: Before: (0, 1) (2, 1) (1, 5) (2, 3) (4, 7) After: (0, 1) (2, 1) (2, 1) (2, 3) (4, 7) I suspect the problem is related to the fact that zip_iterator does not return a "real" reference when dereferenced. Am I mistaken about this? Is the code above supposed to work? If not, is there an alternative way to sort one sequence while swapping elements in another in a corresponding way? I am not able to join the two input sequences into a single sequence of pairs because of other factors in the use case for this code. Thank you for your help. -- Jeremiah Willcock

6 24

Change to documentation writing guidelines
by Daniel James 05 Jun '09

05 Jun '09

Hi, I'd like to change the guideline for writing reference documentation to include header and namespace information in the detailed documentation. If you arrive at a page by a link or from a search engine, it isn't always easy to work this out. I'll add them to the list here: http://beta.boost.local/doc/libs/release/more/writingdoc/structure.html#det… Boostbook documentation already includes this. Any objections? Daniel

6 15

[threads] final decision on making parts of Boost.Threads header-only
by JOAQUIN M. LOPEZ MUÑOZ 04 Jun '09

04 Jun '09

Hi, A few weeks ago we had a discussion about the convenience of making part of Boost.Threads, namely mutexes and locks, header-only. Some (including Anthony Williams) supported the idea, others disliked it: http://lists.boost.org/Archives/boost/2009/04/150524.php What the final decision on this issue is? If positive (i.e. favoring the change), can it be expected to be done for Boost 1.40? As a remainder, I've created an associated trac ticket: https://svn.boost.org/trac/boost/ticket/2964 Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

boost trac for upcoming libraries?
by Barend Gehrels 04 Jun '09

04 Jun '09

Hi, Is the Boost Trac system intended for official libraries only, or can we also use it for (to be) proposed libraries? Thanks, Barend

6 6

[lexical_cast] Locale used during conversion
by Adam Badura 04 Jun '09

04 Jun '09

lexical_cast does not allow to pass the locale to be used during conversion. This is justified with analogy of lexical_cast to other casts which all take only one parameter. So lexical_cast always uses the current global locale. A reasonable choice. However I wanted to propose some additional features. It would be useful to provide (lets call it so for now) classic_lexical_cast which would use std::locale::classic() instead of the global one. I just finalized globalization/localization of our application by adding setting of the global locale to appropriate value according to the selected language. I noticed that all of sudden serialized data (mainly projects) stopped loading/saving correctly. The reason was easy to find. Where previously we had XML node named "item1000" we now have "item1,000" in English or "item1 000" in Polish for example. The projects are no longer interchangeable between applications running in different language version. I corrected this by adding our own lexical_cast which resets the global locale to the classic one, calls boost::lexical_cast and finally resets the global locale back. This special cast is used now whenever we are dealing with texts which are not presented to the final user. This works fine however it seems that resetting the global locale often (each time we save a number in the project for example...) is causing significant performance overhead. (Exact tests have not been yet performed but this seems the only change which might have affected all serialization slowdown.) I might reset it before saving the project and then save the project as usually but this is not very handy as I would have to remember to do it each time I am serializing any data. Also other problems are implied. Other threads for the short period of time see different global locale as well and thus might produce bad strings. And in the end it is impractical. It would be handy to have classic_lexical_cast as well as it could introduce some optimizations knowing that the requested locale is the classic one. Another thing is that it would be handy to introduce a function textual_convert (another example name) which would act like lexical_cast but would take the requested locale as a parameter (this is no longer a cast so it may). lexical_cast might take that locale as a second parameter with default value being the global locale so it could still be used just as any other casting. But I suppose this would not be well seen. Thus why not introduce a different function for that (or maybe there already is one?). It seems those changes would not be difficult to implement and could be hidden in the details of lexical_cast easily. What do you think of that? Finally lexical_cast's documentation might mention explicitly that current global locale is used as it does not mention that if I am not mistaken (I haven't found "locale" word in that document). Adam Badura

3 6

Trac unwell?
by Vladimir Prus 04 Jun '09

04 Jun '09

Hi, it looks like Trac is not feeling very well: 1. Opening an issue takes at least 10 seconds, sometimes a minute. 2. Adding a comment to an issue takes equally weird time. 3. From time to time it gives: "Database locked" errors. The page with the error does not have any additional information. Can somebody look into this? - Volodya

5 6

Ticket #637 - Adjusts mpl::pair concept to be compatible with STL pairs
by Joel Falcou 04 Jun '09

04 Jun '09

https://svn.boost.org/trac/boost/ticket/637 Is this feature request still sensible or does fusion make this useless somehow ? If not, I can provide patch+test -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

4 4

trunk vs release
by troy d. straszheim 04 Jun '09

04 Jun '09

From another thread: Steven Watanabe wrote: > AMDG > > troy d. straszheim wrote: >> I've been wondering a bit about this in-syncness recently. >> >> - Does anybody know offhand what the last release was that was >> branched directly from trunk? >> >> - Is there a way to determine, with SVN, how many lines of diff >> there are between trunk and release? I've tried without >> success.... the diff gets to ~80k lines and then the network times >> out. I wonder if I'm doing something wrong. Of course I can get >> some numbers with git but I'm not quite sure I trust them yet. >> >> % git diff --shortstat svn/release svn/master 3505 files changed, >> 209061 insertions(+), 58428 deletions(-) > > This is probably correct as far as it goes. However, it's hard to > tell how much it really means. About half the modified files seem to > be generated html, judging by the output of > > svn diff https://svn.boost.org/svn/boost/branches/release > https://svn.boost.org/svn/boost/trunk --summarize > Hm, that svn command isn't very helpful and runs for ~5 minutes. I'm seeing about 160k lines total changed in actual code (.cpp, .ipp, .hpp). Full report in case anybody is interested: http://sodium.resophonic.com/trunk_vs_release.txt Poking around it looks like the current release branch was created from the fixed 1.34.1 tag in oct 2007 (@ r40341). The 1.34.1 release was in turn branched from... looks like that goes back into the days of CVS, I'll consider it lost. Git maintains that the last common commit between the current trunk and release branches is > 3 years ago: http://gitorious.org/boost/svn/commit/4914d4934fbc7368e2d43e057f6fffdac0f46… So if the trunk is really just a staging area for merges to release, does the notion of having the release branch and trunk 'in sync' at this point make any sense? Why have just one such staging area? -t

13 74

[iostreams] #2406: implementation in header causes link errors
by Vladimir Prus 03 Jun '09

03 Jun '09

Looking at Trac, I've run into the bug above, which seems both fairly severe and easy to fix, so I took the liberty to commit a patch: https://svn.boost.org/trac/boost/changeset/53427 I've tested it on Linux. Can somebody give it a try on Windows? While I've added necessary BOOST_IOSTREAMS_DECL, I might have missed something. Thanks, Volodya

2 1

[parameter] Testing for existence of a parameter, building ArgumentPacks, more lazy return types
by Jeremiah Willcock 03 Jun '09

03 Jun '09

I have a few questions about the parameter library. Please note that I am using argument packs directly, since I am creating them from another data structure. 1. Is there a way to build Boost.Parameter ArgumentPacks from a program? I am currently using many internal data structures of Boost.Parameter (empty_arg_list and such). Is there another interface to use? 2. Is there a way to tell at compile-time whether a particular parameter exists in an ArgumentPack? I currently have a metafunction that uses a special default type and tests for that; is there a more "official" way? 3. I have a case where the default type for a named parameter cannot be instantiated in some cases where that parameter is given explicitly. The operator||() lazy defaults don't seem to work for that because they get the result_type member from my default right away, even if it won't be used. I currently have a hack to work around this using my parameter_exists test and some metaprogramming. The reason I am working on this low of a level is that I am playing with converting Boost.Graph named parameter structures into ArgumentPacks to have access to Boost.Parameter's nicer capabilities and syntax. I thus need to build all of the argument data structures and such within another function and then access them later. Thank you for your help. -- Jeremiah Willcock

2 5