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

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