- Boost - lists.preview.boost.org

Boost review of the Convert library is ongoing
by Edward Diener 27 May '14

27 May '14

The review of the Convert library started Monday, May 12 and goes through Wednesday May 21. Many people may have missed the first announcement since the mailing lists were held back when the review started so I am announcing this again. 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.

11 36

Convert library review period has ended
by Edward Diener 26 May '14

26 May '14

The review period for the Convert library of Vladimir Batov has ended. There is one more potential review, from Rob Stewart, by the end of today, as well as any response from Vladimir Batov, I am willing to consider as the review manager. I would like to thank all those who have participated in the review, as well as Vladimir Batov for patiently answering reviews and following up in discussions. I will be working on summing up the discussion and votes on whether or not Convert should be accepted into Boost, and will issue my final decision sometime by the end of this week ( by the end of Sunday June 1 US Eastern time at the latest ). Again thanks to all of those who participated in the review and its discussions. Edward Diener

1 0

Pushing a "Pull Request"
by Christian Henning 26 May '14

26 May '14

Hi all, I'm trying to push a pull request to github but I'm getting an error. I believe I'm the maintainer of the gil library so I should have the permissions. This is the pull request I'm trying to commit to gil's develop branch: git pull https://github.com/gallafent/gil tiff-cmyk After that I'm simply trying to git push but I get the following error: ERROR: Permission to boostorg/gil.git denied to chhenning. fatal: Could not read from remote repository. Could someone please help out? Thanks, Christian

4 4

Boost review of the 'convert' library starts tomorrow May 21.
by Edward Diener 26 May '14

26 May '14

The review of the Convert library starts tomorrow Monday, May 12 and goes through Wednesday May 21. 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. 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. 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.

4 10

Last weekend for review of the Convert library
by Edward Diener 25 May '14

25 May '14

This is the last weekend 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.

2 1

Boost.Rational: improve operator+= and operator-= for param_type
by Morwenn Ed 25 May '14

25 May '14

It is possible to provide an implementation of operator+=(param_type) and operator-=(param_type) for the rational class that could be more efficient than the current one: template <typename IntType> inline rational<IntType>& rational<IntType>::operator+= (param_type i) { num += i * den; return *this; }The operation should never denormalize the fraction. Actually, the same optimization is already used in operator++ and operator--. It allows not to convert the param_type into a rational before adding it. Morwenn.

1 0

[review] convert
by Matus Chochlik 25 May '14

25 May '14

Hi, Here follows my review of the convert library: - What is your evaluation of the design? ---------------------------------------------------------- The design of the interface with the post-review changes (the one returning optional<T>) is sound and flexible even if little too verbose for certain cases. The reason why I still write my own converters in applications is that I don't like the interface of lexical cast that does not provide a nothrow option. If Convert is accepted to Boost this would make my life easier. In regard to the verbosity, I understand that it is so for the sake of flexibility, but if possible I would like if one of the available converters was labelled as default (the stringstream-based one?) and a new variant of convert accepting only the input value and internally constructing and using the default converter was added. This is however not a condition for accepting the library. - What is your evaluation of the implementation? >From the quick glance I've had at the sources it looks acceptable. [nitpicking] Some of the code is indented using 4 spaces and the rest using tabs. This looks awkward and is difficult to read on editors with tab width other than 4. [/nitpicking] - What is your evaluation of the documentation? ---------------------------------------------------------- Why is the motivation section placed towards the back? This section IMHO belongs to the front. Otherwise acceptable. - What is your evaluation of the potential usefulness of the library? ---------------------------------------------------------- Very useful, even to the point that I'd like to have it in the standard (one day soon). - Did you try to use the library? With what compiler? Did you have any problems? Yes, with gcc 4.8.1. I've built and run the `test_convert.cpp` test case. It build without problems, but I had to change the hardcoded locale for it to run without errors. Also, the makefile in `test/` references files outside of the library source tree. I've also tried it on some of my own very simple applications which all ultimately built and ran without errors. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In total somewhere between 2 and 3 hours. I've read the docs and some of the reviews here, I've at least scrolled through all source files, and had a look at some parts that I was interested in. - Are you knowledgeable about the problem domain? As knowledgeable as anyone who had to write his own converters for argument values or text input many times. - Do you think the library should be accepted as a Boost library? Yes, if the new interface returning `optional<T>` is used. Best regards, Matus Chochlik

1 0

Re: [boost] Using Program Options styles to format options_description output
by Arindam Mukherjee 24 May '14

24 May '14

Including boost(a)lists.boost.org. On Fri, May 23, 2014 at 11:08 AM, Arindam Mukherjee <arindam.mukerjee(a)gmail.com> wrote: > One of the things I want to do when I use Program Options is to print > the help according to the styles I am enforcing. For example, on > Windows if I use allows_slash_for_short, it will make sense for me to > reflect that when I print the actual help string. I can't find a way > to do this. Any pointers? > I noticed that the option_description::format_name() method, which is called to format each option while streaming the help message, hard codes the leading characters of the long and short options and as a result there is no way to print the description based on the style I am enforcing. This seems like a serious bug to me. If I am using a style in which options are introduced with a leading forward slash (which is supported) or long options are introduced with a single rather than double hyphen (which too is supported), then I'll end up printing misleading description. I'll try to patch this in my private build without breaking existing interfaces. Would be keen to know if there would be any general interest in such a patch. Regards, Arindam

1 0

[Filesystem] Proposal: make filesystem generic-programming friendly
by Alexander Lamaison 23 May '14

23 May '14

Dear all, I'm increasingly finding that I need to write programs that can operate over multiple kinds of filesystem, including the local filesystem, network filesystems such as (S)FTP, filesystems in archives such as zip files, and mock filesystems that exist only in memory for unit testing. This is not as easy as it could be. The difficulty is that the Boost.Filesystem API makes it difficult to write generic code that uses the local filesystem as just one of several API-compatible filesystems. Therefore, I've written a proposal for making a backward-compatible addition to the Boost.Filesystem API that would make it much more friendly to generic programming. It is a first draft and I welcome your comments, criticism and suggestions for improvement. The proposal is available here: http://alamaison.github.io/2014/01/09/proposal-generic-filesystem/ and I've included a text-only version below. Alex Proposal: Generic filesystem API ================================ [FIRST DRAFT] C++ streams provide a common interface to operate on file-like data, regardless of how that data it is actually stored. However, programs often need to operate not just on data from different file sources, but also on entirely separate filesystems. The problem ----------- There is, currently, no way to operate on different filesystems generically, if Boost.Filesystem is to be one of those filesystems. The local-filesystem operations in the Boost.Filesystem API make it difficult to call them generically because they, inadvertently, defeat ADL, so generic code cannot resolve them to specific implementations. For example, how do you write code that calls `path temp_directory_path();` and can operate on both the local filesystem, via Boost.Filesystem, and on a filesystem over FTP, via an FTP library? If both libraries declare the function, how do you resolve the correct implementation? You can't use a namespace as a type. Normally, ADL is the solution to the problem; it resolves the correct namespace based on the namespace of the operation's argument(s). But `temp_directory_path()` doesn't take an argument. The source of the problem is a misconception that the free-functions performing FS operations are part of the `class path` API, when really they are part of the API of an implicit local-filesystem object. The Boost.Filesystem FAQ asks: > **Why are paths sometimes manipulated by member functions and > sometimes by non-member functions?** > > The design rule is that purely lexical operations are supplied as > class path member functions, while operations performed by the > operating system are provided as free functions. This is wrong because the majority of the non-member operations don't manipulate paths at all. They are functions that manipulate the filesystem, some of which use a path, and, therefore, are really part of the API of an implicit local filesystem object. The proposed solution (later) just makes this explicit, in a backward-compatible way. Is modifying Boost.Filesystem necessary? ---------------------------------------- Before we discuss our proposal, let us explore how much can be achieved without any changes to Boost.Filesystem, using the typical ADL approach to generic programming. ### Limited solution: ADL on filesystem-specific path If each filesystem were to declare a `path` class conforming to the `boost::filesystem::path` interface, ADL could resolve a *subset* of the filesystem operations. The example below implements a simple generic algorithm, `remove_if_temporary` over both Boost.Filesystem and an imaginary `ftp_filesystem`. #include <iostream> #include <boost/filesystem.hpp> namespace ftp_filesystem { class path { public: path(const std::string& server, const std::string& location) : server_(server), location_(location) {} std::string string() const { return location_; } /* ... */ private: std::string server_; std::string location_; }; void remove(const path& target) { std::cout << "Removing " << target.string() << " over FTP" << std::endl; }; } template<typename Path> void remove_if_temporary(const Path& file_path) { if (file_path.string()[file_path.string().size() - 1] == '~') { remove(file_path); } } int main() { remove_if_temporary(boost::filesystem::path("/tmp/bob")); remove_if_temporary(boost::filesystem::path("/home/bob~")); remove_if_temporary( ftp_filesystem::path("ftp.example.com", "/tmp/bob")); remove_if_temporary( ftp_filesystem::path("ftp.example.com", "/home/bob~")); } The key to this solution is that each filesystem's namespace maintains a separate `path` type. The algorithm is instantiated with different path types, allowing ADL to resolve the necessary implementations. However, this is not a good solution because it is continues the pretence that operations are part of `class path`, but this pretence only stretches so far. The result is that: 1. Operations that don't take a `path` argument can't be used in generic algorithms. Some operations, such as `temp_directory_path()` just *return* a `path`. ADL won't resolve those. 2. `path` becomes coupled to a particular filesystem. `boost::filesystem::path` is a currently a good abstraction of many filesystem's path representation, but making it as the ADL key that resolves operations to their implementation means that other filesystems can't use it as their path representation (would `BOOST_STRONG_TYPEDEF` solve this?). 3. `path` must carry filesystem instance data. The local filesystem is a singleton so its path only needs the location-on-disk string. But other types of filesystem may be instantiated with host names, authentication information, running network sessions, etc. The path instances have to carry this extra baggage. In addition, important parts of the API, namely file opening/creation and directory iteration, can still not be used generically, without changes to Boost.Filesystem, because they are *classes* constructed with a `path`, rather than free functions taking a `path` argument. Solving this will need additional factory functions for each class so that ADL can resolve them. **In summary**: generic filesystem programming is possible with no changes to Boost.Filesystem if generic algorithms don't open files, create files, iterate directories or use any nullary filesystem operations. Even accepting these limitations, the API is not ideal because of undesirable coupling between `path` and the specifics of a filesystem. ### Proposed solution: Add local filesystem object to Boost.Filesystem The main problem with the above solution is that nullary operations cannot be resolved by ADL. In effect, these operations take a hidden local filesystem argument, but, as the argument is implicit, ADL cannot use it to resolve them The suggestion in this proposal is to make the filesystem object explicit so that: - ADL can resolve all the operations using the namespace of this object; or - the operations can be resolved as methods of this object. Either change is backward-compatible. The existing functions remain in place, and code that only uses the local filesystem need never refer to the local filesystem object explicitly. The example below demonstrates the second option. This is my preferred option because all filesystems, except the local one, are likely to implement their operations in terms of private data in the filesystem object. Passing this object to free functions, instead of calling a method, means this private data must be exposed. The example below demonstrates a partial implementation of the additional new `class filesystem`, and shows how to use it generically. #include <boost/filesystem.hpp> namespace ftp_filesystem { class filesystem { public: typedef boost::filesystem::path path; filesystem(const std::string& server) : server_(server) {} path temp_directory_path() const { std::cout << "Querying " << server_ << " for $TMPDIR\n"; return "/tmp"; } void remove(const path& target) { std::cout << "Removing " << target.string() << " on " << server_ << " over FTP" << std::endl; }; private: std::string server_; }; } /* Added to existing Boost.Filesystem API */ namespace boost { namespace filesystem { class filesystem { public: typedef boost::filesystem::path path; path temp_directory_path() const { return temp_directory_path(); } void remove(const path& target) { remove(target); }; private: filesystem() {} friend boost::filesystem::filesystem& local_filesystem(); }; /* Local filesystem is singleton */ inline boost::filesystem::filesystem& local_filesystem() { static filesystem instance; return instance; } }} template<typename Filesystem> void remove_if_temporary( Filesystem& fs, const typename Filesystem::path& file_path) { std::string name = file_path.filename().string(); if (name[name.size() - 1] == '~' || file_path.parent_path() == fs.temp_directory_path()) { fs.remove(file_path); } } int main() { ftp_filesystem::filesystem ftp_fs("ftp.example.com"); boost::filesystem::filesystem& local_fs = boost::filesystem::local_filesystem(); boost::filesystem::path in_temp_dir("/tmp/bob"); boost::filesystem::path temp_by_name("/home/bob~"); remove_if_temporary(ftp_fs, in_temp_dir); remove_if_temporary(ftp_fs, temp_by_name); remove_if_temporary(local_fs, in_temp_dir); remove_if_temporary(local_fs, temp_by_name); } As well as the technical reasons for introducing this change, I believe it better reflects the division of responsibilities between `class path` and the filesystem. Paths are not coupled to the filesystem and can be shared between supporting filesystems. If a particular filesystem needs a different path implementation, that is supported too and it is up to the generic algorithm whether it works with all path implementations or just `boost::filesystem::path` instances. Filesystem details are encapsulated in the filesystem object alone and it performs all the operations using those internal details. The example above implements <code>class filesystem</code> in terms of the existing operations functions so that it will compile with no further changes. A better idea may be to implement the existing operations in terms of the new filesystem object's methods because that better reflects their meaning. Impact on Boost.Filesystem -------------------------- The impact on existing users of Boost.Filesystem should be minimal. The only change they may notice is extra documentation for generic use of the API. ### Backward compatibility No existing code using Boost.Filesystem will need any changes. The existing free functions remain in place as a sensible convenience for the common case where only the local filesystem is needed. ### Additions A new object `boost::filesystem::filesystem` is introduced, along with its singleton accessor function, `local_filesystem`. Depending which of the two API options is chosen: - the operation free-functions are overloaded to take an instance of `boost::filesystem::filesystem`; or - `class boost::filesystem::filesystem` is given methods that perform each of the operations currently in free functions. Even functions `absolute()` and `canonical()`, which may seem to be part of the path API, are really part of the filesystem object's API: they can be implemented solely in terms on `class path`'s public API but not solely in terms of `class filesystem`'s API. Finally, the classes in the API that perform operations on the filesystem, e.g. `fstream`, `directory_iterator` require one of the following changes: - Add factory functions for each class to `namespace boost::filesystem`. Allows them to be resolved by ADL. Generic callers use auto as return type. - Add static factory functions for each class to the `path` class. Allows them to be resolved by ADL. Generic callers use auto as return type. - Add typedefs for each class to `path` class. Callers construct classes directly. Factory functions for streams will require a workaround in C++03 because the standard streams are not movable. TODO ---- - Define filesystem-path concept - Define filesystem concept -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

6 12

Re: [boost] Boost review of the Convert library is ongoing
by Arpit 23 May '14

23 May '14

alex <alexhighviz(a)hotmail.com> wrote: >>>> >>> The benefit is that it defers initialization and thus passes that >>> responsibility from the generic function to the specific converters. >>> >> Let's try staying with mainstream usage examples meaningful for the >majority of users. I'll >>unlikely be persuaded by an esoteric academic (even a real but >>corner-case) example that will have negative impact on the real users. >>Thoughts?.. > >The convert contract you are proposing is quite abstract, so I think >academic arguments are relevant. But your question can be translated to: are >there real examples of classes that are expensive to construct but cheap to >move? Moreover, these classes need to be potential candidates for being >converted to. > >The example you have been using is encryption. Consider the following class >for an encrypted password: > >struct encrypted_password >{ > encrypted_password(const std::string& password) > { > // connect to random number device > // do all kinds of arithmetic to encrypt > // send email to NSA > // m_encrypted will have a minimum size of 128. > } > encrypted_password (password_encryption&& rhs) : m_encrypted >(std::move(rhs.m_encrypted)) > { } > > bool check_password(const std::string& password){} > >private: > std::string m_encrypted; >}; > >Now I can write a converter: > >struct password_converter >{ > void operator()(const std::string& in, >boost::optional<password_encryption>& out) > { > try { > out = password_encryption(in); > } catch(...) { > out = boost::none; > } > } >}; > > > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Boost review of the Convert library is ongoing
by Arpit 23 May '14

23 May '14

alex <alexhighviz(a)hotmail.com> wrote: >>>> >>> The benefit is that it defers initialization and thus passes that >>> responsibility from the generic function to the specific converters. >>> >> Let's try staying with mainstream usage examples meaningful for the >majority of users. I'll >>unlikely be persuaded by an esoteric academic (even a real but >>corner-case) example that will have negative impact on the real users. >>Thoughts?.. > >The convert contract you are proposing is quite abstract, so I think >academic arguments are relevant. But your question can be translated to: are >there real examples of classes that are expensive to construct but cheap to >move? Moreover, these classes need to be potential candidates for being >converted to. > >The example you have been using is encryption. Consider the following class >for an encrypted password: > >struct encrypted_password >{ > encrypted_password(const std::string& password) > { > // connect to random number device > // do all kinds of arithmetic to encrypt > // send email to NSA > // m_encrypted will have a minimum size of 128. > } > encrypted_password (password_encryption&& rhs) : m_encrypted >(std::move(rhs.m_encrypted)) > { } > > bool check_password(const std::string& password){} > >private: > std::string m_encrypted; >}; > >Now I can write a converter: > >struct password_converter >{ > void operator()(const std::string& in, >boost::optional<password_encryption>& out) > { > try { > out = password_encryption(in); > } catch(...) { > out = boost::none; > } > } >}; > > > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Can I get access to Trac
by Andrzej Krzemienski 23 May '14

23 May '14

Hi All, How can I get access to Trac to be able to close tickets related to Boost.Optional? Regards, &rzej

2 1

Gmane web interface is definitely in trouble as it does not show any messages from 21st forward.
by Vladimir Batov 23 May '14

23 May '14

http://blog.gmane.org/gmane.comp.lib.boost.devel It is clear when one tries the unthreaded view. The activity calendar on the left shows no activity/messages in this list from 21st. Something happened midway through 20th May.

3 2

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

[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