February 2016 - Boost - lists.preview.boost.org

[filesystem] temp_directory_path and Android devices (repost)
by doodad-js Admin 12 Feb '16

12 Feb '16

(sorry for the repost, but someone told me that I should include "filesystem" in the subject) Hi, I have read the specs (http://www.boost.org/doc/libs/1_60_0/libs/filesystem/doc/reference.html#tem p_directory_path) and found the following issues with Android devices: - It should first try to get the application's cache directory from the API level 1 "getCacheDir" so that temporary files created by the application can be easily and automatically removed. - The function fails back to the hard coded value "/data/local/tmp". But I think it should use the environment variable "ANDROID_DATA" when available and append "/local/tmp" to it. - The "/data/local/tmp" folder is denied access on my Android device. I don't have any other suggestion than the application's cache folder like I first mentioned. I'm not a core developer and the information provided on this email maybe erroneous or incomplete. My apologies if I'm entirely wrong. Thanks, Claude Petit

1 0

Contribution to Boost as Developer
by aman kumar singh 11 Feb '16

11 Feb '16

Developers, I am Aman Kumar Singh,Senior Year,NIT Mizoram,India(Computer Science and Engineering).I am new to open source development. I like coding especially in C++.I have 6 years of working experience in C++.I am very much interested in contributing to open source development especially in Boost.I want to apply for Google Summer of Code 2016 in future.Can somebody help me out.I am ready to dedicate my full time to it once I get aware of the system fixing bugs and further contributing to big projects. I am left with very less time for GSoC and this time I want to be part of it.Please help me out. Thanking you, Aman Kumar Singh, NIT Mizoram, India

1 0

problem with ASIO
by Juan Dent 10 Feb '16

10 Feb '16

Thank you so much Bjorn Reese!! you solved my problem with ASIO. My instincts were correct in that the stream was destroying the std::cout. ::dup() solves this. Best regards, Juan

1 0

Re: [boost] Problem with ASIO
by Bjorn Reese 10 Feb '16

10 Feb '16

On 02/10/2016 02:27 AM, Juan Dent wrote: > posix::stream_descriptor stream{ioservice, STDOUT_FILENO}; Here you take over ownership of stdout, so it will be closed by the stream destructor. A quick fix is to pass a copy of the file descriptor with ::dup(STDOUT_FILENO) as shown in the posix_chat_client.cpp example.

1 0

temp_directory_path and Android devices
by doodad-js Admin 10 Feb '16

10 Feb '16

Hi, I have read the specs (http://www.boost.org/doc/libs/1_60_0/libs/filesystem/doc/reference.html#tem p_directory_path) and found the following issues with Android devices: - It should first try to get the application's cache directory from the API level 1 "getCacheDir" so that temporary files created by the application can be easily and automatically removed. - The function fails back to the hard coded value "/data/local/tmp". But I think it should use the environment variable "ANDROID_DATA" when available and append "/local/tmp" to it. - The "/data/local/tmp" folder is denied access on my Android device. I don't have any other suggestion than the application's cache folder like I first mentioned. I'm not a core developer and the information provided on this email maybe erroneous or incomplete. My apologies if I'm entirely wrong. Thanks, Claude Petit

1 0

[ANN] build2 - C++ build toolchain
by Boris Kolpackov 10 Feb '16

10 Feb '16

Hi, build2 is an open source, cross-platform toolchain for building and packaging C++ code. It includes a build system, package manager, and repository web interface. We've also started cppget.org, a public repository of open source C++ packages (where we hope to see Boost one day). This is the first alpha release and currently it is more of a technology preview rather than anything that is ready for production. We have tested this version on various Linux'es, Mac OS, and FreeBSD. There is no Windows support yet (but cross-compilation is supported). The project's page is: https://build2.org For those who need to see examples right away, here is the introduction: https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml Enjoy, Boris

9 19

Problem with ASIO
by Juan Dent 10 Feb '16

10 Feb '16

Hi, I have a problem with the following sample (ASIO 10, part of Boost examples): void f() { { io_service ioservice; posix::stream_descriptor stream{ioservice, STDOUT_FILENO}; auto handler = [](const boost::system::error_code&, std::size_t) { std::cout << ", world!\n"; }; async_write(stream, buffer("Hello"), handler); ioservice.run(); std::cout << "hhh\n"; } // in this line and afterwards, no output will be seen through std::out!! ( it is somehow damaged or destroyed by the destructor of the *stream* object!! std::cout << “This will not print\n"; } As explained in the line comment, when stream is destroyed some permanent damage is done to the std::out object which will not output any more after executing the code in the nested block. I believe the stream should be somehow disconnected from STDOUT_FILENO before its destruction so it does not “harm” std::out. Any ideas? Thanks!! Juan

1 0

[block_ptr] Request for a review manager
by Phil Bouchard 09 Feb '16

09 Feb '16

Greetings, As some of you might know I work full time on WebKit which in turn uses a garbage collector for its Javascript interface and quite honestly a garbage collector is not ready for a commercial release unless you have a lot of CPU juice. So a garbage collector is unacceptable. On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.… Please let me know if you are interested for me to present it and answer questions live. Sincerely, -Phil www.unifiedfieldtheoryfinite.com

6 17

recompile with -fPIC
by Marwa Refaie 09 Feb '16

09 Feb '16

Hi I try to compile "cdec" translation package , I been stuck in this error : ______________________________________________________________________________ /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libboost_system.a(error_code.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libboost_system.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status error: command 'g++' failed with exit status 1______________________________________________________________________________ I red solution like bjam boost without debug or specifiy -fPIC !!! Any help to apply any solution ?? How should I fix plz ?? Marwa N. Refaie

1 0

[smart_ptr] Interest in the missing smart pointer (that can target the stack)
by Noah 09 Feb '16

09 Feb '16

Hi all, I'm new here. Here goes: I propose a new smart pointer called, say "registered_ptr", that behaves just like a native C++ pointer, except that its value is (automatically) set to null_ptr when the target object is destroyed. This kind of smart pointer already exists and is being used in the form of, for example, QPointer and Chromium's WeakPtr (http://doc.qt.io/qt-5/qpointer.html and https://code.google.com/p/chromium/codesearch/#chromium/src/base/memory/wea…) although those implementations only apply to a specific set of object types. There's also std::experimental::observer_ptr (http://en.cppreference.com/w/cpp/experimental/observer_ptr) which seems to be trying to serve a similar purpose, but with none of the functionality. This might be as far as you need to read to decide if you think it's a good idea or not. The rest of this (kind of long) post addresses some of the details and motivation. It's instructive to compare this "registered_ptr" with (std::)shared_ptr. Both have a (modest) performance cost, although registered_ptr's performance cost is significantly lower, as will be discussed later. Both can have a significant "code safety" benefit when used for that purpose - i.e. reduce or eliminate the possibility of invalid access of an object that has already been destroyed. And both have a functional purpose other than safety or convenience (or just being a regular pointer). That functional purpose is to deal with situations when it is not easy to predict in advance (i.e. at compile time) when an object will be referenced (and stop being referenced). shared_ptr deals with these type of situations by ensuring that the object remains "alive" for as long as there are any (owning) references to the object. This assumes that the object has no "curfew". But one can imagine situations where an object needs to be destroyed at or by a certain time or event. If the object is exclusively holding an in demand resource, or security lock for example. In these cases one might prefer that late attempted references to the object fail (safely) rather than have the object's destruction delayed. registered_ptrs might be more suitable for these situations. So from this comparison it's hard to argue for the inclusion of shared_ptr and the omission of registered_ptr in the library. registered_ptr can be thought of as a kind of "non-intrusive" counterpart to shared_ptr. "But wait", you say, "shared_ptr already has a non-intrusive counterpart. Namely weak_ptr." Yes, but the difference between weak_ptr and registered_ptr is that registered_ptr is independent, not just an appendage of shared_ptr. And registered_ptr can point to stack allocated objects (just like native C++ pointers can), but at the cost of "thread safety". Referencing an object on another (asynchronous) thread's stack is inherently not safe, right? Some may be concerned with this lack of thread safety - I am not, I don't think we should be encouraging casual asynchronous object sharing - but the performance dividend of getting to put the target object on the stack rather than the heap more than makes up for it in my opinion. So I've actually already had cause to implement, and use, a version of this "registered_ptr" (I actually called it "TRegisteredPointer"), and in practice it works great. But there are, arguably, a couple of issues. Besides the thread safety (non-)issue, my implementation can only target types that can act as base classes. By default most classes can act as a base class, but native types like int, bool, etc. cannot. In my case, this is not a big issue because TRegisteredPointer is actually part of a small library that includes (safer) substitutes for int, bool and size_t that can act as base classes. The good thing is that it does seem to serve its purpose of not only being safe, but also faster than shared_ptr. Much faster when targeting stack objects as one would expect, but also faster when targeting heap objects according to my simple benchmarks (msvc2013 - Windows 7 - Haswell). My implementation can be found here: https://github.com/duneroadrunner/SaferCPlusPlus. It's in the file called "mseregistered.h". Examples of it in action can be found in the file called "msetl_example.cpp", near the end. No decent documentation yet, but the examples are commented and it should be clear what's going on. So far I've posited that the argument for registered_ptr is at least as good as the argument for shared_ptr. But let me make a further argument for why I think it's particularly important to include registered_ptr. First, let me make an argument for "safe" pointers in general. By safe pointers, I mean pointers that have zero chance of participating in a dereference to invalid memory. This will usually imply that the safe pointer will do a runtime check and throw an exception if an invalid dereference is attempted. Now, I subscribe to the C++ "trust the programmer" philosophy, so I agree that programers should have the option of avoiding these runtime checks. But security (and by extension, language safety) is so important these days that programmers should also have the option of having these runtime checks when desired. So I'm suggesting that all the smart pointers (shared_ptr, unique_ptr, etc.) come in "safe" versions as well. There is already some precedent for safe and unsafe options. For example, std::vector<> provides both the "unsafe" [] operator and the "safe" at() function. And ultimately it needs to be properly measured, but I would think that the performance cost of this kind of runtime check should be quite modest. There is plenty of opportunity for optimizing compilers to strip them out when not needed and of course these sorts of runtime checks are a favorite food of branch predictors in modern cpus right? I haven't put a lot of effort into this, but my simple benchmarks show checked dereferences being only modestly slower than unchecked dereferences. (The "msetl_example.cpp" file includes some simple benchmarks.) So why does this make registered_ptr so important? Because the "safe" version of registered_ptr would be the safe pointer with the lowest performance cost. Perhaps low enough for the safety benefits to be widely considered worth the cost. Of course the ideal would be smart pointers that could distinguish between stack allocated objects and heap allocated objects. Unfortunately, as far as I know, (standard) C++ doesn't seem to give us that facility. If we can't have those, I think we need a smart pointer that can at least accommodate stack allocated objects. Right? Noah

10 45