July 2016 - Boost-users - lists.boost.org

Re: [Boost-users] Acquiring and rebuilding C++ libraries on Windows
by LeMay.Steve 06 Jul '16

06 Jul '16

Probably a great topic for CPPCON. Sent from my iPad From: Ernest Zaslavsky Sent: 7/5/16, 8:44 PM To: , Boost Subject: Re: [Boost-users] Acquiring and rebuilding C++ libraries on Windows Hi, And what happened to the native NuGet packages idea? It is quite convenient way to get, use and update third parties. From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Eric Mittelette Sent: Wednesday, July 06, 2016 2:49 AM To: boost-users(a)lists.boost.org Subject: [Boost-users] Acquiring and rebuilding C++ libraries on Windows Hello I’m Program Manager at Microsoft, working on VC++ Libraries team (VC runtime, STL…) We are working on the spec of a tool to acquire 3rd party libraries on Windows. We are targeting mainly OSS libraries, our tool will help dev to rebuild locally from the source code on Windows. Today we have a proto, based on a port tree approach. (having a repo with the build script and the associated patch file) I wanted to have a discussion with the Boost community about this project, and how dev could acquire Boost this way. Feel free to contact me to initiate this discussion, we’ll be happy to share our idea and prototype with you and collect feedback and suggestions. Best, Eric Mittelette Senior Program Manager – Visual C++ (VCLib) Microsoft Corp. CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC and/or its subsidiaries and may contain proprietary, confidential or trade secret information. This message is intended solely for the use of the addressee. If you are not the intended recipient and have received this message in error, please delete this message from your system. Any unauthorized reading, distribution, copying, or other use of this message or its attachments is strictly prohibited.

1 0

filesystem path{}.string() interface brittle when developing cross platform
by Werner Erasmus 05 Jul '16

05 Jul '16

Firstly, I would like to than the author/s of filesystem for their great work and their time. I've recently written some code on Linux where I had to adapt a filesystem::path object to string. I noticed that the return value was of type [const std::string&], and used the same return value in my getter that exposed the underlying string. Moving over to windows, I had strange crashes (undefined behaviour) as result of the type under windows being converted to [std::string]. The reason for the "undefined behaviour" took me a while to figure out. While understanding why the author returned by value (Windows API underlying type not a std::string...), I think that for a specific type, the contract concerning return value "semantics" should no be broken. There is a significant difference between returning by const reference as opposed to returning by value. If the contract cannot be held, the decision should be made to (in the interest of consistency/clarity) to return the same type for all OS's/platforms if the code is to be considered platform independent. This might mean to compromise by returning by value, or to, in the case of Windows (where the underlying string has a different type), cache the string, or at the very least document a *BOLD* note that caution must be taken. I can comprehend that if conversion is required, return by value is the only option. I expect type consistency per type, as this to me is part of the contract of a function. I don't consider this a bug, but would appreciate some response. Kind Regards

3 2

[coroutine2] - exceptions from constructor fail
by Tamas.Ruszkai＠leica-geosystems.com 01 Jul '16

01 Jul '16

2 1