- Boost - lists.preview.boost.org

[icl] insert_iterator and elements
by Jeff Flinn 22 Dec '14

22 Dec '14

interval_set has overloaded insert methods for both intervals and elements. Is there a reason there insert iterator lacks this ability. The line in the code below *itr = 4; fails to compile. This could be made to compile by: - adding an implicit constructor 'interval( const element& )' for the underlying (discrete) intervals, initializing to [element, element+1), or [element, element]. - adding an overloaded operator=( const element& ) - adding an element_insert_iterator class I've encountered 2 domains now where I need to construct an interval_set<int> from a range of ints. The most natural ways to accomplish this (for me) are: boost::copy( ints, inserter(int_interval_set) ); or boost::copy_range<int_interval_set>( ints ); Of course I can transform the incoming ints, but this seems a common enough usage pattern for the library to provide. Especially since the lack of this facility is asymmetric to the insert overloads of interval_set. #include <iostream> #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS #include <boost/icl/interval_set.hpp> #include <boost/range/algorithm/copy.hpp> int main() { typedef boost::icl::interval_set<int> IdSet; typedef IdSet::interval_type IdInterval; IdSet ids; ids.insert(3); boost::icl::insert_iterator<IdSet> itr(ids, ids.end()); *itr = IdInterval(1,2); //*itr = 4; //compile error no viable operator = boost::copy(ids, std::ostream_iterator<IdInterval>(std::cout)); std::cout << "\n"; return 0; }

1 0

[compute] review
by Pavan Yalamanchili 22 Dec '14

22 Dec '14

*Design and Implementation* The library provides an STL-like library for OpenCL devices. Although there are other libraries offering similar behavior, Boost.Compute is the most complete and the most generalized. The directory structure is well organized and easy to dig through to understand the implementation or debug an issue. Others have pointed out the existence of the OpenCL C++ wrapper and the fact that Compute library does not use it. Here are a few reasons why I think the author was *right* in his design decisions. - The C++ wrapper begins to look similar to the original OpenCL C interface once you start using it in a generalized fashion. - cl.hpp is monolithic (single file 12k+ LOC) and is not modular enough to only include the parts that you need. - Compute and cl.hpp have two different goals. The biggest selling point of Compute is the set of algorithms it supports not its C++ wrapper around OpenCL. Having said that, I think the Compute library might be better off with an additional interface that accepts the OpenCL-C++ wrapped objects. *Documentation* The documentation is comprehensive and the API is documented well. There are a few improvements that can be done. For example, the reference is at the bottom of the TOC and is hard to see immediately. The API reference in the TOC can also be expanded out a bit more to show the general categories of algorithms that are supported. *Potential Usefulness* It is fairly easy to transition from applications using vector algorithms in STL to Compute. The wide availability of OpenCL devices makes the library useful to a large user base. *Domain Knowledge* I am a developer of the ArrayFire library[1]. I am the lead engineer of a company that specializes in this domain. I consider myself to be fairly knowledgeable in this domain. *Experience with the library* ArrayFire depends on Boost.Compute for a few algorithms in our OpenCL backend. We explicitly and implicitly (via ArrayFire) test Boost.Compute on a variety of hardware / compilers / operating systems. Compilers and Operating systems we use: - gcc 4.8, 4.9 on various Linux distributions - clang 3.4 on OSX - Visual Studio 2013 on Windows. We have found some bugs through our usage that have been mostly resolved by the author or by patches sent by us. *Conclusion* The experience overall has been fairly positive. But there are certainly *some* rough edges that need resolving. An issue that will plague any OpenCL library is the performance portability across various devices. It would be nice if the author can talk about how he plans to eventually address this issue. Overall, Boost.Compute will be a great addition to Boost. But before it is accepted the following issues need to be addressed. - The tests need to be a bit more comprehensive. - Due to the general nature of OpenCL, there needs to be a list of "officially supported" devices. - Make sure all the tests are passing on the supported devices. *Links* [1] https://github.com/arrayfire/arrayfire

2 1

A Google Summer of Code Proposal(Boost C++)
by Mudit Sharma 22 Dec '14

22 Dec '14

Respected Sir, I have been studying the Boost C++ libraries.I see that there isn't any library for game development in Boost C++. I propose a new library for game development for Boost C++ under which I propose to use the pygame library of python.Make a Boost C++ analogue for pygame library of python.. *I would like to know if this can be taken as a GSoC'15 project?* Thanking You Mudit Sharma (Student,Pursuing Electronics And Communication Engg. At Delhi Technological University,Delhi,INDIA)

5 5

IDE for developing Boost
by Jens Müller 20 Dec '14

20 Dec '14

Hi, I am looking for recommendations for developing Boost, especially code in the graph library. At work, most developers (not for Boost, for some commercial software), most developers are using Eclipse. This works quite fine as soon as it has properly auto-discovered include paths etc. But before fiddling around with Eclipse to get all the settings right, I'd wanted to to ask for your recommendations. And maybe there are already settings available to make it "just work", at least initially. Cheers, Jens

16 22

[Phoenix] [Bug Fix] A fix for boost::bind compatiblity now on test.
by Fletcher, John P 20 Dec '14

20 Dec '14

For a long time there have been problems with some of the tests for Boost Phoenix compatibility with Boost Bind. These have shown up with recent compilers, gcc 4.9.0 and Clang 3.5 and 3.6. I have discovered that the problems were caused by incorrect overload resolution where some cases were being wrongly allocated. I have just uploaded a patch to develop which passes all tests with gcc 4.9.0 and I hope fixes this problem. The solution involves the use of boost::lazy_disable_if to reject the wrong functions from the overload set and allow them when they are needed. Tests affected are: bind_member_function_tests, bind_mf2_test, bind_test I have not traced a bug report which directly relates to this. I hope this helps. Please reply if there are any problems. Best wishes for the season. John Fletcher

1 0

pygame in boost C++
by Mudit Sharma 20 Dec '14

20 Dec '14

I have been studying the Boost C++ libraries.I see that there isn't any library for game development in Boost C++. I propose a new library for game development for Boost C++ under which I propose to use the pygame library of python.Make a Boost C++ analogue for pygame library of python.. *I would like to know if this can be taken as a GSoC'15 project?* Thanking You Mudit Sharma

1 0

Questions to help me determine export classification of Boost libraries
by Ben Fritz 20 Dec '14

20 Dec '14

Hello, list! One of the contractors I'm working with has delivered code to us that pulls in a few boost libraries. In order to release this code to our customer, I need to determine the Export Control Classification Number (ECCN) of the boost libraries. I see in the archives that someone has asked for the ECCN directly without success ( http://lists.boost.org/boost-users/2008/01/33241.php) so I'm currently trying to use a questionnaire put together by some of the export experts within my company to figure this out. If there is an ECCN already listed somewhere, please point me to it, otherwise I'll continue. I'm interested specifically in version 1.56.0 of the boost libraries. However, since I don't see any major additions or deletions in the 1.57.0 release notes, I assume the answers will apply to both versions. Apparently the export classification is primarily based on two things: 1. Does the library have anything specifically designed for military use? I'm assuming the answer to this is "no". Please correct me if I'm wrong. 2. Does the library include any strong encryption? This includes symmetric or asymmetric encryption with certain key lengths, cryptanalytic functions, intrusion detection, quantum cryptography, "reduce information-bearing signals" (not sure what that is), and other cryptographic technology. I looked through the list of libraries documented here: html/index.html <http://www.boost.org/doc/libs/1_57_0/libs/algorithm/doc/html/index.html> http://www.boost.org/doc/libs/?view=categorized >From the description of each library, I was mainly concerned with Boost.Algorithm, Boost.Asio, and Boost.Uuid. >From the documentation of Boost.Algorithm at http://www.boost.org/doc/libs/1_57_0/libs/algorithm/doc/ <http://www.boost.org/doc/libs/1_57_0/libs/algorithm/doc/html/index.html>, it looks like there is no encryption technology in the library. Can someone confirm? Boost.Asio contains some SSL interfaces, which undoubtedly contains encryption technology. However, according to http://www.boost.org/doc/libs/1_57_0/doc/html/boost_asio/overview/ssl.html these interfaces require OpenSSL to be used. Does this mean that the Boost.Asio library itself does not contain encryption, it only provides an interface to another library which does the encryption? I.e., is it a true statement, that Boost.Asio contains no encryption technology in either its source code or in the compiled binary, and that in order to use encryption I would need to link in a separate library? Boost.Uuid contains some cryptographic hash features. However, I understand that a cryptographic hash cannot by itself provide any message encryption, so I do not believe this should qualify. Is there anything I'm missing here? Does Boost.Uuid contain other technology that might qualify? Please also let me know if I missed any encryption in other Boost libraries, as I only looked at the library descriptions, and am not familiar with any of the library functionality. -- Ben Fritz

6 8

[RPC] Compile-time reflection for RPC and mocking
by Peter Bindels 19 Dec '14

19 Dec '14

Hi all, I've searched through the Boost mailing list history to find related emails and the last I found was from January where Oleg Labutin and Hartmut Kaiser discussed compile-time reflection in the context of RPC mechanisms. Based on Hartmut's speech last Saturday introducing HPX and explaining a bit about async/future/promise I tried to implement a simple RPC mechanism that uses then to decouple work and the result I have so far is very promising. I have a simple interface with a call that returns a future, and the caller does not distinguish between calling the actual object and calling on a proxy, as both return a future<T>. It does what the discussion mentions - serialize the name of the interface and function, as well as the arguments (basically the mangled name of the interface function) to ensure there are no mismatches. I would like to take this oppurtunity to propose two things: - I can work on this idea to work it out into a full RPC mechanism, to be proposed for Boost.RPC, if there is enough interest. Currently it uses macros to generate and wrap functions, and a simple serializer that serializes in the same way that Protobuf and Thrift also serialize. - Given a compile-time reflection method, the entire proxy class and dispatch class can be auto-generated from the interface class - the full code for registering an interface with the RPC mechanism would collapse to RPC::Register<T>(); To do so, it would need two language additions. It needs access to a compile-time iterator over functions and traits about the argument types, return type, name and whether it is a virtual function. For the prototype this can be manually generated for an interface to show it works. Additionally, it would need to be able to use such a definition to instantiate a virtual function from a base class - basically, hooking up an std::function<X> to a virtual function X directly. I think this is well-implementable (probably reusing most code from lambdas for the link code), but I don't know whether that's true. On the second note, I also proposed a Mock library a few years ago. This basically fell flat on the code that I suggested being very unsafe and using many hackish methods to mock functions. Using the compile-time reflection proposed for the second bullet I would be able to replace the entire hackishness from that with 100% compliant code, with only one minor regression in functionality. That should make it Boost-OK at least from a language standards perspective. Any ideas? Reactions on RPC or Mocking? Best regards, Peter Bindels

8 15

file_descriptor::read() docs?
by Olaf van der Spek 19 Dec '14

19 Dec '14

Hi, Where is file_descriptor::read() documented? Shouldn't it be at http://www.boost.org/doc/libs/1_57_0/libs/iostreams/doc/classes/file_descri… ? -- Olaf

2 3

[compute] Request to extend the review period till 30 December
by Antony Polukhin 19 Dec '14

19 Dec '14

Hi, Now, when the review of Compute library is going on, it seems that 10 days is not enough. Some of the Boost developers are on a vacations or do not have much free time right now. I've got a few personal requests to extend the review period. Library author agrees to extended review. 30 of December seems like a reasonable date for the last review day to both of us. Do the review wizards agree for extended review? -- Best regards, Antony Polukhin

2 1