- Boost - lists.preview.boost.org

copied boost files in other projects
by Oliver Kowalke 12 Dec '16

12 Dec '16

I encountered some projects that have copied files from boost and replaced the copyright and license notice by their own. Other projects have added their own license (for isntance MIT, LGPL ...) beside the Boost license notice in the copied files - does this mean that the code is dual licensed now?. How does the boost community deal with this? Oliver

9 16

Review period has ended for the Synapse library
by Edward Diener 12 Dec '16

12 Dec '16

The review period has officially ended for the Synapse library by Emil Dotchevski. I have received one e-mail specifying a review that will come sometime today and therefore will wait before making my decision as Review Manager for that review and Emil's possible response. I would like to thank all those who took part in the review during the review period, and Emil for responding to the remarks of those who have participated. I know another library will shortly begin its review, but I will not rush my final analysis and decision regarding Synapse and intend to make it sometime by the end of this week. Edward Diener, review manager

1 0

Re: [boost] [synapse] Synapse library review starts today December 2
by Barrett Adair 12 Dec '16

12 Dec '16

On Fri, Dec 2, 2016 at 8:19 AM, Edward Diener <eldiener(a)tropicsoft.com> wrote: > - What is your evaluation of the design? I don't know anything about Signals2, but I find the "non-intrusive" argument to be compelling. I don't like that the invocation mechanism is single-threaded by default. I think the thread_local approach is interesting, but it sounds ripe for confusion in application code. > - What is your evaluation of the implementation? This code style is quite foreign to me, but it seems consistent. The mix of Boost and std libraries seems arbitrary (e.g. boost::shared_ptr and <thread>). The Boost.Function dependency appears redundant. The callback is effectively being erased twice. std::invoke or equivalent could serve as a replacement. I don't much like signal_traits.hpp and the limitations it imposes. Arity is capped at 4 parameters, and the signal type must be passed explicitly. The latter is surely good for compile times, but I think it would be nice to have a deduced signal type version that could still support stateful lambdas and member functions. I browsed the test cases, and they seem rather in-depth. I think some comments in this code are warranted. > - What is your evaluation of the documentation? The tutorial is very well done. Overall, the documentation is very solid. I enjoyed reading it. Quickbooks and syntax highlighting would be nice. This line was disappointing: "requires compiler support for the following C++11 features" I have seen this in existing Boost library documentation, so there is precedent, but I do not like it at all. I much prefer to see a range of tested compiler versions, even if it's only a couple. Continuous integration services like Travis and Appveyor are free, and very useful toward this end. > - What is your evaluation of the potential usefulness of the > library? It appears that it could be useful to Qt users. I personally would not find this useful. > - Did you try to use the library? With what compiler? Did you > have any problems? I ran the logger example with GCC 5.3 on Ubuntu 16.04. No problems. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? 4 hours combined of reading the documentation and playing around with the implementation code. > - Are you knowledgeable about the problem domain? My experience with C++ signal libraries is limited. I am comfortable using the Intel TBB flow graph library, which has some degree of overlap. I have a bit of experience with event-driven programming in other languages. I am knowledgeable about C++ callable types and compiler support for their variations. > - Do you think the library should be accepted as a Boost library? This is my first formal review participation, I don't have a library in Boost, I'm not familiar with Signals2, and I do not have a use case for Synapse, so I'm not going to answer this question. Please consider this message as a "technical comment" instead. P.S. For whatever it's worth, I did fork the Synapse code and implement tentative variadic support in connect.hpp and emit.hpp (though I did not get around to translate.hpp). https://github.com/zajo/boost-synapse/compare/master...badair:master It appears to work as-is with the logger example, but similar work would need to be done in translate.hpp to make it fully variadic. I used my proposed CallableTraits library with the intention of implementing deduced signal types, but I ran out of willpower. Please forgive the aggressive formatting.

2 1

Boost.IOStreams mapped_file_sink missing flush() functionality
by AB 11 Dec '16

11 Dec '16

Hello, I wish to bring to your attention two issues regarding mapped_file_sink from Boost.IOStreams (release 1.62.0): 1. There is no member function `mapped_file_sink::flush()` which I would like to use in my program. I believe it could be implemented portably by using `msync()` for POSIX and `FlushViewOfFile()` for Windows; was the omission of this function a deliberate choice or a minor oversight? 2. The member functions `begin()` and `end()` are implemented for mapped_file_sink but are not documented! This will lead to programmers relying strictly on the docs to use `data()` and `data()+size()` instead. Please update the documentation for the next release 1.63.0.

3 3

[1.63.0] Master is closed for beta release + release notes
by Daniel James 10 Dec '16

10 Dec '16

Hello everyone, The master branch is now closed for the beta release. Please can you add any remaining entries to the release notes, either by emailing me, or by creating a pull request at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_63_0.q… To do so, click on the little pencil icon at the top right of the code. thanks, Daniel

4 3

Synapse library review final 2 days
by Edward Diener 10 Dec '16

10 Dec '16

Today and tomorrow are the last 2 days of the review of the Synapse library by Emil Dotchevski. If anybody intends to review the Synapse library but cannot finish their review this weekend, but will be able to finish their review by this coming Monday, please e-mail me and I will take into account your review when making my decision as Review Manager. I encourage all those who are interested in signal/slot programming to look at Synapse and make a review. Synapse is a signal programming library, similar to Boost Signals2 and the signals-slots system in Qt. The main difference is that Synapse is non-intrusive: the address of any object of any static type whatsoever can be passed to synapse::emit to emit a signal. This makes it possible to emit Synapse signals from objects of third-party types as well as system objects (e.g. standard FILE pointers, HWNDs, etc.) or any other object that can be converted to a pointer. The library has been formatted to fit the Boost directory and namespace structure. To get Synapse, clone 'https://github.com/zajo/boost-synapse.git' into a directory called 'synapse' under your boost/libs directory. See the tutorial at 'http://zajo.github.io/boost-synapse/Tutorial.html', or read full documentation at 'http://zajo.github.io/boost-synapse/index.html'. You can also view the documentation locally from your clone of the library at boost/libs/synapse/doc/index.html.

1 0

[stacktrace] Prereminder of Boost.Stacktrace review starting 14th
by Niall Douglas 10 Dec '16

10 Dec '16

I know we are all likely feeling a bit of tired of reviewing potential new Boost libraries, but I just wanted to remind everyone that Antony's Stacktrace library will start its peer review this coming Wednesday Dec 14th with the review lasting until just before Christmas, Dec 23rd. I appreciate this reminder is a little early given the Synapse review doesn't finish until tomorrow, but today I have the time to do email using both hands, and I likely won't get the time again until next weekend (newborns force a lot of single handed typing with your neck twisted hard to the side. Very slow). Edward I hope this doesn't get in the way of concluding your very interesting review. Antony's Stacktrace library adds a long overdue facility to Boost, a formal portable API for obtaining and parsing the call stack of a thread of execution. It has three user selectable backends, tries to provide a maximum performance (nomalloc) stack capture and I think by now can serialise stacktraces to storage. I'll be honest in saying I sent a long list of fairly strong concerns I had with the design and implementation to Antony last month, but I'll defer in the review to whatever the community votes (increasingly me and the Boost consensus seem to be diverging on what makes for good design and practice). I'll make the formal review announcment on Wednesday, but for those wanting to get started early go to: Github: https://github.com/apolukhin/stacktrace Docs: http://apolukhin.github.io/stacktrace/index.html Regards, Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

[fusion] Compilation errors on Intel compiler (C++14)
by Andrey Semashev 08 Dec '16

08 Dec '16

Hi, I'm seeing compilation errors coming from Boost.Fusion headers on Sandia-intel-17.0-c++14: http://www.boost.org/development/tests/develop/developer/output/Sandia-inte… Notably, the same tests compile fine in C++11 mode on the same compiler, which makes me think that is related to C++14 mode specifically. Looking at the code, it seems the compiler makes constexpr functions implicitly const-qualified even though it shouldn't in C++14 mode, so it's likely a compiler bug. Still, is it possible to add a workaround?

3 3

Solaris Boost Install headaches
by Paluzzi, Aaron 08 Dec '16

08 Dec '16

Hello, I'm currently banging my head against a Boost install on Solaris 10 Sparc. I started with a 1.57 download and install. This had mild success using the "Getting started" documentation with some compilation errors. I've been asked to upgrade this to 1.62, and now I'm getting errors as follows when I run ./bootstrap.sh $ ./bootstrap.sh -n Building Boost.Build engine with toolset ... Failed to build Boost.Build build engine Consult 'bootstrap.log' for more details In the Bootstrap.log file I get the following: ./build.sh: syntax error at line 135: `machine=$' unexpected I've been unable to find any further documentation on this error. Any assistance would be appreciated. Actually an in depth install guide for Solaris would be appreciated. I've had no issues on Windows, but Solaris is giving me migraines.

2 1

Synapse library review ongoing
by Edward Diener 07 Dec '16

07 Dec '16

We are in our final 5 days of the review of the Synapse library. We have had some good discussions about Synapse for those willing to review the library, but we really need much more from those who are, or might be, interested. Without wishing in any way to limit reviews or discussions to specific topics I would like to suggest to those interested in the library that they might address soem of these particular questions about Synapse in their commenst or review: 1) Is the documentation understandable for programming with Synapse ? 2) Does the library successfully achieve what it says it can do, providing a non-intrusive signal/slot system ? 3) Is the Synapse syntax easy enough for a programmer to use ? 4) Does testing show that Synapse works with user's code ? 5) Is the design of the library clear enough and flexible enough to make working with it viable ? While I realize that much of the discussion has been about particular end-user's preferences for a signal/slot library or Synapse's way of doing signal/slot programming versus Boost Signals/Signals2, all important topics in a review, it would be helpful if reviewers or commenters would consider Synapse for what it does do, even if they might not personally find a use for it in their programming tasks. ----------------------------------------------------------------------- Synapse is a signal programming library, similar to Boost Signals2 and the signals-slots system in Qt. The main difference is that Synapse is non-intrusive: the address of any object of any static type whatsoever can be passed to synapse::emit to emit a signal. This makes it possible to emit Synapse signals from objects of third-party types as well as system objects (e.g. standard FILE pointers, HWNDs, etc.) or any other object that can be converted to a pointer. The library has been formatted to fit the Boost directory and namespace structure. To get Synapse, clone 'https://github.com/zajo/boost-synapse.git' into a directory called 'synapse' under your boost/libs directory. See the tutorial at 'http://zajo.github.io/boost-synapse/Tutorial.html', or read full documentation at 'http://zajo.github.io/boost-synapse/index.html'. You can also view the documentation locally from your clone of the library at boost/libs/synapse/doc/index.html.

1 0

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 07 Dec '16

07 Dec '16

>boost.asynchronous looks to have many of the same features/functionality as HPX. >Can I ask why you chose to reimplement futures/lightweight thread pools/parallel STL/etc, >rather than working on improving HPX to suit your needs? I don't think the libraries have the same goals (or at least it seems to me so). Asynchronous is first of all an architecture tool focusing on organizing a whole application into thread worlds. The libraries also do not have the same design / tradeoffs. Asynchronous can make use of futures but encourages callbacks and tries to make these as safe as possible. The goal is to be as asynchronous (meaning non-blocking) as possible. It is no coincidence that I'm also the author of Boost.MSM. The encouraged design is a whole lot of state machines, each in its own thread (possibly sharing a thread), sending tasks to threadpools, TCP connections, etc. and waiting for callbacks. Future-based designs do not mix well with state machines' run-to-completion. The reason for the non-blocking focus is that I'm using the library at work in an industrial 24/7 application. When working on the production line, blocking is a disaster. If an algorithm goes astray, or simply takes longer than usually, blocking the production line results in huge costs. Crashes due to races also. Asynchronous provides ways to avoid both. >JB >Disclaimer : I have contributed o HPX, but I'm not one of the "German HPC Guys" :) . No hard feeling. I'm grateful for participation and the chance to explain the underlying ideas of the library. Thanks, Christophe

4 25

[serialization][test] failures in serialization causing regressions
by Barend Gehrels 06 Dec '16

06 Dec '16

> The regression matrix in develop of Boost.Geometry contains many new > compilation failures due to: > > > 1) : D:\t08\run\boost_root\boost/serialization/array.hpp(25) : error C2039: 'array' : is not a member of 'std' > > 2): > ../boost/numeric/ublas/storage.hpp: In member function ???void boost::numeric::ublas::unbounded_array<T, ALLOC>::serialize(Archive&, unsigned int)???: > ../boost/numeric/ublas/storage.hpp:331:18: error: ???make_array??? is not a member of ???boost::serialization??? > ar & serialization::make_array(data_, s);and a > > > The master is still OK. > > Can this be solved? Ping! This is still the case! Robert, can you explain this? It is (of course) not only geometry failing, also ublas or (if there are) other libraries with ublas dependencies: http://www.boost.org/development/tests/develop/developer/numeric-ublas.html All yellow! Thanks, Barend

3 8

Re: [boost] [process] Formal Review starts today, 27 October
by Bjorn Reese 04 Dec '16

04 Dec '16

On 10/27/2016 08:26 AM, Antony Polukhin wrote: > - Whether you believe the library should be accepted into Boost > * Conditions for acceptance I withhold judgement for now to give the author an opportunity to respond. At the moment I am unsure whether to vote for conditional acceptance or rejection. > - Your knowledge of the problem domain Advanced on Unix. > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design I have a couple of serious concerns. My first concern is about the use of tagged arguments, and especially the redirection operators, in constructors. Instead I propose that the library uses the Named Parameter idiom (see [1], not to be confused with what Niall labelled "tagged name parameter" idiom.) The bp::child object should not execute in the constructor, but rather via operator(). That way we can use the named parameter idiom to build up redirections and similar modifications. For example: auto compile = bp::child("c++").output(bp::null); compile("main.cpp"); // Executes My second concern is about deadlocking. The FAQ shows two ways of deadlocking. I would expect the latter (the ls example) to work without further ado because that is how any newcomer would write their code. My third concern is about the chaining of pipes between processes. The tutorial shows an example where the output of the nm command is forwarded to the c++filt command. However, the forwarding is not done directly from the nm process to the c++filt process, but goes via the parent process. This can incur a performance degradation when nm generates much output. Is it possible to chain them directly? Besides "nm myfile | c++filt" that is. I also have the following minor comments / questions. Is it possible to redirect stderr to stdout? (like 2>&1). The reference documentation only mentions this under asynchronous pipe output. The bp::starting_dir should be renamed to bp::current_path to be consistent with Boost.Filesystem. Consider renaming bp::spawn to avoid confusion with boost::asio::spawn which is how you launch coroutines with Boost.Asio. I am missing a this_process::get_id() function to return the current process identifier. > * Implementation My major concern with the implementation is that the library is only header-only, so I cannot compile it as a static library if I wish to. There are several Boost header-only libraries that allows you to do that. The reason why I find this important for Boost.Process is because I want to avoid getting platform-specific C header files included into my project when I include a Boost.Process header. The library should throw its own process_error exception which inherits from system_error, similar to Boost.Filesystem. I did not investigate the implementation in greater detail. > * Documentation The documentation is lacking an entire chapter with an overall description of the library and the concepts used. For instance: * What are processes and pipes? * What are the possible invocation mechanisms? Some of this is mentioned in the Design Rationale, but that is not the place where developers seek their information. * How to set search paths or the current working directory. * How to use environment variables. * this_process Tutorial / Synchronous I/O: What is the default behaviour when I/O redirections are not specified? Tutorial / Asynchronous I/O: Consider including an example with boost::asio::spawn as a way to obtain the yield context. Reference / child: Does not mention how the life-time of the object and the child process are related. For instance, the documentation on the destructor only mentions that it is a destructor. Reference / cmd: bp::cmd will parse the input string as a sequence of space-separated arguments. Is it spaces or whitespaces? Is it possible to have escapes for arguments that do contain spaces? > * Tests Did not investigate. > * Usefulness A process library is a very useful addition to Boost. > - Did you attempt to use the library? If so: > * Which compiler(s) > * What was the experience? Any problems? Did not try. > - How much effort did you put into your evaluation of the review? About 4-5 hours (one of which was gratuitously donated by daylight saving time.) [1] https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Named_Parameter

11 49

API/ABI changes report for Boost
by Ponomarenko Andrey 02 Dec '16

02 Dec '16

Hello, The report on API/ABI changes in the latest releases of Boost: https://abi-laboratory.pro/tracker/timeline/boost/ The report is generated by the open-source abi-tracker tool and updated three times a week. Hope it will be helpful for users and maintainers of the library. Thank you.

1 0

[poly_collection] Request for comments: fast polymorphic collections
by Joaquin M López Muñoz 02 Dec '16

02 Dec '16

A couple of years ago I wrote two blog entries about high-performance data structures for polymorphic objects: http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.html that spurred some interest in the community. Now I've had the time to turn these ideas into something resembling a full-fledged library: https://github.com/joaquintides/poly_collection http://rawgit.com/joaquintides/poly_collection/website/doc/html/index.html and I'd be very grateful if people could give their opinion on usefulness, design, etc. so as to determine potential interest in an eventual official submission to Boost. Thank you, Joaquín M López Muñoz

6 21

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 01 Dec '16

01 Dec '16

>After having a deeper dive into the documentation and examples, one >pattern I see popping up quite >frequently is this: >future<R> fut = my_promise.get_future(); >post_callback(some_work, [this](expected<R> r) { >this->my_promise.set_value(r.get()); }); >return fut; This is simply to make examples easier to run (it finishes the example). It demonstrates that the only one which blocks in an application built on Asynchronous is main(). This might be more confusing than useful and I probably should get rid of this. >Is there any performance/usability drawback from this (might have gotten >the syntax wrong here): >return post_future(pool, some_work); > >Why is the former to be preferred to the latter, or vice versa? post_future is the preferred for simple applications or examples. It is similar to std::async (without the problem of blocking futures and with different continuations). post_callback is the design the library seeks to promote for bigger applications: post a task to a threadpool, get a callback posted to the queue of the caller's thread world. >Regarding the documentation overall, >it seems to miss a proper reference section. >For example, boost::asynchronous::expected is used almost >everywhere, but not documented. My bad. Will be corrected. Thanks, Christophe

2 2

Asynchronous library now in Boost Library Incubator
by Christophe Henry 01 Dec '16

01 Dec '16

Dear Community, The Asynchronous library is now listed in the Boost Library Incubator ( http://blincubator.com/bi_library/asynchronous-2/?gform_post_id=1654) I took a lot of time since first presenting it in C++ Now 2014 in order to extend the scope and intensively test the library. The library has been in use in production code for already 1.5 years, has survived billions of calls and usage 24/7, so its core is stable and quite tested. All algorithms have not been used though so that bugs are possible there. The reason for using the Incubator is, the library is quite big and 2 weeks review will not be sufficient so I hope for comments, discussions or pre-reviews earlier on. Asynchronous is first of all an architecture tool. It allows organizing a complete application into Thread Worlds, each world having the possibility to use the same or different threadpools for long-lasting tasks. The library provides an implementation of the Active Object pattern, extended to allow many Active Objects to live in the same World. It provides several Threadpools and many parallel algorithms making use of them. And most important of all, it allows simple, blocking-free asynchronous programming based on thread-safe callbacks. It also provides very useful logging and HTML diagnostics (see https://htmlpreview.github.io/?https://raw.githubusercontent.com/henry-ch/a…) to allow better understanding of code. I look forward to an interesting and lively discussion. Christophe

6 7

Upcoming review of the Synapse library starting tomorrow
by Edward Diener 01 Dec '16

01 Dec '16

The formal review of the Synapse library by Emil Dotchevski starts tomorrow, December 2 and is scheduled to continue through December 11. I will be making an official announcement tomorrow, but I want to give the following information today for anyone wishing to acquaint themselves with the library. As explained previously by Emil Dotchevski when requesting that Synapse be put on the Boost Review list, Synapse is a signal programming library, similar to Boost Signals2 and the signals-slots system in Qt. The main difference is that Synapse is non-intrusive: the address of any object of any static type whatsoever can be passed to synapse::emit to emit a signal. This makes it possible to emit Synapse signals from objects of third-party types as well as system objects (e.g. standard FILE pointers, HWNDs, etc.) or any other object that can be converted to a pointer. The library has been formatted to fit the Boost directory and namespace structure. To get Synapse, clone 'https://github.com/zajo/boost-synapse.git' into a directory called 'synapse' under your boost/libs directory. See the tutorial at http://zajo.github.io/boost-synapse/Tutorial.html, or read full documentation at http://zajo.github.io/boost-synapse/index.html. The documentaion can also be viewed from the local clone at boost/libs/synapse/doc/index.html. I would urge anyone who may be interested in signal/slot processing in C++ to take a good look at the Synapse library. Edward Diener, review manager

1 0

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 01 Dec '16

01 Dec '16

>I'm trying to digest the docs for this monster work. > >One things that strikes me immediately is that the doc preparation >does not use code snippets, and so code is in boring old >black'n'white rather than colored syntax. >For me, that makes it significantly harder to read (and understand) the code examples. Ok, I'll see if I can improve this. >It also means that one doesn't have the assurance that 'What You See is What Compiles'. For most features, the doc provides a link to an example, which I regularly compile. >(I've also having trouble finding things in all the plentiful 'good stuff'. >But that's a common (and largely still unsolved) >problem with all documentation.) >Paul Please let me know what is the "good stuff" for you and I'll make it more visible. Cheers, Christophe

2 1

[compute] Remove boost::chrono lib dependencie
by Viktor Sehr 01 Dec '16

01 Dec '16

Hi, Would it be possible to remove the dependency for boost/chrono is boost/compute/detail/duration.hpp. As it already supports std::chrono via a macro, couldn't the inclusion of boost/chrono.hpp be excluded? As it is now, boost compute is dependent on having libboost_chrono-vc140-mt-gd-1_62.lib built. /Viktor

4 4

[release] Boost 1.63.0 Beta 1
by Marshall Clow 29 Nov '16

29 Nov '16

The first beta packages for 1.63.0 beta 1 are now available: <https://sourceforge.net/projects/boost/files/boost/1.63.0.beta.1/> The SHA256 checksums are as follows: 3dbc1bca10941710755c13a00b1ae56d2d37fe90bbadcf9746203194f9d33e3a boost_1_63_0.7z c8b986fd57e436fd88dbc70e51d3e21efa2be3bdf835fa499b2cf6c0a8cc2985 boost_1_63_0.tar.bz2 745d99e4be9c0f324ec7ba15b7d228fd780067f2e8aeae2f16660a4cf6e6a051 boost_1_63_0.tar.gz e66bd6e2f637148c314398b92bc1f3cbdc777ee282f9de7885697afad3d9c202 boost_1_63_0.zip As always, the release managers would appreciate it if you download the archive of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

12 21

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 29 Nov '16

29 Nov '16

Hi Vicente, >> In theory, the standard version would suffice, except for Thread. >> Boost.Thread provides interruption points, which the standard does not. >> With the standard version, I would not be able to offer task interruption. >Could you explain why task interruption is associated to thread >interruption? Ah already implementation details :) Tasks are executed in schedulers (uisually threadpools), which manage 1 to n threads. To interrupt a task from outside, the library interrupts the thread running the task. To be exact, the task will be interrupted the next interruption point in encounters. The thread executing the task does not terminate but instead recovers and pops the next task from its job queue. >> I rely for the other parts also on Boost because the standard version had >> bugs on earlier versions of compilers, and quite some projects are still >> stuck with gcc-4.9 or mingw. At some points, it seemed easier to maintain >> using Boost (which also happens to be faster than the standard, at least on >> my tests). >> >Whow, glad to hear Boost.Thread is working for you Henry. It is. I got no problem whatsoever. >I believe that Michael is however right. Boost libraries restricted to >C++11 should use the standard library as much as possible. Sure. At the moment I have no way around Boost.Thread though. If that changes, I'll probably want to switch to standard. The performance issue for the clock is not a huge one and by that time, the older compilers will hopefully have vanished. I could provide a macro to switch between boost / std. If one needn't interrupt tasks, the library would make no use of boost at all. >It would be great to have a specific C++11 (language and standard >library) version of your library. Well, if there is interest, why not? >Good luck with the review, >Vicente >P.S. I've in my todo's list implement thread interruption on top of the >standard as Anthony showed in his book, but I have no time to work on >this now. Oh, it would be great. This really is a fantastic feature. Thanks, Christophe

1 0

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 29 Nov '16

29 Nov '16

Hi Michael, >Thank you for submitting this library to the the incubator in >preparation for a review. I saw your presentation in 2014 >and I believe that this library solves a common problem. >My first question: I see that the library is listed as C++11 and also >has dependencies on Boost.System, Boost.Thread, Boost.Chrono, >and Boost.DateTime. Much of the functionality provided by those >Boost libraries is now part of the C++11 or C++14 standard. >Can you comment on the specific Boost dependencies >and if the standard versions would suffice? A good question which deserves a rationale, which I will add. In theory, the standard version would suffice, except for Thread. Boost.Thread provides interruption points, which the standard does not. With the standard version, I would not be able to offer task interruption. I rely for the other parts also on Boost because the standard version had bugs on earlier versions of compilers, and quite some projects are still stuck with gcc-4.9 or mingw. At some points, it seemed easier to maintain using Boost (which also happens to be faster than the standard, at least on my tests). HTH, Christophe

2 1

[ssl] SSL handshake takes forever sometimes
by Shuchen He 28 Nov '16

28 Nov '16

Hi, I have an application written in boost with SSL. I noticed that when the client network is down for a while and come back again. The SSL handshake sometimes take forever. I tried to kill the client application and run it again, the problem still there. The only way to make it work again was to reboot my client device. I'm using boost 1.60 on the client side and 1.58 on the server side. The SSL handshake code was copied from Boost SSL server and client example I modified a bit to suit my application needs. Does anyone experience the similar issue? If so, can you please let me know how do you fix it? It would be much appropriated if you could help me out on this issue. Below is the SSL handshake code. chat_client(boost::asio::io_service& io_service, boost::asio::ssl::context& context, tcp::resolver::iterator endpoint_iterator) : io_service_(io_service), socket_(io_service, context) { filesize_=0; isfileopen_=false; socket_.set_verify_mode(boost::asio::ssl::verify_peer); socket_.set_verify_callback( boost::bind(&chat_client::verify_certificate, this, _1, _2)); boost::asio::async_connect(socket_.lowest_layer(), endpoint_iterator, boost::bind(&chat_client::handle_connect, this, boost::asio::placeholders::error)); } bool verify_certificate(bool preverified, boost::asio::ssl::verify_context& ctx) { char subject_name[256]; X509* cert = X509_STORE_CTX_get_current_cert(ctx.native_handle()); X509_NAME_oneline(X509_get_subject_name(cert), subject_name, 256); log_time(); fprintf(logfile,"%s: Verifying %s\n",logtime.c_str(), subject_name); return preverified; } void handle_connect(const boost::system::error_code& error) { if (!error) { socket_.async_handshake(boost::asio::ssl::stream_base::client, boost::bind(&chat_client::handle_handshake, this, boost::asio::placeholders::error)); } else { log_time(); fprintf(logfile, " %s Connect to server failed: %s\n ",logtime.c_str(), error.message().c_str()); fflush(logfile); delete this; } } void handle_handshake(const boost::system::error_code& error) { if (!error) { ssl_handshake_ok=1; do_read_header(); } else { log_time(); fprintf(logfile,"%s: Handshake failed:%s\n ",logtime.c_str(), error.message().c_str()); } }

1 0

[poly_collection] request for help at performance testing
by Joaquin M López Muñoz 28 Nov '16

28 Nov '16

Hi, Some days ago I published the first version of (candidate) Boost.PolyCollection at https://github.com/joaquintides/poly_collection Performance tests are available at http://rawgit.com/joaquintides/poly_collection/website/doc/html/poly_collec… but GCC and Clang were run in a Travis VM and the resulting figures are noisy and not sufficiently accurate. I'm looking for volunteers willing to run the performance suite in one or more of the following environments: * Recent GCC, 32 bit * Recent GCC, 64 bit * Recent Clang 32 bit * Recent Clang, 64 bit The full suite in one environment takes 1.5-2h to execute. If you're interested, please contact me privately (so that we don't pollute the mailing list) and I'll provide you with further instructions on how to do the testing. Thank you! Joaquín M López Muñoz

1 0