August 2018 - Boost - lists.boost.org

[ublas] Supporting DNNs with Tensors/Multidimensional Arrays
by Cem Bassoy 06 Sep '18

06 Sep '18

Gsoc <https://summerofcode.withgoogle.com/organizations/4507228564881408/> 2018 just ended one week ago and we had many successefully completed student projects <https://github.com/BoostGSoC18>. I was responsible for adding tensor support to Boost.uBLAS for primarily supporting multilinear algebra operations in the field of numerics. The wiki description along with the implementation can be found here <https://github.com/BoostGSoC18/tensor>. Similar to Boost.multi_array <https://www.boost.org/doc/libs/1_68_0/libs/multi_array/doc/index.html> the runtime-reshapable tensor data structure is parametrized in terms of number of dimensions (rank/order), dimension extents, data type, layout (first- and last-order) and storage type. The first two are runtime-variable. I am also about to add subtensor (view/handle of a tensor) along with multidimensional iterators for convenient algorithm implementation. It is yet not as flexible as GSL's multi_span <https://github.com/Microsoft/GSL/blob/master/include/gsl/multi_span>: does not yet support static rank and dimensions. However, basic generic tensor operations (contraction/transposition/reshaping/...), including a nice syntax for Einstein's summation convention with placeholders, using C++17 features are provided. The operations are evaluated using expression templates (not smart yet). Similar to the tensor <https://eigen.tuxfamily.org/dox/unsupported/group__CXX11__Tensor__Module.ht…> framework of Eigen, that is used by tensor flow <https://github.com/tensorflow/tensorflow>, the tensor data structure in Boost.uBlas could be taken for implementing deep neural networks or higher-order statistics I think. I am not sure if the C++ community would appreciate if Boost has some form of basic operations for building *deep neural networks* (DNNs). I would like to ask 1. if it make sense for boost to support basic operations for DNNs? 2. what are the obligatory, necessary basic operations for creating DNN building blocks? 3. if there are any additional data structure parameters that needs to be added for (efficiently) supporting DNNs? Best, Cem

3 5

No Viable function warning
by randydom 03 Sep '18

03 Sep '18

Hello i've the bellow function : __declspec(dllexport) int TrySendData(_isocket * isocket,char * ibuff,int ilen) { boost::system::error_code ignored_error; boost::asio::write(isocket->socket(), boost::asio::buffer(ibuff,ilen), boost::asio::transfer_all(), ignored_error); if(ignored_error) return 0; return 1; } I get a *No Viable function* warning , can someone tells me why or helps me in fixing this warning . Thank you . -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

Original STL Library Documentation has been recovered and is now safe forever.
by Robert Ramey 03 Sep '18

03 Sep '18

The Standard Template Library is the foundation of modern C++. The creation and publication of this code and its documentation set a new standard for the formal specification of what a computer program should do, how it should be designed and how it should be formally documented. These pages were maintained first by Silicon Graphics and then later by Hewett-Packard. In January of 2018 these pages were removed by H-P. This is a historic blunder. I have recovered the original STL Library Document and hosted them here: http://www.rrsd.com/software_development/stl/index.htm Robert Ramey

8 10

[integer] CMT assume responsibility for Boost.Integer?
by James E. King III 01 Sep '18

01 Sep '18

The maintainer of Boost.Integer has no commits since 2008, and I was unable to get a hold of him by email (waited 10 days for a reply). I suggest we transfer responsibility of this repository to the CMT. - Jim

3 3

Gsoc 2019
by Shubham Verma 01 Sep '18

01 Sep '18

Hey I'm new, but I'd like to contribute to your organisation, can someone please guide me along?

5 4

Let's stop distributing binaries
by Robert Ramey 31 Aug '18

31 Aug '18

The fact is that users of boost use compilers with differing levels of C++ standard conformance. This creates a number of problems including (but probably not limited to) a) Using libraries built with different levels of C++ conformance may create ABI issues. b) it creates a discussion about "dropping C++03 support". Actually it creates a discussion about that the above actually means. c) It's motivated a suggestion that all libraries move to header only. This is not great idea - but I won't address that here. I believe all these issues - and more - would disappear if we just stopped distributing binaries. Each user would be building his own boost version with (presumably) the same compiler. Since C++03 compatible libraries are C++?? compatible, each library author can maintain the level of backward compatibility that he wishes. But if we're not going to distribute binaries, then users might as well just clone the latest "certified - good - tagged" version in the master branch from the github repo. That is, let's just stop or truncate the whole release circus. Replace with an occasional "certification/versioning procedure" which would make available a "squashed" master suitable for efficient cloning. This would make everyone's life easier. Robert Ramey

19 63

A possible date for dropping c++03 support
by Mike Dev 31 Aug '18

31 Aug '18

Sorry for all the bad line-breaks in my previous message. I don't have access to a properly configured email client right now. This should be easier to read: ====== Original Message ============== Please, let's not derail the discussion just after some consensus has emerged and just before it actually produces actionable items. Let's not make the better the enemy of the good here. I made the suggestion to commonly drop c++03 support in the hope that it would actually lead to some code simplifications and reduced coupling between the boost libraries - even if only in their implementation (if someone wanted to do a real c++14 reboot of their library, no one is/was stopping them anyway). >From the survey, I'd say interest in actually applying c++11 features in libraries that a currently supporting 03 is already relatively low, but big enough that I believe this will actually lead to some changes other than just changing the default test settings. That is with a standard almost universally supported by compilers in use today. Even though the move from 11 to 14 is much less dramatic, c++14 support is less wide spread and outside of the big three, there are many compilers where even the most recent version doesn't support c++14, so I just don't see people that are currently maintaining c++03 support in their libraries suddenly starting to use c++14. All this doesn't preclude a discussion about if and when to move to c++14 or a general policy about LTS versions and the like, but please keep it separate unless you are really, really confident it will lead to something actionable earlier than what is currently proposed. I have lots of Ideas, how boost could be reformed and/or modernized but in the end it comes down to convince the individual library maintainers to actually do something. I think the current proposal will at least spark some action. Let the announcement to move to cmake be a warning sign about realistic expectations about the evolution of boost. Maybe I'm aiming too low, but again, if you want more, please open a separate thread and most likely, whatever you come up with there will not be mutually exclusive with what is proposed here. Regarding the test settings: If c++11 is supposed to be the lowest official supported version then that is what should be tested Anything else doesn't make sense (you can't claim to support c++11 if you don't test if it actually works there). In any case, as was mentioned before, for the announcement itself we don't need give any specifics about something that is going to happen 1-1,5 years from now. How about something like " c++03 mode/compilation will no longer be tested / part off the general test/suit"? Best Mike

1 0

A possible date for dropping c++03 support
by Mike Dev 31 Aug '18

31 Aug '18

Please, let's not derail the discussion just after some consensus has emerged and just before it actually produces actionable items. Let's not make the better the enemy of the good here. I made the suggestion to commonly drop c++03 support in the hope that it would actually lead to some code simplifications and reduced coupling between the boost libraries - even if only in their implementation (if someone wanted to do a real c++14 reboot of their library, no one is/was stopping them anyway). >From the survey, Id' say interest in actually applying c++11 features in libraries that a currently supporting 03 is already relatively low, but big enough that I believe this will actually lead to some changes other than just changing the default test settings. That is with a standard almost universally supported by compilers in use today. Even though the move from 11 to 14 is much less dramatic, c++14 support is less wide spread and outside of the big three, there are many compilers where even the most recent version doesn't support c++14, so I just don't see people that are currently maintaining c++03 support in their libraries suddenly starting to use c++14. All this doesn't preclude a discussion about if and when to move to c++14 or a general policy about LTS versions and the like, but please keep it separate unless you are really, really confident it will lead to something actionable earlier than what is currently proposed. I have lots of Ideas, how boost could be reformed and/or modernized but in the end it comes down to convince the individual library maintainers to actually do something. I think the current proposal will at least spark some action. Let announcement to move to cmake be a warning sign about realistic expectations about the evolution of boost. Maybe I'm aiming too low, but again, if you want more, please open a separate thread and most likely, whatever you come up with there will not be mutually exclusive with what is proposed here. Regarding the test settings: If c++11 is supposed to be the lowest official supported version then that is what should be tested Anything else doesn't make sense (you can't claim to support c++11 if you don't test if it actually works there). In any case, as was mentioned before, for announcement itself we don't need give any specifics about something that is going to happen 1-1,5 years from now. How about something like " c++03 mode/compilation will no longer be tested / part off the general test/suit"? Best Michael

1 0

A possible date for dropping c++03 support
by Mike Dev 31 Aug '18

31 Aug '18

>From the discussion about abi compatibility when the Boost.System library is compiled e.g. in c++03 mode and then included in ac++11 project or vice versa (https://groups.google.com/forum/#!topic/boost-developers-archive/EWG5NVOZo_ g) > > When can we drop C++03 support? :D This will probably be ignored or shouted down, but maybe someone just needs to make a concrete suggestion about which people can discuss and vote so I'm giving it a shot: What about the first or second release in 2020 ? By then, all major toolchains have had solid c++11 support for at least 5 years ( I think, msvc was the last one with VS2015) and at least partial support for 7+ years (gcc 4.8, msvc 2013, clang 3.3). Also, most likely c++20 will be released in that year, which means that c++03 compatible libraries would have to support 5 different (and partial incompatible) language versions by then (not to mention ABI-compatibility considerations between different versions). That should also be enough time to ensure that the last c++03 release (late 2019) is really solid (for projects that still can't upgrade to c++11) and ideally there could be a few more bugfix-releases afterwards as is often done by other software projects. And before someone starts to raise straw mans: That of course wouldn't mean that a particular library *must* no longer compile in 03 mode, but one can no longer rely on the boost-internal dependencies remaining c++03 compatible. Best Mike

23 104

[ptr_container] associative container insert takes reference instead of const reference as key ?
by comic fans 30 Aug '18

30 Aug '18

Hello , I've found that ptr_unordered_map.insert has following signature (from code and latest doc) std::pair<iterator,bool> insert( key_type& k, T* x ); that forbids calls like ptr_unordered_map.insert( myobj->id(), myobj) ,I wonder if this is by design , or some other reason ? why other overload takes const key_type& k as key type? and insert always call insert_impl which have const reference as key type ? any help would be appreciated.

2 5