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

Convert library -- Andrzej's review
by Andrzej Krzemienski 23 May '14

23 May '14

Hi, This is the review of the Convert library. My vote is a CONDITIONAL YES: this library should be accepted into Boost subject to conditions described at the end of this message. This is a good and useful library. This is what I needed for a long while: a tool that allows me to convert a string to an int or float, but that would not treat the failure to convert as something unusual, and that would be locale-aware. Convert library offers this. It also offers other things that I fail to appreciate, but I accept that it is supposed to satisfy more expectations than just mine. Your choice of the generic type converter: bool operator()(TypeIn const&, TypeOut&); I think it is the right choice: this is the signature that does not impose any run-time overhead. Unlike boost::convert<TypeOut>::result, which does impose some run-time overhead of copying (or at least moving) the TypeOut. But that's acceptable. If the conversion needs to be super fast, one can fall back to using the converter directly. I appreciate the stringstream-based converter most. About the ability to plug other converters, I am just not convinced. Why would I use other converters? I know, lexical_cast is supposed to be faster in some cases, but if I was interested in this performance I would have used lexical_cast directly. The alleged ability to use this library to change the encoding of the strings or to convert between "related" types like ptime and time_t and Time -- I am not convinced: do you expect such conversions to fail and to report such failure the same way as you report the impossibility of interpreting a string as a float? I personally do not like this trick to force me to type this "from" in "convert<int>::from". If I was only passing my string as an argument, this would be fine, but when I am also passing the converter object, it reads that I am converting from both the converter and the string. But I do not intend to argue over it. You wrote the (good) library, so you have the privilege to pick the name. I am also not convinced about the potential of the 'facade' part. I can see that you can see the potential in it. But to me separating the library into the facade and the stringstream converter adds no practical value. But the stringstream converter itself is enough to stand for the usefulness of library. My condition on the acceptance of the library is that its performance should be improved as indicated by others, in particular, provide move semantics for boost::convert<TypeOut>::result (on compilers with rvalue references). It is enough that you commit to doing it in the future. Regards, &rzej

5 18

[ptr_container] pull request: test values were swapped
by Ben Pope 22 May '14

22 May '14

https://github.com/boostorg/ptr_container/pull/1 Ben

3 12

[container] templated find / [lower/upper]_bound would be really useful
by Sebastian Karlsson 22 May '14

22 May '14

In my case I have map such as: flat_map< pair< TypeInfo, TypeInfo >, ... >, TypeInfo being a wrapper around std::type_info. From this map I want to find lower & upper bound of some TypeInfo in comparison to the first TypeInfo of the pair. Since I can't know the maximum & minimum TypeInfo I can't construct a key_type to search with. In this case it would be great to be able to use find with a templated argument ( in my case I'd overload the comparison for pair and smack in a TypeInfo for comparing against first ). templated find / lower / upper would also have the benefit of being faster if key_type is expensive to create. Overall I can't think of any major downfalls, and the changes would seem to be rather easy to make. Kind regards, Sebastian Karlsson

2 1

Re: [boost] Thoughts on Boost v2
by Michael Caisse 22 May '14

22 May '14

[Robert's input didn't come through. Replying so it shows up in the thread.] On 05/20/2014 08:47 AM, Robert Ramey wrote: > On Monday, May 19, 2014 6:51:51 PM UTC-7, Michael Caisse wrote: > > On 05/19/2014 06:47 PM, David Stone wrote: > > As the author of bounded::integer, I do intend to submit my > library to > > Boost at some point, for whatever that is worth. It's just not in > a state > > that is ready to submit yet (but soon it will be). I suspect that, > as a > > C++14 library, it will have an interesting process getting in, but > maybe > > the next Visual Studio preview will be out by then, which looks > like it > > might support all the features I need. > > > > > > 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. > > I look forward to your submission David. > > > There is one issue that should be addressed. The Current test matrix > doesn't distinguish between C++ versions. If I make a library > which requires C++11 and start testing it, it will fail on all test > platforms which don't support C++11. This creates pressure > to support earlier versions of C++ when we don't there to be. Currently > there is no way to tag a library "test for version >= C++11 only". > We need to tweak the test setup only run tests configurations which > match the C++ version supported by the library. > > Note that this currently cannot be done with the current test markup for > a few reasons: > a) it's extremely tedious > b) now some compilers have switches like -std=c++11 or such so the > markup can't be kept in sync with the actual version > being tested. > > Things that are necessary are: > > a) Each library needs to be marked/tagged as to what it's minimum > version is. > b) Each toolset needs to communicate what version of C++ it corresponds to > c) Only compatible toolsets are actually tested. > > This would show all green results for libraries for which a minimal > version is required - unlike that which happens now. > It would also skip useless testing for unsupported configurations > thereby saving time. > > It would also resolve the whole question of Boost version v2. Each > library can support the version of C++ > without conflict. Older, core components like Config would support > everything while newer more specific > libraries like spirit3 would only support C++14/17 etc.. > >

2 1

[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