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

[graph] [graph_parallel] Named parameters in non_distributed_brandes_betweenness_centrality
by Javier Dehesa 22 May '14

22 May '14

Hi. I'm trying to add an optional named parameter to non_distributed_brandes_betweenness_centrality. I've managed before to do it in the brandes_betweenness_centrality function of the sequential BGL, but here the named parameters seem to be managed a little differently. Currently there is only one optional named parameter, weight_map, but I've seen that here, unlike the sequential version, it is not actually optional, as I cannot compile a call to the named parameter version of the function without providing that parameter. I'm attaching a piece of code as an example of what does and what does not compile. Is this behavior wrong? I suppose it is, but named parameters are kinda obscure for me, so any insight about it would be welcome. My intention is to copy the named parameter collection code from the sequential version, but I wanted to know any advice or comments anyone could provide. Thanks. -- Javier Dehesa

1 0

[typeof] unqualified enable_if in msvc-8.0 code is confused with Boost.Test boost::unit_test::decorator::enable_if
by Menelaos Karavelas 22 May '14

22 May '14

Dear typeof maintainers. I have encountered a problem with typeof on msvc-8.0. boost::enable_if is used in the code (unqualified), and it is confused by msvc-8.0 with Boost.Test boost::unit_test::decorator::enable_if (this happens with the included version of unit test). I have created a pull request for this issue: https://github.com/boostorg/typeof/pull/1 Could you please see to it. Best regards, - m.

2 4

Convert library to use Boost.Optional?
by Andrzej Krzemienski 22 May '14

22 May '14

Hi Vladimir, I have just made one observation regarding the return type. Now, that you are using your custom boost::convert<TypeOut>::result, you can choose what exception type you want to throw from function value(). Your current choice is probably not the best one because you cannot distinguish with a type alone between the failure to convert form string to T from any other std:: invalid_argument thrown in a big program. I recommend that you invent your own type that can derive from std::invalid_argument. This will work fine, but the problem will reappear when you switch to boost::optional, because the latter is a general purpose library and it does not know the history behind the failure. It will throw a generic "empty optional" error rather than something speciffic to conversions. So, there is one disadvantage of using boost::optional. I do not know how important you consider it to be. If it is a deal, and you do not want to invent your own return type. Perhas you could use 'Expected': http://www.hyc.io/boost/expected-proposal.pdf. It is proposed for Standard C++, And I think some work is being done to include it into Boost too. It is similar to Boost.Optional, but conveys more information about the reason of failure. Might be worth considering. Regards, &rzej

2 2

[ANN] libstudxml - modern XML API for C++
by Boris Kolpackov 22 May '14

22 May '14

Hi, libstudxml is an XML library for modern, standard C++. It has an API that I believe should have already been in Boost or even in the C++ standard library. The API was first presented at the C++Now 2014 conference. Based on the positive feedback and encouragement I received during the talk, I've decided to make the implementation generally available. As an example, we can parse this XML: <person id="123"> <name>John Doe</name> <age>23</age> <gender>male</gender> </person> With the following C++ code, which performs all the validation necessary for this XML vocabulary: enum class gender {...}; ifstream ifs (argv[1]); parser p (ifs, argv[1]); p.next_expect (parser::start_element, "person", content::complex); long id = p.attribute<long> ("id"); string n = p.element ("name"); short a = p.element<short> ("age"); gender g = p.element<gender> ("gender"); p.next_expect (parser::end_element); // person The API has the following interesting features: * Streaming pull parser and streaming serializer * Two-level API: minimum overhead low-level & more convenient high-level * Content model-aware (empty, simple, complex, mixed) * Whitespace processing based on content model * Validation based on content model * Validation of missing/extra attributes * Validation of unexpected events (elements, etc) * Data extraction to value types * Attribute map with extended lifetime (high-level API) libstudxml is compact, external dependency-free, and reasonably efficient. The XML parser is a conforming, non-validating XML 1.0 implementation that is based on tested and proven code. The library is released under the MIT license. More information, documentation, and source code are available from: http://www.codesynthesis.com/projects/libstudxml/ Or, you can jump directly to the API description with examples: http://www.codesynthesis.com/projects/libstudxml/doc/intro.xhtml#2 Enjoy, Boris

6 11

Re: [boost] Foundational vs non-foundational libraries
by Loïc Joly 21 May '14

21 May '14

Le 21/05/2014 22:26, Peter Dimov a écrit : > Loic Joly wrote: > >> Internally, some boost classes depend on boost::shared_ptr, not on >> std::shared_ptr. I remember making a suggestion that on platform >> supporting std::shared_ptr, boost::shared_ptr should be a simple >> typedef to std::shared_ptr. It was rejected. As a consequence, it's >> very hard not to indirectly include <boost/shared_ptr> when you >> include any part of boost. Which create issues for people who only >> want to use std::shared_ptr in their code. > > I understand why such a setup would be better for some (most) users. > It would however preclude any further improvements to boost::shared_ptr. > > boost::shared_ptr now supports arrays, for example, and no current > std::shared_ptr does that yet. Agreed, but I have never in my life wanted a shared_ptr to an array... Types such as shared_ptr are IMO crucial, because they are basic vocabulary types, that are part of library interfaces, and allow communication between different parts of the code. To me, the fact that std::shared_ptr is in std, and therefore might be used as a common vocabulary type by anyone anywhere has more value than any bells and whistles that might be added to anywhere::shared_ptr. I agree that we are not here yet. Many concurrent implementations of shared pointers (some of them buggy) exist in many libraries. But I also believe that if boost switched by default to std::shared_ptr, it would give this class enough momentum to make it not only an ISO standard, but also a de facto standard. And it would be a great boon to library compatibility. The possibility to work with an alternative shared_pointer is interresting, mostly to make it evolve in the future, but I think this is an experimental feature. It should not be enabled by default, just like compiler experimental feature are useful, but are best disabled by default and explicitly enabled by people who really want to experiment with them. > >> If I proposed [a library / a patch for an existing library] for boost >> that returned a std::shared_ptr, would it be accepted? I sincerly >> don't know. > > I concede that you'll probably be asked to return a boost::shared_ptr > instead. --- Loïc

1 0

Second week of review for the Convert library
by Edward Diener 21 May '14

21 May '14

This is the second week of the the review of the Convert library, which started Monday May 12 and goes through Sunday May 25. For those who have been to C++ Now please take a look at the library and review it. I am looking for at least a half dozen reviews before I can decide, based on the reviews, whether or not the library should be accepted into Boost. The Convert library builds on the boost::lexical_cast original design and experience and takes those conversion/transformation-related ideas further. * to be applicable to a wider range of conversion-related use-cases, * to provide a more flexible, extendible and configurable type-conversion framework. The Convert library can be cloned from GitHub at https://github.com/yet-another-user/boost.convert. The library follows the modular-boost format. Just clone it to modular-boost/libs in the 'convert' subdirectory and run 'b2 headers' in order to create a link to its header file directory in the modular-boost/boost subdirectory. The library comes with documentation in its top-level index.html or doc/html/index.html file. You can also view the documentation online at http://yet-another-user.github.io/boost.convert/doc/html/index.html. The library is by Vladimir Batov and is a second reiteration with a greater focus of his library that was reviewed in the past. I am Edward Diener and I am again serving as the review manager of the library. If you have used lexical_cast or, like many C++ programmers, have used stringstream to do string-to-type, type-to-string conversions please look at this library. We need reviews of whatever point of view before a library can even be considered a Boost library. Comments, questions, and reviews will all be welcome for the library. Please try to sum up your review by answering these questions: 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: Do you think the library should be accepted as a Boost library? As always whether you do or do not feel that the library should be accepted into Boost please specify any changes you would like to see for the library to be better in your estimation.

1 0

[GSoC] HTTP library traits
by Vinícius dos Santos Oliveira 21 May '14

21 May '14

Hi, I've been working on the HTTP library that will later be proposed to inclusion on Boost. I still don't have a working example to show and some uncommited and incomplete changes to documentation generation (still learning QuickBook) and changes to the acceptor (don't bother to ask) are laying around on my system. I can hunt all these on my all and I'll ask for design ideas later. The reason for this email is to ask for help from template meta programming ninjas to rate the skel of my traits implementation. It took me a whole day (first time I had the opportunity to play with SFINAE) to write this and I don't know if I'm following good practices or so on: - https://github.com/BoostGSoC14/boost.http/blob/b9c596249e39eea26fe1b59377cc… - https://github.com/BoostGSoC14/boost.http/blob/b9c596249e39eea26fe1b59377cc… -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

2 3

(Fwd) Re: Thoughts on Boost v2 (was: Re: Is Boost dead? [Re: Anyone is interested in being review manager of ‘Applic
by Niall Douglas 21 May '14

21 May '14

And the other one, probably the one people actually wanted .. N ------- Forwarded message follows ------- Date sent: Mon, 19 May 2014 10:04:22 -0700 (PDT) From: Robert Ramey <robertmacleranramey(a)gmail.com> To: boost-devel-archive(a)googlegroups.com Copies to: boost(a)lists.boost.org, boost(a)lists.boost.org, s_sourceforge(a)nedprod.com Subject: Re: [boost] Thoughts on Boost v2 (was: Re: Is Boost dead? [Re: Anyone is interested in being re view manager of `Application´?]) Ahhhh - not only provocative but actually concrete enough to comment on: Here goes On Friday, May 16, 2014 10:10:51 AM UTC-7, Niall Douglas wrote: > > > 2. Everyone recognises there are serious problems with process, > everything from how you were treated Stephen when you tried cleaning > out cruft and only really Dave supported you, This effort may have been well intended - but is ill conceived and had major flaws in approach and execution. I don't want to re-debate this here so let's just agree to not use this as an example of anything. right through to the > fact that peer review simply doesn't work any more. There is wide agreement that there are problems here. The boost library incubator (www.blincubator.com) is a major effort to address this. We'll see if this helps. The Boost > community has become quite selfish in recent years, as you would > expect from those with a vested interest in the status quo before > evolution. And for the record, I have no problem with those vested > interests keeping their existing Boost, It's hard to attribute motives to a person - much less than an organization. > but I personally want as far away from C++ 03 as soon as is possible. > Not everyone has that luxury. 3. All the interesting new C++ 11 libraries you find around the > internet have zero interest in trying to join Boost, with a very few > honorable exceptions. That speaks volumes, to me at least. > Without seeing a list of these, it's hard to comment. Which suggests to me a need for a new Boost which attempts to apply > the benefits of hindsight to what we learned with Boost v1. Hmmm - not to me. Note that the problem of various C++ versions has existed since the beginning of boost. Not differing standards but no compiler implement the whole standard and all had bugs. This was addressed by a couple of things. a) Boost.Config which abstracted all the platforms to a common interface. b) An explicit policy that no library be required to be backward compatible or be compilable by any buggy or out of date platform. Many authors have made their libraries backward/buggy compatible in the interests of getting wider usage - but that has not been a boost requirement. c) Though it has not been explicitly stated, (maybe it should be) all libraries should be (and I believe they are) build able and testable with any compiler which meets the latest standard. Now, it > is extremely clear from this conference there is little appetite for > that, but I think later on this year we're going to have three C++11 > libraries in the queue, no problem. And here is what I think should be in a fork of Boost: > A fork of boost would be a spectacularly bad idea - it would mean the end of boost as we know it. > 1. Minimum required compiler feature set will be VS2014's. Hmm - I'm not sure what this means. I believe that all libraries current build and test under the latest C++ compilers. > No use of Boost STL permitted where the C++ 11 STL provides a feature. > This is for the library review process to determine. 2. cmake instead of Boost.Build. There is mixed history regarding boost tools. In some cases things have worked well other cases less so. A big problem is that boost has imposed which tools must be used. It seems you're comfortable with this - but just thing the tool choices need to be updated. I think this is the wrong approach has has contributed to our recent difficulties in evolving to the current software development landscape. I believe we will eventually want to pull back from tool selection specifics and move toward specifying tool requirements. More less like the boost documentation toolset situation. There is no specific requirement as far as toolset but it's wide agreed that documentation is required and that meet some sort of standard. (though that standard hasn't really been explicitly defined - we all think we know what it is). > 3. Eliminate peer review in favour of a suite of automated libclang > based AST analysers. Instead of persuading people to review > libraries, persuade them to review and improve the AST analysers. > I'm trying to restrain myself, but this idea is so naive as to be ridiculous. 4. Mandatory cross platform per-commit CI with unit testing exceeding > 95% coverage. We don't care what unit test library is used so long as > it can output results Jenkins can understand. > These kinds of mandates are a bad idea. No one can predict the future with the precision necessary to make them. > > 5. Mandatory all green thread, memory, UB sanitisers and clean > valgrind. All also tested per-commit. > lol - see above. > 6. Mandatory CI testing for exception safety. I am hoping a clang > rewriter can basically patch all exception throws and have them > randomly throw for testing. > again - not realistic given our variety of environments. > 7. Per-library source distributions instead of a monolithic blob. > This implies some dependency management, I agree with this. Though the scale of the effort seems way under estimated - as usual > but cmake makes that much easier. CMake is not nearly up to this job. In fact, I haven't seen any tool that can actually work for dependency management in our context. Actually, other than John Maddocs post on the problem), I haven't seen any posts which demonstrate an understanding of the problems with this. > It also means we can eliminate the release cycle because each > library does its own release cycle, OK - we've got that now with modular boost whenever anyone merges their develop branch to master. We do need to agree on per library versioning scheme though. and the correct (i.e. tested) > version of dependencies are included into each per-library source > distro. This is never going to be all that reliable. This solves the version lock problem currently plaguing > git-ised Boost, at the cost of pushing the version lock problem onto > users [1]. I don't know what this means. > BTW I want to see a soak test of the unit tests for 24 > hours be all green before a release. > For now I would say that a Boost Release would be: a) All master branches would be tagged with Boost.1.xx b) All tests are run on this branch - if everything passes that Boost 1.xx become the release and git export is used to create the tar, zip, et This purpose of this is catch errors where some library has changed it's interface and broken any dependent libraries. I think (though I'm not sure) that this is inline with your idea above > > 8. Reusable utilities in a submitted library need merging into some > common utilities library which follows the STL conventions. Other > than that, no source code, naming conventions, namespace or anything > else needs converting or changing. We are looking for very high > quality C++ libraries, nothing more. Obviously if someone hopes for a > library to enter the C++ 17 STL they'll need much more rigour, but > that's up to them. > I don't understand what you're getting at here. But .. I think we will evolve a classification scheme which distinguishes levels of dependency a) std b) boost::core e.g. config, mpl c) boost::application e.g. odint, seriaiization? Basically to be able keep out circular dependencies and depency explosion. 9. There is no longer an "in" or an "out" for distribution. I'm > thinking of a scorecard page where member libraries are ranked by how > high quality they are according to all the automated review, so when > I say "mandatory" above, I simply mean they don't get to appear on > the main downloads page without that precondition. All submitted > libraries do appear though, just ranked very low if their quality is > low. I would hope all this is generated from a database and requires > very little human input. > This has merit but the explanation isn't concrete enough. Here's my take on this. Boost has a number of aspects a) lists and communication and community b) library certification via reviews and acceptance c) creation of a monolithic "product" c) testing d) deployment. In the future I would expect to see something different a) community - same as above b) library certification via reviews and acceptance - same as above. c) deployment of closed subset. subsets would be selected either by users when they download (e.g. cygwin) or by third parties (e.g. some embedded systems vendor includes a subset with his IDE). Hopefully boost could then better focus on what only boost can do - certify some specific level of quality. 10. BoostBook documentation using the Boost look and feel becomes > mandatory. I've had enough with library authors thinking they can > improve on BoostBook's output with things like using Comic Sans as > the font or weird colour schemes throughout. > LOL - i hear you. But it's not a great idea to make a big deal about this stuff. We can't really do a good job and we would spend huge amounts of time on trying agree on stuff which is less important. To grow boost has to narrow it's focus - not expand it. > So, basically, in some areas requirements are significantly > tightened. In other areas requirements are significantly loosened. > The aims of the above ten items are as follows: > > 1. To reduce the amount of human work involved in maintaining Boost. I think your specific suggestions would expand the amount of work required to maintain a working boost by a very large amount. Actually just agreeing on what to do would be huge. And it would result in bad decisions being taken since only a few could have the time to participate. What Dave and Daniel had to do for the git conversion last year was > far above what anyone should ever feel they need to do. > lol - right - should we have not made the conversion? > > 2. To decentralise Boost, letting it scale up far better. > Correct. 3. To provide a gradual process of entering Boost which authors can > tip away at slowly with automated scripts slowly improving their > rankings instead of the current "lumps" of high intensity output and > the review approved/failed scheme currently used. > Not clear what you mean - But If you look at the Boost Library Incubator it has exactly that idea. Reviews can accumulate until it becomes clear that a library should be accepted or rejected. It doesn't replace the final review. Maybe someday it might, but I doubt it. 4. To incentivise authors to maintain their libraries as the quality > bar is improved - the automated scripts will start to drop library > rankings as the quality is raised, thus dropping that library in the > overall rankings. Rather more importantly, it provides a natural > "deprecation" mechanism, something sorely lacking in my opinion from > present Boost. > This is also on the right track. I think the idea of a "deployment subset" as stated above will address this. Eventually I expect that some libraries (e.g. those which have std equivalents) would be dropped from standard deployments. They would still be approved boost libraries though. I would deprecate the word "deprecate" as it has a perjorative flavor. But rather characterize these libraries as "not part of standard (or minimal or core, or...) deployment. That, the set of deployed libraries would not be the same as the set of "boost certified" libraries as it is now. In fact, I'd like to see boost get out of the deployment business all together eventually. Robert Ramey > > Thoughts? > > [1]: If this model proves popular as we can get a regular donation > stream going, we could deploy an automated SHA stamper which through > unit test iteration, figures out which SHAs in which combinations of > libraries are compatible. Then you could safely mix library A's > distro with library B's distro. I'd imagine Debian upstream et al > might be coaxed into providing for this as they need one unified set > of compatible libraries. > > Niall > > -- > ned Productions Limited Consulting > http://www.nedproductions.biz/ > http://ie.linkedin.com/in/nialldouglas/ > > > ------- End of forwarded message ------- -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

(Fwd) Re: Thoughts on Boost v2
by Niall Douglas 21 May '14

21 May '14

Seeing as the original did not reach the mailing list. N ------- Forwarded message follows ------- Date sent: Wed, 21 May 2014 07:02:20 -0700 (PDT) From: Robert Ramey <robertmacleranramey(a)gmail.com> To: boost-devel-archive(a)googlegroups.com Copies to: boost(a)lists.boost.org, boost(a)lists.boost.org, s_sourceforge(a)nedprod.com Subject: Re: [boost] Thoughts on Boost v2 On Wednesday, May 21, 2014 4:49:37 AM UTC-7, Niall Douglas wrote: > > > > We welcome C++14 libraries and I see no problem with a submission on > > that basis alone if it is supported by at least two compilers. > > For me personally, I would vote for an instant rejection for any > library not compilable to the MSVC ABI irrespective of any other > factors. FYI a review is not a vote. Acceptance/Rejection is not a democratic process. The review manager has the authority to accept/reject based on his assessment of the quality of the library independent of the number of "votes" it receives. Long standing boost policy is that there is no explicit requirement that any code conform to any specific compiler as long as it complies with the current standard. There is no requirement that it use specific features (e.g. from more recent standards) to the exclusion of more traditional (albeit still conforming) features. Indeed, a number of libraries have been submitted and accepted that don't compile on multiple compilers. Robert Ramey ------- End of forwarded message ------- -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Boost contributing tutorial (GitHub)
by Adam Wulkiewicz 21 May '14

21 May '14

Hi, I prepared a tutorial about the contributing at GitHub/Boost describing how to create a Fork of a library, use it inside modular Boost and create a pull request. The tutorial presents examples for Boost.Geometry but could be extended to the other libraries. It has a form of a README of this repository: https://github.com/awulkiew/temp-contributing Would you be so kind and see if everything is ok wth it? In praticular I'd like to hear if this model is good for modular Boost in general? Regards, Adam

3 5