January 2015 - Boost - lists.boost.org

[Phoenix] [MSVC] 8 9 and 10 COMDAT error
by Fletcher, John P 17 Jan '15

17 Jan '15

I am attempting to sort out the bugs and test failures in Boost Phoenix. I have one test (bind_rv_sp_test) which fails at the link stage with the following error on MSVC 8 9 and 10 but not later bind_rv_sp_test.obj : fatal error LNK1179: invalid or corrupt file: duplicate COMDAT '?value@?$result_@P8Y@@AE?AV?$shared_ptr@UX@@@boost@@XZ@?$is_mem_fun_pointer_select@$0A@@detail@boost@@2_NB' I have been researching this error and attempting to find a workaround for Phoenix. Has anyone else working on Boost encountered this error and have any suggestions about it. It does appear to have been around for some years and there are a lot of suggestions but no clear resolution I have found. How important are these compilers, and would it be O.K. to mark this test as expected to fail? I don't have these compilers so for any new tests I am relying on the develop tests to check out experiments. Thank you John

2 2

Re: [boost] [compute]/ Futures Some remarks
by Antonio Colino 16 Jan '15

16 Jan '15

> > On 01/14/2015 10:46 PM, Antonio Colino wrote: > > I have a flawless implementation of this concept I am very proud of. Is any one willing to critique it? > > On 01/14/2015 10:46 PM,?Thomas Heller?wrote: > > Wanna share it? Which concept are you refering to? > > I was hoping to share this lib, if i could generate any interest in a copyable hpc version of packaged_task > On Jan 2015 20:36:40,?Thomas Heller?wrote: > Absolutely! Note that there are already a few out there doing exactly what > you described (HPX and Habanero++ come to my mind here). >On Date: Thu, 15 Jan 2015 21:58:37, Antonio Colino wrote: >What would be the best way to arrange this? Thomas if you are sill interested I am still curious by which method you would prefer to review the code, as it is not yet made public and I would like to have a second opinion before doing so.

1 0

[function] unmerged changes
by Peter Dimov 16 Jan '15

16 Jan '15

Boost.Function's develop branch appears to have accumulated a few changes that aren't in master, to which I've added one more (I neglected to check first). Looking at the test results, nothing there seems out of the ordinary, so these should probably be merged, perhaps without my final commit (which is itself a very low risk, as it merely changes detail:: to boost::detail:: in a few places).

2 1

[test] clang warning
by Peter Dimov 16 Jan '15

16 Jan '15

..\..\../boost/test/impl/debug.ipp:211:21: warning: private field 'm_binary_path_buff' is not used [-Wunused-private-field] char m_binary_path_buff[500+1]; // !! ?? ^ I'm not sure what the purpose of this member is, but according to Clang, it's not used anywhere.

4 4

[units] unmerged changes in develop
by Peter Dimov 16 Jan '15

16 Jan '15

The following changes are in develop but not in master. Should these be merged? They all look fine (and beneficial) to me. C:\Projects\boost-git\boost\libs\units>git log master..develop commit cc97c0f253a250a15f0b2174ec12a338772248b6 Merge: 87778d2 12f0a2e Author: Jürgen Hunold <jhunold(a)gmx.eu> Date: Thu Nov 6 20:44:33 2014 +0100 Merge pull request #14 from mkurdej/fix/doc-information Fix documentation on information system units. commit 87778d23197aeceaccedeea2c3df43f2fa9f9a85 Merge: b40a903 45058c0 Author: Jürgen Hunold <jhunold(a)gmx.eu> Date: Thu Nov 6 20:43:04 2014 +0100 Merge pull request #13 from mkurdej/fix/header-guards Fix header guards and namespace trailing comments. commit 12f0a2eb0a2ac2925fe04d8afb744e7178e37ddc Author: Marek Kurdej <mkurdej(a)users.noreply.github.com> Date: Thu Nov 6 12:32:02 2014 +0100 Fix quickbook warning about deprecated '\n' in generated base_units.qbk. commit 9ba957d7208322bf752d61c7d5401bb358af5f0b Author: Marek Kurdej <mkurdej(a)users.noreply.github.com> Date: Thu Nov 6 12:22:02 2014 +0100 Add doc for boost/units/systems/information.hpp. commit 2042d4d72337d05e1606eb385d5b1b3865739e70 Author: Marek Kurdej <mkurdej(a)users.noreply.github.com> Date: Thu Nov 6 12:14:53 2014 +0100 Fix documentation on information system units (not only base units). commit aaffc7fa6f8c05cff396b6fc71a3ef8b79192330 Author: Marek Kurdej <mkurdej(a)users.noreply.github.com> Date: Wed Nov 5 18:24:23 2014 +0100 Fix documentation on information system units. commit 45058c08f7c2372cef729237a21a87a036245d2d Author: Marek Kurdej <mkurdej(a)users.noreply.github.com> Date: Mon Nov 3 13:59:10 2014 +0100 Fix header guards and namespace trailing comments.

2 4

Integrating Boost.Sort library
by Steven Ross 16 Jan '15

16 Jan '15

I would like to integrate the (recently accepted) Boost.Sort library into the main Boost build process, and provide Paul A. Bristow < pbristow(a)hetp.u-net.com> access to edit the documentation (it doesn't have to be restricted to just the docs). Are there instructions on how to do this? The current code is sitting here: https://github.com/spreadsort/sort

2 3

ASIO does not fully support Windows Runtime (WinRT), and a suggestion for providing support
by Moshe Rubin 16 Jan '15

16 Jan '15

While attempting to port filesystem to Windows Phone 8.1, I encountered some issues with the WinRT portions of ASIO. Examining the Boost code shows that ASIO does not fully support WinRT. Examples are that the acceptor implementation for WinRT #includes the null_socket_service class in socket_acceptor_service.hpp, rendering it unsupported. In addition, there is no counterpart in WinRT to WinSock's select() function, so there is no way to call select() off of a WinRT socket object. I would therefore like to briefly summarize what my company's needs are, what problems I've encountered, and a suggested solution for having ASIO support WinRT. Here are our corporate library's (let's call it CORLIB) needs: (*) Our goal is to build our Boost-based library (i.e., CORLIB) for Windows Phone 8.1. (*) CORLIB refers to Boost sockets in a cross-platform fashion (e.g., using the basic_stream_socket class as an abstraction via boost::asio::ip::tcp::socket). (*) CORLIB uses the boost::asio::ip::tcp::acceptor object in portions of its code. (*) CORLIB also calls the bind() socket function (*) CORLIB uses the BSD/Winsock functions select() and bind(), among other functions, to implement its logic Here are the problems: (*) The socket_acceptor_service class #includes null_socket_service.hpp to implement the acceptor object for WinRT. In other words, the acceptor object is not implemented for WinRT. (*) The winrt_ssocket_service_base class does not implement the listen() function, something that must be implemented to support the acceptor object. (*) The winrt_ssocket_service class implements native_handle_type as Windows::Networking::Sockets::StreamSocket^. There is no WinRT analog for the BSD/WinSock select() function, so CORLIB has no way of performing a select on the StreamSocket object. Since select() is critical to CORLIB, StreamSocket^ is unacceptable. We believe that winrt_ssocket_service must be implemented using WinSock (almost completely supported by Windows Phone 8.1) rather than Windows::Networking::Sockets, because the select() function is unimplementable using the WinRT hierarchy. We therefore propose creating a new socket service class for WinRT (we will refer to this new service class as winrt_winsock_socket_service) . This new service will be similar to reactive_socket_service: the stream_socket_service.hpp include file shows the following: #if defined(BOOST_ASIO_WINDOWS_RUNTIME) # include <boost/asio/detail/winrt_ssocket_service.hpp> #elif defined(BOOST_ASIO_HAS_IOCP) # include <boost/asio/detail/win_iocp_socket_service.hpp> #else # include <boost/asio/detail/reactive_socket_service.hpp> #endif Since we want to return to WinSock-based sockets for WinRT, we therefore want to model the Winsock-based WinRT implementation on reactive_socket_service, making changes for WinRT when necessary. Because Windows Phone 8.1 supports Winsock2, including bind(), listen(), and select(), we should be able to support WinRT via WinSock. This class will not make any use of WinRT's new socket classes.

4 5

Re: [boost] ASIO does not fully support Windows Runtime and a suggestion for providing support
by Moshe Rubin 16 Jan '15

16 Jan '15

>> I highly object to the tone of your response. Bringing up a matter on >> this mailing list related to a Boost library is not a command for anyone >> to do anything. By responding the way you have done you are discouraging >> people with issues from using Boost mailing lists to start a discussion >> about a particular library. > I apologise if I have offended anyone on the list, including you > Edward. My thanks to Edward for standing up for a relatively new poster to this mailing list. There was absolutely no malicious or similar intention in my post, and certainly no "commanding and impatient tone". My intention was to improve ASIO, which is an incredible technological achievement. Our needs for a ported Boost for WinRT, as the needs of many others, are immediate, so I used the methods known to me, including posting to this mailing list. If I had a nickel for every WinRT developer pining for a complete port of Boost for WinRT, I'd probably be a rich man <g>. > However, there is an etiquette when dealing with deficiencies in open > source libraries. You first raise the issue with the library's > maintainers before going onto public lists - and before I replied to > the OP, I checked the github ASIO issue tracker and the Boost issue > tracker and found no mention of the deficiencies. It may be the case > that the OP has spoken to Chris by private email, but his post did > not indicate that. I am willing to learn the ropes and thank you for pointing out the correct procedure. As a matter of fact, I used a two-pronged tactic just in case and sent the same email to Chris in parallel (see his response below). > Furthermore, Chris fairly bluntly stated in the > ASIO release notes which added WinRT support that that support would > be limited, and he went into some detail as to how and why. That > would strongly suggests that the maintainer is well aware of the > limitations, and has a strong idea of what should be done about them > (if anything). Moreover, if he has left out a particular support for > something, he may well have very good reasons for that, including the > cost benefit reason. Indeed, I had not checked the ASIO release notes, and now know that that is most important. Reading them now, I see that Chris limited his port. As a WinRT developer, I know why he decided to do so. > So, go raise it with the maintainer first, and that's probably best > done as I mentioned via the ASIO github issue tracker which Chris > definitely responds quickly to. If the maintainer refuses to support > what you need, *then* come onto this list to see if anyone else is > having the same problem, *then* see if you can put together a > coalition of the willing. However, to be honest, I think the > maintainer will be happy to improve WinRT support, you just need to > prearrange what form he'd prefer it to come in. Here is Chris's courteous reply to me: <quote> Thanks for your email. I was not aware that Windows Phone now supports Winsock. This is great news. However, I am a bit confused by your proposed design. I don't believe we need a new socket service at all. If Windows Phone now supports Winsock then we simply need to prevent BOOST_ASIO_WINDOWS_RUNTIME from being defined - see asio/detail/config.hpp. Then, provided that BOOST_ASIO_WINDOWS *is* defined and BOOST_ASIO_HAS_IOCP is *not*, it will use the existing select()-based reactive_socket_service backend. This backend is already supported on Windows, and was used in the past to support Windows 9x and WinCE. I suggest you start by modifying asio/detail/config.hpp to make those changes, and then see what errors happen after that. There will most likely be other changes needed to work around Windows API functions that are still unsupported on Windows Phone. Cheers, Chris </quote> > And BTW, after you've talked to Chris and gotten green lit by him, > absolutely do ping this list with what you've agreed to do and ask > for feedback on it. The people I'm currently contracting for would be > very interested in improved WinRT support in ASIO. I'm sure so would > others on the asio-users ML. And as ASIO is going to be the > Networking TS, I daresay so would Microsoft, indeed you might even > get some improvements to WinRT to help ASIO along - we have the main > Microsoft engineer who ported Boost to WinRT on this mailing list. So here I have a question: when I've followed up on Chris's suggestions and have ASIO working for ASIO, what should I do next? Return to the mailing list to announce the fact and ask for feed as you suggest, or schedule a GitHub pull request? I have recently been in contact with Steven Gates, who has been very helpful on my quest of porting Boost for WinRT. In conclusion, Niall, I thank you for educating me on the etiquette on Open Source public mailing lists. I trust you've also learned not to pull the trigger too quickly. Moshe

6 5

Regarding Contribution to Boost Library
by Siddharth Agrawal 16 Jan '15

16 Jan '15

Hello all, Myself Siddharth Agrawal, I have been using boost library since 1 year.Now I want to contribute to the development of this library. Can anyone guide me where should I start. I would be grateful for this. Moreover I also want to know the github page of Boost. Regards, Siddharth Agrawal.

3 3

Interest in a FIX Protocol Library?
by Marius Dobrea 16 Jan '15

16 Jan '15

Hello Boost, I have been following the boost email lists for a while now and would like to contribute to Boost too. Since it matches at best my experience it would be probably most beneficial if I contribute to a BOOST/FIX library. FIX comes from the "Financial Information eXchange" Protocol and it represents a standard that is used a lot in the Financial Industry. For more information see the related Web Site: http://www.fixtradingcommunity.org. Firstly I would like to ask the community if there is interest in such a library and if anyone is doing any work on it. It seems to me that although there are a lot of firms and institutions in the world providing software or using FIX there are too few open source C++ libraries for that. Secondly I would like to receive feedback on what functionality would be interesting to be part of this library. For instance it could contain: - basic components that can be used to build bigger blocks: e.g.: raw data iterators, message components, field types; - conversion functions from FIX to C++ types and vice versa; - code generators for Messages, Enums, Constants based on XML specification files; - implementations for various FIX Session types: Tag-Value, FAST, FIXP, user defined messages, etc; - transformers which based on some configuration could convert messages automatically between various FIX versions; - message persistence, etc. FIX is very well documented and as such various functionality could be probably easily split into interesting projects that are to be part of the GSoC. Let me know what you think. Thanks, Marius Dobrea

13 17