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

boost modularization questions
by Eric Cornelius 13 May '13

13 May '13

Hi all, Out of curiosity, is the plan to move to a git pull-request model once the modularization process is complete? Or is github being used simply as a convenient mirror and interface for browsing code and history? Also, I have some changes to the Jamroot and boostcpp.jam files for improving modularization builds, which aggregate all the public headers from modules into the standard boost/... layout within the install/include directory, as well as implicitly setting up include paths during the initial build process. https://github.com/EricMCornelius/boost/commit/cdc08a1afa4b3df85997d54d9e6a… Cheers, Eric Cornelius

3 2

Boost range - Add variadic join/zip
by Gonzalo BG 12 May '13

12 May '13

Code available here: https://gist.github.com/gnzlbg/5547905 Let, std::array<double,4> a = {{ 1, 2, 3, 4 }}; std::list<int> b = { 11, 22, 33, 44 }; std::deque<int> c = { 111, 222, 333, 444 }; std::vector<int> d = {1111,2222,3333,4444 }; If the values stored in a container have the same type, I would like to iterate over different containers as if it were a single one, and: /// - modify its value for(auto&& i : join(b,c,d)) { i += 1; } /// - use it with boost algorithms boost::transform(join(b,c,d),begin(join(b,c,d)),[&](int j){ return j * 2; }); /// - and read it for(const auto& i : join(b,c,d)) { std::cout << i << "\n"; } Another problem I usually face is manipulating data that has different types. This data is usually stored in different containers for efficiency, but it does belong together. Zip can be used to iterate throw a row of this kind of table-like data structure: for(const auto& t : zip(a,b,c,d)) { std::cout << t << "\n"; } However, boost's zip_iterators are not writable. I don't really think it would be possible to make them writable, but that would allow code like this: typedef decltype(*begin(zip(a,c,d))) tIt; boost::sort(zip(a, c, d), [](const tIt& i, const tIt& j){ return boost::get<0>(i) > boost::get<0>(j); }); which sorts the three containers in lock-step after the values in the first container (a). Some parts of this code can be implemented with minor extensions to boost range. A variadic join might look like this: template<class C> auto join(C&& c) -> decltype(boost::make_iterator_range(c)) { return boost::make_iterator_range(c); } template<class C, class D, class... Args> auto join(C&& c, D&& d, Args&&... args) -> decltype(boost::join(boost::join(boost::make_iterator_range(std::forward<C>(c)), boost::make_iterator_range(std::forward<D>(d))), join(std::forward<Args>(args)...))) { return boost::join(boost::join(boost::make_iterator_range(std::forward<C>(c)), boost::make_iterator_range(std::forward<D>(d))), join(std::forward<Args>(args)...)); } A variadic zip is more complicated. If we want write access we cannot use boost zip_iterator. Still one can use Anthony Williams' TupleIterator: template <class... T> auto zip(T&&... c) -> boost::iterator_range< decltype(iterators::makeTupleIterator(std::begin(std::forward<T>(c))...))> { return boost::make_iterator_range (iterators::makeTupleIterator(std::begin(std::forward<T>(c))...), iterators::makeTupleIterator(std::end(std::forward<T>(c))...)); } For read-only access one could use boost::zip_iterator, but I think write-access is _really_ important (e.g. sort wouldn't work). Would it be possible to add similar functionality to boost range? This code wouldn't work without the help of everyone who participated in the following SO discussions: - http://stackoverflow.com/questions/14366576/boostrangejoin-for-multiple-ran… - http://stackoverflow.com/questions/13840998/sorting-zipped-locked-container… and without Anthony Williams's tupleIterator. See also http://www.justsoftwaresolutions.co.uk/articles/pair_iterators.pdf Bests, Gonzalo BG

5 9

[chrono/date] conversion between concrete dates
by Vicente J. Botet Escriba 12 May '13

12 May '13

Hi, as the conversion between concrete dates could be expensive I guess that these conversion must be explicit. But this has some consequences when used the implicit conversion was hidden a not efficient implementation, e.g. date ISO_week_start = mon <= jan/day(4)/y; jan/day(4)/y should be ymd_date as is the efficient representation. The date generator was declared as date operator<=(weekday wd, date x); but it works efficiently only for days_date. If we provide only the functions that are efficient we should declare it as days_date operator<=(weekday wd, days_date x); So the preceding expression would need an explicit conversion days_date ISO_week_start = mon <= days_date(jan/day(4)/y); Do we want to go on this direction? A radical alternative to the explicit construction, if we want to make evident that the conversion operation could be expensive, is to use a compute_ factory days_date ISO_week_start = mon <= compute_days_date(jan/day(4)/y); Best, Vicente P.S. the generator function is just an example needing explicit conversion.

4 18

[spirit] [lex] semantic actions to handle and manipulate eoi
by Andreas Pokorny 12 May '13

12 May '13

Hi, I want to replace a flex lexer with boost.spirit.lex. We implemented an include-like functionality inside the lexer semantic actions: include { BEGIN(incl) } <EOF> { leaveCurrentFile(); popScannerState(); } <incl> { ".+" { openNewFile(); pushScannerState(); BEGIN(INITIAL); } } Is there a way to do that in lexertl? I thought about extending the spirit file_iterator but found that unwieldy. So I now consider adding a semantic actions that are allowed to change lex::_eoi and the ability to have a eoi token or just a semantic action to handle eoi. Is that a reasonable way of implementing that? regards Andreas

1 0

[1.54.0][release] Provisional schedule
by Daniel James 12 May '13

12 May '13

Hello everyone, I've put up a provisional schedule for the next release on the calendar. You can see it at: http://www.boost.org/development/ It targets a 1st July release date, and follows the usual schedule relative to that date. The deadlines for the release branch are pretty soon, particularly the deadline for new libraries which is just a week away. Also, the deadline for new features is just after C++Now. If any of this is a problem let us know now. The release after that will probably target November 1st (as normal), which will give a 4 month release cycle. If the git modularization is considered ready, this will allow a little extra time to deal with any disruption caused (possibly not enough...). How does that sound? Any thoughts? Daniel

9 34

[GSOC] XML library of Boost
by Amos Ji 12 May '13

12 May '13

Hi All, I'm a graduate student from Fudan University in China. And I hope to contribute some code to Boost during the GSOC. I've scanned the idea page. The ideas in the page are all very interesting and challenging. But what I'm interested in most is XML library, which is at the bottom of page. I think the XML format is the most popular standard for storing information so it's important for Boost to have a good XML library. However, I know Boost contains RapidXML in property_tree library to parse XML file. So what I want to make sure is I need to implement a new XML parser in this project instead of make enhancement for RapidXML. Am I correct? If so, I have some ideas to share with you. In my opinion, an XML parser must be able to do these things: 1. To Iterate over DOM nodes tree; 2. To access the values of nodes and their attributes quickly; 3. To insert or delete nodes or attribute of an exact node easily; 4. To generate new XML from the structure which stores XML in the library. And there are some optional function too: 1. To support XPATH; 2. To validate whether the XML file is valid; 3. To support various encoding; 4. To manage memory better; 5. To support regular expression. The ideas are not mature now. I'll improve them in my proposal. In fact, it's not easy to implement a perfect XML parser but I'll do my best. And I have another question. Who will mentor this XML library project? Thanks for your patience to read this email. Sincerely, Mingchao -- Amos Ji(Mingchao Ji) Master in School of Information Science and Engineering, Fudan University MSN: jmc891205(a)hotmail.com E-mail: jmc891205(a)gmail.com

14 36

[type_erasure] How to have just one behavior from relaxed without inheriting the other behaviors
by Felipe Magno de Almeida 12 May '13

12 May '13

Hello, I need to create a type_erasure::any with just this behavior from relaxed: copy assignment of any uses the copy constructor if it can't use assignable(either because assignable is missing, or because the stored types do not match). But without adding the other behaviors, is there a way to implement this? Regards, -- Felipe Magno de Almeida

2 1

[math][constants] mathematical constants page deserves to be more visible in the documentation
by Andrew Hundt 11 May '13

11 May '13

I believe the Boost.math toolkit mathematical constants are an extremely useful feature, yet it is extremely difficult to find. Every time I try to browse to it I try searching boost.org/libs, then try the math library page and cannot find the links at either of those locations. In fact, I'm not exactly sure how to browse to it and instead use saved bookmarks. I it would be worthwhile if there was some direct link or mention of it on boost.org/libs/math at minimum, and possibly even directly on boost.org/libs . Here is the mathematical constants page I am referring to: http://www.boost.org/doc/libs/release/libs/math/doc/sf_and_dist/html/math_t… Any thoughts on this idea? Cheers! Andrew Hundt

5 7

Re: [boost] Live read-only GIT mirrors of Boost trunk SVN
by Niall Douglas 11 May '13

11 May '13

> on Mon May 06 2013, Niall Douglas <ndouglas-AT-blackberry.com> wrote: > > > My experience with SubGit has been very, very good. I would *strongly* > > recommend it over git2svn. > > Why, have you got a lot of experience with both tools? You'd recommend > SubGit for what job, exactly? Does it modularize? (answer: no). Git2svn is painful. I think anyone who has used it even trivially has found it so. SubGit can map structure arbitrarily, so SVN branches need not become GIT branches, they can become tags or any other kind of git ref. You can apply filters and map one (or more) SVN repo to multiple output GIT repos using those filters, so yes it does do limited modularization. Is that modularization support particularly powerful? Definitely not. With an automated script to generate a ton load of mappings it could approach the capability of KDE's tool, albeit with no range specific filtering available. But its specific purpose is a different use case: live two-way mapping. And for that you necessarily have to restrict the flexibility of output, because they have to map in reverse. > We didn't choose svn2git at random: we started using it because KDE (a > much bigger project than Boost) used it to solve the exact same problems > Boost has to solve: modularization + Git migration. Svn2git is a completely different tool to git2svn. Svn2git is a much superior tool, albeit rather harder to configure (correctly). > You'd have to have some pretty compelling arguments, a complete plan for > migration and modularization, and be prepared to lead the effort > yourself for me to throw out years of planning and coding to use a > different tool. Do you really think you're making a reasonable > suggestion? I'm sorry you have read my confusion that way Dave. I would have hoped that after all the years we have known one another you wouldn't have interpreted my comments in that way. Just to be clear and for the record, I have no compelling arguments, no plan for migration, and I am in no way criticizing your work, your leadership, nor suggesting the throwing away of any planning or coding. I apologise unreservedly if anything in my words appeared that way. I am absolutely sure that you have given this the very deepest of thought and I - as always actually - trust your judgment. I am simply confused. > > I think it would be quite easy to set up a live perfect Git mirror of all > > Boost SVN, > > "Perfect," really? I think you are grossly underestimating some of the > strange ways that the SVN filesystem has been used over Boost's history. > >From http://subgit.com/book/index.html#branches-mapping it's clear that > the SubGit tool isn't equipped to deal with them properly. For example, > there's no revision range limiting in the branch mapping, a feature of > svn2git that we actually *need* to use. Perfect for me means that HEAD and releases work perfectly. I personally feel little priority about perfect preservation of history. > > do a transition period where SVN is writeable but GIT read only, and > > then one day the switch is flipped and it goes the other way > > round. That way anyone dependent on SVN keeps on working, but without > > write access. > > Again, I think a two-way mirror could be a really nice addition to the > existing transition plan, if someone is willing to put in the elbow > grease to set it up. Are you volunteering? We can talk about this at C++ Now next week, but if we were to coordinate our efforts and I have definite approval and support from Boost SC, I have no objection to volunteering for this. There is also the matter that SubGit would probably need some money paid for it as a matter of good faith. I would emphasize that a successful two way mirror does impose substantial restrictions on the variety of modularization possible so long as the mirror is active. That probably is unacceptable to you given your apparent plans. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

2 1

Re: [boost] Git Modularization Ready for Review
by Niall Douglas 11 May '13

11 May '13

> Niall Douglas <ndouglas(a)blackberry.com> writes: > > > Me personally I'd just chuck away any unmappable historical information. > > Chalk it up to a cost of transition. If they really need the history, > > they can go fetch it from the read-only SVN repo. > > I see you've not been keeping up with the list lately ;) Daniel et. al. > suggested doing just that a few months ago and was met with such a chorus of > criticism, they didn't really have a choice but to fix it. Never actually was on this list, not ever, until recently as it's a lot of extra reading. Been involved with Boost for over a decade though. > Personally, I agree with the chorus. After all, the point of a VCS is to have a > history of the code's evolution to a point. The VCS, be it SVN, Git, whatever, is > just a means to get that history. Jetissoning the ends for the means seems > misguided. No, it's a cost of doing an upgrade. Those of you who ever migrated a large CVS to SVN transition know what I mean: stuff gets lost, and actually it isn't important enough to preserve that it requires a quadrupling of transition effort when a read-only copy of the old technology repo is good enough. Distributed SCM is much more dimorphic again, and you *have* to accept some data loss. Let me put this another way: those who want no history loss ought to be the ones volunteering the additional time to preserve history. What actually happens sadly is then the argument becomes we must stick with whatever the old technology is, because people will choose a small reduction of productivity every day over fixing tooling once and for all ("programmers program, they don't do tooling"). I *still* find CVS in use in places because "history must never ever be lost", and given the anti-productivity nature of CVS that costs far more in present developer time than accepting a 5% or 10% history loss, most of which will never significantly matter anyway because it occurs on the edges where SCMs dimorph. > What happens in a few years time when Git is replaced with the next big thing? > Do we lose the history again? And then again when that gets replaced too? That's exactly what happens. Bitrot is always inevitable in the long run. Here call it "non-fatal bitrot" :) My only red line is corruption of past and present source code releases. It must *always* be possible to check out tag X and build release X. Other than that, I'm flexible, including loss of branch integrity, because in the end if that branch is really important its owner will manually fix up the damage. > > I fear that if modularization is taken to its logical extreme, you > > could see submodules get out of step with other submodules. You may of > > course have already anticipated this and have implemented something I > haven't realized. > > As I said, I am confused. > > Can you explain a bit more about what you mean by out-of-step? The whole > point of modularising the code is to *help* modules to get out-of-step and > therefore be easier to develop and test independent of what other Boost > libraries are doing. But perhaps you mean something else? Well, the Git way of helping stuff get out of step is that everyone gets their own full copy of the whole repo, and their copy is just as important as anyone else's copy. You clone, you develop and test, and optionally push changes elsewhere which could be your friend, your team, your employer, or of course some central authoritative copy. So I'm afraid I just don't get the present design for a library as small and as tightly integrated as Boost. Something huge and cleanly separated like KDE sure, but for Boost I suspect it's overkill. Unless Boost plans to grow 10x in the next three years that is. > > [1]: By findable I mean that when Boost library users do #include > > <boost/whatever> they get the main Boost repo version, not the > > submodule version. I absolutely would expect an automated tool to pull > > headers from submodules, check them for ABI breakage and push them > > into the main repo. My point is that some sanity check ought to be there. > > I'm not following why you would want to do this. Perhaps you can explain what > problem you are anticipating and how this would solve it? Most of Boost is implemented in headers, very much unlike KDE or most other C++ libraries. Moreover, those headers are quite brittle, unlike KDE or most other C++ libraries. If broken into submodules, I can see an apparently innocent change in submodule X appearing to compile and be okay in developer X's set of submodule clones, but silently be a breaking change with a simultaneous change in submodule Y by developer Y. Why this matters is because when in git you go to push, git will force you to merge before push and at that point you "see" the breakage by a conflict appearing (hopefully) and if not then your immediate next compile will fail. With the submodule approach that doesn't happen, so you *don't* see the breakage till much later when the regression tests suddenly start failing. I'm a great believer in refusing to let programmers commit code which breaks other code rather than nagging them later to fix an earlier commit. The point of failure notification ought to be as close to cause as possible. > I also don't get what 'findable' means. What would a non-findable header be? Any internal header only findable by internal implementation. What I'm basically suggesting is an approach where the master repo keeps a gold candidate set of headers automatically extracted regularly from the submodules. Then on push a hook can do appropriate black magic to force the pusher to merge headers before the push. Then stuff which is broken appears broken as soon as possible, rather than suddenly emerging many days later. Does this make sense? Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

3 2