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

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