January 2015 - Boost - lists.preview.boost.org

Re: [boost] [filesystem, regex, asio] These three libraries successfully ported to Windows Phone 8.1
by Moshe Rubin 28 Jan '15

28 Jan '15

On January 27, 2015 09:55 GMT, Paul A. Bristow wrote: >>> And thank you very much for the improved WinRT support. >> >> My pleasure. It was an education for me (in the positive sense of the >> word!) participating in porting Boost. I will only rest on my laurels >> once the port authorized by the crew and back in the repository <g>. > > I'm pleased to see that Windows Phone developers will now be able to use these Boost libraries. When we went looking for Boost ports for Windows Phone 8, we had a sinking feeling because no one had ported any of the libraries to WinRT. Steven Gates of Microsoft took the first step, and was a great encouragement to me and my company. I'm glad to be able to return the favor to the Boost project, as we have benefited very much from this excellent collection of libraries. > I'm also curious to know if you have tried to port the Boost.Math library? > > Although it contains a lot of esoteric mathy stuff that are unlikely to be mainstream on a phone > app, there are also some very simple-to-use statistics stuff that will/should be widely applicable. > > Have you tried this yet? Are there any obstacles that you can foresee? We did not need Boost.Math in our product so I did not look into building it. I'm happy to say that I just now built it for Windows Phone 8.1 on a Visual Studio 12 2013 system and it compiles and creates the resulting libs like a pro: <command> b2 toolset=msvc-12.0 windows-api=phone architecture=arm link=static --with-math variant=debug debug-store=database debug-symbols=on pch=off cxxflags=-ZW stage </command> Libraries created: (*) libboost_math_tr1-vc120-mt-gd-1_58.lib (*) libboost_math_tr1f-vc120-mt-gd-1_58.lib (*) libboost_math_c99-vc120-mt-gd-1_58.lib (*) libboost_math_c99f-vc120-mt-gd-1_58.lib The only warning message received, and there are many of these, is LNK4264: <snippet> msvc.archive bin.v2\libs\math\build\...\libboost_math_tr1-vc120-mt-gd-1_58.lib bin.v2\libs\math\build\...\sph_neumann.obj : warning LNK4264: archiving object file compiled with /ZW into a static library; note that when authoring Windows Runtime types it is not recommended to link with a static library that contains Windows Runtime metadata bin.v2\libs\math\build\...\sph_legendre.obj : warning LNK4264: archiving object file compiled with /ZW into a static library; note that when authoring Windows Runtime types it is not recommended to link with a static library that contains Windows Runtime metadata bin.v2\libs\math\build\...\sph_bessel.obj : warning LNK4264: archiving object file compiled with /ZW into a static library; note that when authoring Windows Runtime types it is not recommended to link with a static library that contains Windows Runtime metadata . . . bin.v2\libs\math\build\...\beta.obj : warning LNK4264: archiving object file compiled with /ZW into a static library; note that when authoring Windows Runtime types it is not recommended to link with a static library that contains Windows Runtime metadata bin.v2\libs\math\build\...\assoc_legendre.obj : warning LNK4264: archiving object file compiled with /ZW into a static library; note that when authoring Windows Runtime types it is not recommended to link with a static library that contains Windows Runtime metadata bin.v2\libs\math\build\...\assoc_laguerre.obj : warning LNK4264: archiving object file compiled with /ZW into a static library; note that when authoring Windows Runtime types it is not recommended to link with a static library that contains Windows Runtime metadata common.copy stage\lib\libboost_math_tr1-vc120-mt-gd-1_58.lib bin.v2\libs\math\build\...\libboost_math_tr1-vc120-mt-gd-1_58.lib 1 file(s) copied. </snippet> I encountered many of these warnings when building my ported libraries. The online documentation seems to indicate that this is a recommendation. I can tell you that the ported libraries, with these warnings, all function correctly with no problems. In short, it looks like Boost.Math compiles as-is for Windows Phone 8.1. Moshe

2 1

Re: [boost] [filesystem, regex, asio] These three libraries successfully ported to Windows Phone 8.1
by Moshe Rubin 28 Jan '15

28 Jan '15

On 28 Jan 2015 at 02:04:22 GMT, Niall Douglas wrote: > And once again, my apologies for earlier. It is no excuse, but that > particular day I had the misfortune of combining codeine and a lot of > cough medicine due to a heavy flu. This affected my mind. I was quite > appalled with myself when I read what I had written to you the next > day, very embarrassing, I was clearly off in a grim imagination land > and had completely underestimated its effects on my wits. > > As a token of making good on my earlier behaviours, do feel free to > email me off list to review your pull requests for any problems, > either before or after you submit them. And thank you once again for > making the effort, it is hugely appreciated here. Rest assured, I harbor no ill will at all. Quite the contrary, notwithstanding the text written, it was obvious you were a battle-seasoned professional and knowledgeable software engineer, one worth listening to. As a newbie to the Boost mailing list, I have gained invaluable information from you and others that will stand me in good stead. The ones to feel sorry for are those involved in the Linux kernel -- Linus Torvalds most certainly does not apologize for his comments! <g> I appreciate your candor, a welcome trait in the professional world. I'm currently working on verifying the changes using the regression test suite, and cleaning up the changes based on the comments you posted the other day. Thank you for your kind offer to eyeball my pull requests before or after submitting them. I will certainly feel free to take you up on your offer. Moshe

1 0

[filesystem, regex, asio] These three libraries successfully ported to Windows Phone 8.1
by Moshe Rubin 28 Jan '15

28 Jan '15

After the helpful advice I received in this mailing list and other forums, I'm happy to report that the three Boost libraries, filesystem, regex, and asio have been successfully ported to Windows Phone 8.1. Our corporate product is back up and running on Windows Phone 8.1 devices. I assume there are others who will be happy to download the new Boost code for use in their WP 8.1 apps. These libraries will hopefully join those already ported by Steven Gates of Microsoft [http://blogs.msdn.com/b/vcblog/archive/2014/07/18/using-boost-libraries-in-…] I am therefore beginning the process of verifying the port using the Boost regression test suite (I have to decide how to get them to run under Windows Phone 8.1). When the code has passed the regression suite I will issue a pull request against the GitHub repository. Thanks again to everyone in this list for their helpful comments and suggestions, Moshe Rubin Technology Manager Hyperlync Technologies Ltd. Jerusalem, Israel

4 5

Re: [boost] [filesystem, regex, asio] These three libraries successfully ported to Windows Phone 8.1
by Moshe Rubin 28 Jan '15

28 Jan '15

On 26 Jan 2015 15:51, Niall Douglas wrote: >> When the code has passed the regression suite I will issue a pull >> request against the GitHub repository. > Some tips for creating a successful pull request: > > 1. Avoid #ifdef spam. Write thunk emulations of missing APIs where possible. Here's an example for GetTickCount64(): > https://github.com/boostorg/thread/blob/master/include/boost/thread/wi > n32/thread_primitives.hpp#L290. Remember Boost still supports Windows XP and exclusively targets an XP level Win32 API. Use GetProcAddress for newer APIs. > > 2. Avoid using macros to implement functionality. > > 3. Don't forget to modify the documentation where needed to support the changes. > > 4. It might sound obvious, but make sure the unit test suite still passes on Windows XP in default build settings on all of MSVC-8, > mingw32 and mingw-w64. You'd be surprised how often pull requests don't because they use some Vista or later API, or an API not supported by mingw32. If a pull request doesn't instantly go all green on all supported platforms it tends to not be merged and get put > off till much later (sometimes forever). > > Right now cygwin support is broken at least in thread, but other libraries are probably a lot better, so test that too. > > 5. Consider additional unit tests where appropriate. In this situation I'd doubt you'd need them. These are excellent points, obviously the product of your own "battles" with modifying the Boost source base. Many thanks for sharing them, and now is the perfect time to learn them. > And thank you very much for the improved WinRT support. My pleasure. It was an education for me (in the positive sense of the word!) participating in porting Boost. I will only rest on my laurels once the port authorized by the crew and back in the repository <g>. Moshe

3 2

[release] Release schedule changes..
by Rene Rivera 27 Jan '15

27 Jan '15

After some discussion in the Boost Release Team we've decided on an ongoing schedule for releases. Taking into account the realities of how long it takes for authors and the release team to work on a release we've decided to move to *three* releases a year. The targets for the releases will now be: * Spring release on the second Wednesday of April. * Summer release on the second Wednesday of August. * Fall/Winter release on the second Wednesday of December. There will be no January release. This will allow for the fact that most people are on extended holidays during Winter. It will also allow for people to work on larger changes that require more testing time during the longer Winter period. We are also moving to Wednesday release to allow the release managers non-weekend time to work before and after the release. Please consult the Boost calendar for specific dates and merge schedule for the next release. Thanks, the Boost Release Team. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

Boost modular: Build without version number suffixes
by Robert Dailey 27 Jan '15

27 Jan '15

When I build modular boost on Linux Mint 17, I get SO files named like so: libboost_date_time.so.1.57.0 with a corresponding symlink without the version number: libboost_date_time.so I'd like it to build without the version number because when I rename the base file to remove the version, code links fine but during runtime it tries to load the SO with the version number at the end. I don't know how to fix that, so I assume the fix is to build boost without the version numbers. Any help is appreciated.

5 8

[doc][build]
by Damian Vicino 27 Jan '15

27 Jan '15

Hi, I noticed the boost.build site links to documentations are broken in http://www.boost.org/doc/libs/1_57_0/tools/build/index.html <http://www.boost.org/doc/libs/1_57_0/tools/build/index.html>: http://www.boost.org/doc/libs/doc/html/bbv2.html <http://www.boost.org/doc/libs/doc/html/bbv2.html> http://www.boost.org/doc/libs/1_57_0/tools/build/doc/userman.pdf <http://www.boost.org/doc/libs/1_57_0/tools/build/doc/userman.pdf> both return 404. I got there following links in installation documentation.

1 0

[endian] [bikeshed] Conversion function naming discussion
by Beman Dawes 26 Jan '15

26 Jan '15

Naming is always a bike shed issue. I'm starting a separate thread for those who don't care can easily ignore it. The current names I'm least comfortable with are the conversion function names in the endian sub-namespace: big_to_native big_to_native_inplace native_to_big native_to_big_inplace little_to_native little_to_native_inplace native_to_little native_to_little_inplace conditional_reverse conditional_reverse_inplace These are quite explicit, but are a bit too long and awkward for my taste. I'd be willing to change these names if someone can come up with replacements that are shorter and less awkward, but still reasonable explicit. --Beman

4 5

Boost 1.58 schedule available?
by Barend Gehrels 26 Jan '15

26 Jan '15

Hi, Boost 1.57 was released last November 3, so it is probably about the time to merge to master again? Is there already a schedule available? Thanks, Barend

13 36

RFC Expression Validity Asserts
by Matt Calabrese 26 Jan '15

26 Jan '15

I've found it useful, especially in tests, to easily be able to do expression validity checking via SFINAE in a static assert. In other words, it's frequently useful to want to quickly test to make sure that a particular expression does or does not compile, similar in some ways to a concepts-lite usage pattern. The general idea is that you want to static assert that, given a series of object declarations of a specific type, a specified expression or series of expressions that deal with those objects would or would not cause substitution to fail had the object types been dependent on a template parameter. It internally relies on a macro that is invoked as such: ////////// IS_VALID_EXPR( (int) a, (float) b, // etc.. (a + b) (a - b) // etc. ) ////////// The above macro invocation results in an expression that is a constexpr bool which is true iff substitution would not fail. With the above macro, one can do, for instance: static_assert(IS_VALID_EXPR((const int) a, ++a), "Some error message."); I've found this pattern so common that I've created a macro that takes such a series of declarations and expressions and automatically produces a simple static_assert, outputting the declarations and the expression that did not compile. A slimmed down version of this macro can be toyed with via the link below (this slim version allows only one declaration and one expression per macro): http://ideone.com/RHd6FM Briefly, using the macro as such: STATIC_ASSERT_VALID ( (const int) a, ++a ); is able to produce a very human-readable error message: prog.cpp:58:1: error: static assertion failed: ******************** Given: const int a; The following expression was expected to compile but did not: ++a ******************** There is a similar macro for verifying that an expression does not compile, which I find is much more useful in practice. Notable is that the validity macro is an expression -- no statement or other declarations are introduced -- and the static assert macro produces a single static_assert. This means that you can use the assertion macro in the normal scopes that any static_assert can be used (namespace scope, class scope, function scope...). One limitation is that because it uses lambdas behind the scenes, the context in which the validity macro may be used is slightly restricted (I.E. it can't be used in an un-evaluated context). Is this something people would generally find useful? If it is considered generally useful, I don't think it's really worthy of its own library, so where would it go? Years ago I probably would have just assumed utility, but I'm not really sure where it would go in the modern boost structure. The slim version can easily have no dependencies, though the more general solution ideally depends on Boost.Preprocessor. The macros themselves require C++14, though slightly less-useful forms (ones that introduce additional declarations) could be made that would work in C++11. -- -Matt Calabrese

5 14