- Boost - lists.boost.org

Need help >> Boost's managed_shared_memory usage in between two processes (C and C++)
by vijay sharma 09 Oct '17

09 Oct '17

Hi, I am having a Design/Implementation issue with Boost managed_shared_memory. Let me describe it: -------------------- Problem ------------------------- I am having two processes (i) Writer (ii) Reader Here Writer is a c++ executable which is using boost to write in shared memory. Code snapshot for writing method: shm_controller.reset(new boost::interprocess::managed_shared_memory( boost::interprocess::open_or_create, shmName, size));void * addr = shm_controller->allocate(size) ; shm_controller ->deallocate(addr); Once I have addr pointer, I am using memcpy to write in SHM. On other hand I am having Reader, which is C executable. They both are communicating via message passing application. I wrote Reader code in such way: Writer is passing address, which is stored in "addr" (from above code snapshot) to Reader. Once reader receive the address and size, I am using memcpy to write SHM data in Reader's local variable. Note1:- (This reader is not using any boost shm API, as it's C application ) Note2:- I validated address is same on Writer and reader (after communication). But reader's memcpy to read shm data is leading crash in my executable (reader). ------------------------------------------------------------- I need help in : 1) Can we use boost::interprocess::managed_shared_memory in C ?? 2) Is there any implementation problem in above section. (can't a reader access shm of writer via pointer) 3) Is there a way to solve this C and C++ limitation like any wrapper implementation etc. Please provide me any kind of help or pointers on this issue, as I am stuck with this and need to resolve it ASAP. Thanks, sharmavijay1991(a)gmail.com

2 3

Appveyor setup for msvc-14.1 toolset
by Edward Diener 09 Oct '17

09 Oct '17

I have added an Appveyor test to some Boost libraries, but if I specify toolset=msvc-9.0,msvc-10.0,msvc-11.0,msvc-12.0,msvc-14.0,msvc-14.1 on the b2 test script command line the run fails when it gets to 14.1, due to not finding 'cl', but succeeds for the others. What is the magical Appveyor incantation to test the latest VC++ ? I would like to avoid the environment/matrix gunk I see in other appveyor.yml files, but if it is the only way to get msvc-14.1 tests with Appveyor I will use it.

3 3

[review] The review period of Boost.DoubleEnded has ended -- thanks to all involved
by Thorsten Ottosen 09 Oct '17

09 Oct '17

Dear users and members of Boost, We are now done with the review of Benedek Thaler's Boost.DoubleEnded library. Many thanks to all those involved in discussions and reviews. It will take me some time to digest all the feedback and get back with the review results. kind regards Thorsten, review manager -- Best regards, Thorsten Jørgen Ottosen, Ph.D. Director of Research +45 23308797 Dezide (www.dezide.com)

1 0

Boost.Http parser documentation ready (feedback welcome)
by Vinícius dos Santos Oliveira 09 Oct '17

09 Oct '17

Hi, first of all, do not confuse this “Boost.Http” library with the one who was rejected in the Boost review. I've received financing[1] from Boost to write an HTTP parser and here it is, just a parser. The documentation has 4 tutorials. You may have special interest in the “tutorial #4: implementing Boost.Beast parser interface” where I answer why you don't want to use Boost.Beast parser. https://vinipsmaker.github.io/asiohttpserver/ Feedback welcome. [1] https://gist.github.com/vinipsmaker/4998ccfacb971a0dc1bd -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

1 0

GITHUB - How does one add another maintainer to a repo
by Robert Ramey 08 Oct '17

08 Oct '17

I'm maintainer of the boost serialization library. Is there a simple way to give update permission to other persons? What is it. Ideally I'd like to do it at the branch level. I've looked through the GitHub help, and as usual, I'm mistified. Robert Ramey

2 2

[thread][build] develop terminally broken?
by John Maddock 07 Oct '17

07 Oct '17

All CI tests are currently failing with: ./b2 headers /home/travis/build/boostorg/boost-root/tools/build/src/build/feature.jam:140: in feature from module feature error: feature already defined: error: in feature declaration: error: feature "threadapi" : "win32" "pthread" : "optional" "propagated" /home/travis/build/boostorg/boost-root/libs/thread/build/threadapi.jam:4: in load from module threadapi /home/travis/build/boostorg/boost-root/tools/build/src/kernel/modules.jam:295: in modules.import from module modules /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:1069: in import from module Jamfile</home/travis/build/boostorg/boost-root/libs/thread/build> libs/thread/build/Jamfile.v2:39: in modules.load from module Jamfile</home/travis/build/boostorg/boost-root/libs/thread/build> /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:325: in load-jamfile from module project /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:64: in load from module project /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:89: in load-used-projects from module project /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:75: in load from module project /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:145: in project.find from module project /home/travis/build/boostorg/boost-root/tools/build/src/build-system.jam:535: in load from module build-system /home/travis/build/boostorg/boost-root/tools/build/src/kernel/modules.jam:295: in import from module modules /home/travis/build/boostorg/boost-root/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /home/travis/build/boostorg/boost-root/boost-build.jam:17: in module scope from module Any ideas? Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

4 5

[contract] auto_..._error regression tests fail on C++1z
by Lorenzo Caminiti 04 Oct '17

04 Oct '17

Hello all, I asked this question on compl.c++ list as well, given this is more of a general C++1z question than a Boost question. However, this is making some Boost.Contract regression tests fail on C++1z compilers so I wanted to ask it here as well hoping to get some info more quickly... Following code prevents copies outside its friend function f: // File: 05.cpp struct x { x() {} private: x(x const&) {} x& operator=(x const&) { return *this; } friend x f(); }; x f() { return x(); } int main() { auto xx = f(); return 0; } Correctly it does not compile up to C++1y because main cannot access the copy operations: $ clang++ -std=c++1y 05.cpp 05.cpp:14:15: error: calling a private constructor of class 'x' auto xx = f(); ^ 05.cpp:5:5: note: declared private here x(x const&) {} ^ 1 error generated. However, it compiles on C++1z?! $ clang++ -std=c++1z 05.cpp # Not compiler errors?! Why... what changed in C++1z that makes the above compile? How can I prevent copying x outside its friend function f in C++1z? Thanks, --Lorenzo

6 7

[outcome v2] How important is it that an Expected implementation is also provided?
by Niall Douglas 04 Oct '17

04 Oct '17

Dear list, I know it's been a fair few months since any news on Outcome v2. Ordinarily I'd be speaking at CppCon happening right now, but I instead chose Jens' Meeting C++ in November where I'll be speaking on Expected. Outcome v2 has undergone its period of maturation since it was completely rewritten to reflect peer review feedback last May. The new consensus design has fared very well after being put under heavy production use these last few months, and I expect it to return here for a second review before the end of this year. Outcome v2 will also be appearing in the WG21 October mailing, watch out for: * P0762R0: Concerns about `expected<T, E>` from the Boost.Outcome peer review * P0779R0: Proposing `operator try()` Outcome v2 currently implements the not published yet D0323R3 Expected proposal as part of its test suite as a refinement of what boost-dev thought Expected ought to be instead of what it is (ahem!). We run it against the Expected reference test suite, and it passes. So here's the question before any second peer review. Should Outcome v2 provide: 1. No Expected implementation at all, not even under a different name. Not its place. 2. The Expected implementation which the consensus on boost-dev felt the WG21 Expected ought to be (this is the current situation, and no we don't call it `expected<T, E>`). 3. A closely conforming, but not exactly conforming [1], implementation of WG21 Expected. Options 2 and 3 can be combined. But be aware that Peter rolled together an even more conforming Expected implementation using his variant2 library. I had been assuming people would be better advised to use his likely exactly conforming implementation, rather than Outcome v2's not exactly conforming implementation. Less surprise. Thoughts? Niall [1]: Known differences from P0323R3 `expected<T, E>` in this implementation: - `T` and `E` cannot be the same type. - No variant storage is implemented (note that technically speaking, D0323R3 does not require variant storage). -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 5

Boost CMake update
by paul 04 Oct '17

04 Oct '17

Hi all, So I have been working at converting more of boost tests to cmake utilizing the BCM library, here: https://github.com/boost-cmake/boost/tree/1.64 This is a build of Boost 1.64, with a majority of the tests integrated. There is still much more work needed to update the tests, as there are some that still fail. Also, some of the libraries were skipped due to missing headers in the 1.64 tag. You can check the library yourself by running cmake: cd build mkdir build cmake .. cmake --build . --target check This will build all the tests. You can check the tests for one target with: cmake --build . --target check-boost_core Which will run the tests for just `boost_core`. This was all generated using scripts in https://github.com/pfultz2/boost-cmake I plan to update this to a newer version of boost. If anyone has fixes or changes they can send a PR or issue on either repos, and I will try to incorporate them in. Thanks, Paul .

8 35

[beast] Supporting ICY 200 OK
by Vinnie Falco 04 Oct '17

04 Oct '17

Bjorn brought up the point that there are some niche cases where applications do not strictly follow the HTTP message syntax for responses. Specifically, for Shoutcast(?) / Icecast mp3 servers the status-line in the response looks something like this: ICY 200 OK\r\n I have thought about ways to support this directly in Beast but I have decided against it. "ICY 200" is not HTTP according to the RFC, and trying to accommodate this use case places needless technical debt in public interfaces. However, I came up with a very simple technique to make this work with Beast by writing just a tiny bit of extra code. The solution is to implement a stream wrapper which meets the requirements of SyncReadStream[1] and/or AsyncReadStream[2] and forwards the calls to read to the "next layer" object, which will be the actual socket or ssl::stream. The implementation of the icy_stream wrapper can check to see if the first 3 bytes received from the next layer match "ICY" and if so, return a buffer to the caller which replaces those characters with "HTTP/1.1" (or "HTTP/1.0"). With this wrapper, calls to beast::http::read or beast::http::async_read can parse the custom response as a regular HTTP message. The wrapper can embed state information to inform the caller if the "ICY" string was not received. The declaration for such a wrapper might look like this: template<class NextLayer> class icy_stream; Usage for the wrapper: asio::ip::tcp::socket sock{ios}; icy_stream<asio::ip::tcp::socket&> stream{sock}; beast::http::response<beast::http::empty_body> res; beast::multi_buffer buffer; beast::http::read(stream, buffer, res); This technique may of course be generalized to support any desired similar but non-standard HTTP requests or responses in a fashion that is completely transparent to Beast. Thanks [1] <http://www.boost.org/doc/libs/1_65_1/doc/html/boost_asio/reference/SyncRead…> [2] <http://www.boost.org/doc/libs/1_65_1/doc/html/boost_asio/reference/AsyncRea…>

2 4