December 2014 - Boost - lists.preview.boost.org

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

[inteprocess] static analyzer results
by Gaetano Mendola 19 Dec '14

19 Dec '14

We have upgraded to use boost 1.55 and our static analyzer is telling us: interprocess/detail/win32_api.hpp: ~1145 if if(!SetSecurityDescriptorDacl(&sd, true, 0, false)) takes the true branch then sa.nLenght, sa.lpSecurityDescriptor, sa.bInheritHandle result in not initialized members. interprocess/sync/spin/recursive_mutex.hpp: CTOR at 71 leaves the m_s not initialized interprocess/mapped_region.hpp: ~341 boost::uintmax_t(mapping_size - (offset - page_offset)) > boost::uintmax_t( std::size_t(-1))) is always false

1 0

[compute] review
by Sebastian Schaetz 17 Dec '14

17 Dec '14

Hi, Here is my review of Boost.Compute: 1. What is your evaluation of the design? The library is based upon OpenCL, a cross-platform cross-device open standard that abstracts access to and provides a programming model for many-core vector co-processors such as GPUs. These co-processors are usually referred to as "devices". The library provides a wrapper layer around the OpenCL C interface. It skips the standard OpenCL C++ wrapper which I don't consider a problem because except for destructors there is no added value in using this wrapper. In my opinion Khronos should adopt Boost.Compute as their C++ layer for OpenCL. Boost.Compute provides compatibility with the OpenCL C interface through conversion operators that decay Boost.Compute types to their OpenCL C equivalents. This can be quite useful. On top of this wrapper Boost.Compute exhibits 3 core components: * types to interact with and issue commands to devices: these follow OpenCL concepts but are not necessary if defaults are used * means of managing memory (allocate, copy) on devices: this component contains also asynchronous operations which I consider essential in a library that deals with co-processors * a collection of parallel primitives and meta-functions with an STL interface: this components contains powerful iterators to combine containers and algorithms to implement more complex algorithms in an efficient manner One thing I'm not clear about is how asynchrony is handled. Command queues are exposed, issuing commands to different queues is a way to express concurrency. At the same time copy_async returns a future which is another way of exposing concurrency. It is out of the scope of Boost.Compute to solve the challenges of asynchronous/concurrent operations because it is a different and difficult topic not yet solved for C++ in general either, but at least the documentation should be more explicit about which commands are executed when, which commands are synchronous, which are asynchronous and what is the role of the command_queue in this regard. 2. What is your evaluation of the implementation? I did not evaluate the implementation in detail but looked at a few of the tricks Boost.Compute uses to generate kernels. The implementation of this part of the library is good and instructive. 3. What is your evaluation of the documentation? Boost.Compute documentation is of excellent quality. The recent addition of performance data is helpful. I could not find any documentation about fancy iterators, this should probably be added. Also, it would be great if the my questions regarding asynchrony/concurrency could be addressed in the documentation. 4. What is your evaluation of the potential usefulness of the library? Boost.Compute is extremely useful. With this library a developer familiar with the STL can utilize the processing power of GPUs without any knowledge of vector co-processor programming. The documentation shows that for large vector sizes, some Boost.Compute algorithms outperform the STL by an order of magnitude. 5. Did you try to use the library? With what compiler? Did you have any problems? I tried the unit-tests on a 8x GeForce Titan system without any problems and on a ARM Mali GPU with some unit tests failing. I'll be working with the library author to fix tcomp.lib.boost.develhe problems in these unit tests. I used gcc 4.8.2 for the tests on both GeForce and Mali. 6. How much effort did you put into your evaluation? A glance? Aquick reading? In-depth study? I reviewed the library a few months ago in-depth and reread the documentation for this review as well as ran some unit tests. 7. Are you knowledgeable about the problem domain? My job involves working with both CUDA and OpenCL. Furthermore I am the author of the Aura library [0] a similar, albeit lower level library for accelerator programming. 8. Do you think the library should be accepted as a Boost library? I think the library should be accepted into Boost. The interface is simple and easy to understand for non-experts and the benefits of using this library can be significant. I'd like to add that Boost.Compute represents one level of abstraction for accelerator programming. I'd like the Boost community to keep an open mind when it comes to different levels of abstraction, either lower (i.e. my Aura library) or higher (i.e. VexCL). Libraries with different levels of abstraction can coexist, be compatible with one another or could even build upon one another. Best Regards, Sebastian Schaetz [0] https://github.com/sschaetz/aura

2 1

File Handle and FILE* wrappers?
by Olaf van der Spek 16 Dec '14

16 Dec '14

Hi, Would there be any interest in wrappers for file handles / descriptors and FILE*? Sometimes one needs native handles or FILE* for interoperability or special features like memory mapped IO, but standard C++ doesn't provide convenient RAII friendly wrappers for these. The idea seems trivial yet quite useful. I'm aware of <boost/iostreams/device/file_descriptor.hpp> but it seems to be too high-level. I've put a simple start for FILE* at https://code.google.com/p/xbt/source/browse/trunk/xbt/misc/xbt/cfile.h What do you think? Also posted at https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Q4RdFSZg… -- Olaf

8 21

[utility] What happened to OptionalPointee/compare_pointees?
by Mostafa 16 Dec '14

16 Dec '14

1) OptionalPointee/compare_pointees reside here: libs/utility/OptionalPointee.html, but there's no way to navigate to it from here: libs/utility/ or here: libs/utility/utility.htm 2) IMO, compare_pointees should have stand alone documentation, and be grouped with pointee and indirect_reference. 3) pointee and indirect_reference are not iterator specific, therefore they shouldn't reside under iterator's documentation. IMO, compare_pointees, pointee and indirect_reference should all reside under a pointee utilities section. Thanks.

1 1

Spam ticket
by Barend Gehrels 15 Dec '14

15 Dec '14

Hi, This is not a spam-ticket but an annoying spam-comment in a long closed ticket. How can we handle this? Can the user of this comment (Smithg358) be blocked? Thanks, Barend -------- Original message -------- Onderwerp: Re: [Boost C++ Libraries] #6019: Convex hull and Area, combined, sometimes give wrong result Datum: Sat, 13 Dec 2014 23:23:53 -0000 Van: Boost C++ Libraries <noreply(a)lists.boost.org> CC: boost-bugs(a)lists.boost.org #6019: Convex hull and Area, combined, sometimes give wrong result ------------------------------------------+------------------------------ Reporter: Crispin Cooper <cooperch@…> | Owner: barendgehrels Type: Library Submissions | Status: reopened Milestone: Website 1.X | Component: xpressive Version: Boost.Build-M3 | Severity: Not Applicable Resolution: | Keywords: convex hull area ------------------------------------------+------------------------------ Changes (by Smithg358): * status: closed => reopened * severity: Problem => Not Applicable * type: Bugs => Library Submissions * component: geometry => xpressive * version: Boost 1.47.0 => Boost.Build-M3 * milestone: To Be Determined => Website 1.X * resolution: fixed => Comment: Your goal is to breed all the different dragons available to you ddgkbecefcfgddbk -- Ticket URL: <https://svn.boost.org/trac/boost/ticket/6019#comment:7> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.

2 2

[safe_numerics] questioning the basic idea
by Andrzej Krzemienski 15 Dec '14

15 Dec '14

Hi, I was going through the Safe Numerics library in Boost Library Incubator, and I realized I disagree with the basic idea it is built on. I wanted to rise my concerns here. If I were to summarize in one sentence what this library is, I would say: a drop-in replacement for type int that checks for overflow in run-time and throws an exception if it finds one. Did I get it right? The remainder of this post is based on this interpretation. If so, I am not sure if this idea is a good one and worth promoting in Boost. BTW this is one of my criteria for letting a library into Boost: whether it promotes worthy ideas. I agree with the statement that a program should be UB-free. But I do not think that the approach of letting the programmer do what he did before, having the library or some run-time tool check for potential UB, and throwing an exception instead makes the program any better (or safer). It is just hiding the symptoms but not curing the disease. The programmer should not plant the UB in the first place - I agree. But this is different than first doing the mess and then having the run-time clean it up for you. I know it works for many people, in a number of languages, and it may even be considered a practical solution, but (by inclusion into Boost) I wouldn't like to be sending the message "this is how you are suppose to code". I try to recall how I use type int. I do not think I ever use it for anything that would be close to "numeric" as I know the term from math. Use Case 1 (an index): for (size_t i = 0, I = v.size(); i != I; ++i) { if (i != 0) str += ","; str += v[i]; } There doesn't appear to be a good reason to wrap it into safe<int> here, even though the incrementation could possibly overflow. Plus, it would kill my performance. Use Case 2 (using reasonably small range): I used an int to represent a square on a chessboard. There is only 64 squares, so I couldn't possibly overflow, on whatever platform. And even if there exists a platform where 64 doesn't fit into an int, I would not use safe<int> there. I would rather go for something like double_int. If I were to use some numeric computations on integers and I perceived any risk that I may overflow, I would not be satisfied with having the computations stop because of an exception. I would rather use a bigger type (BigInt?). I do not think int is even meant to be used in numerical computations. I believe it is supposed to be a building block for building more useful types like BigInt. One good usage example I can think of is this. After a while of trying to chase a bug I comae up with a hypothesis that my int could be overflowing. I temporarily replace it with safe<int> and put a break point in function overflow() to trap it and support my hypothesis. I would probably use a configurable typedef then: #ifndef NDEBUG typedef safe<int> int_t; #else typedef int int_t; #endif But is this the intent? But perhaps it is just my narrow perspective. Can you give me a real-life example where substituting safe<int> for int has merit and is not controversial? I do not mean the code, just a story. Regards, &rzej

6 12