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

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

[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

[endian] Heads up: breaking name changes coming
by Beman Dawes 15 Dec '14

15 Dec '14

Boost.Endian develop branch is about to have major changes merged in as part of the preparation for a mini-review. AFAICR, the breaking changes are limited to header, class, and function name changes, but there are a lot of hopefully non-breaking changes so I could easily be wrong about that. If you are currently using Boost.Endian develop branch, you will need to change your code accordingly. It would make sense to wait a few days until the mini-review merge is complete and any fixes required by regression test failures are fixed. Thanks for your patience, --Beman

1 0

Re: [boost] List of C++ 11 only Boost libraries and their status?
by Dave Gomboc 14 Dec '14

14 Dec '14

On Sat, Dec 13, 2014 at 08:37 AM, Rogerio dos Santos <rogerio.santos.main(a)gmail.com> wrote: > > On Sat, Dec 13, 2014 at 8:27 AM, Nat Goodspeed <nat(a)lindenlab.com> wrote: >> >> I'm just contradicting the assumption that those who must work with >> old compilers aren't doing any new development, or have no interest in >> new libraries. >> > > To add to this point, I would like to mention that even new developments > trends might require support to old or limited compilers. E.g.: IoT, real > time projects, industrial HMIs and mobile applications. > > Roger Indeed. I work on embedded, real-time industrial control systems in a field where certain specifications (unfortunately, IMO) severely restrict the platform choices available. In many cases, the systems developed must be built using pre-C++98 compiler technology. While that is a problem I am attempting to address, I suspect it is going to take at least another year to do so, and I am confident that at least one of the platforms will probably never support multi-threading even if its vendor does end up improving or replacing its toolchain (and I have no iron-clad guarantee from the vendor that the toolchain will actually be improved or replaced, though I have a reasonable hope). None of the above constraints imply that the libraries developed by Boost are not of use for these systems, or that we are not interested in using Boost libraries to the extent that it is possible to do so. I think it is possible to structure compatibility code so that it doesn't egregiously interfere with future development. I always get nervous when Steve posts asking to hack away the support for a few more of the older toolchains. While I fully appreciate that his end-goal is well-intentioned, there's still important code out there relying upon some of those pre-C++98 workarounds that can still benefit from the fixes and new libraries introduced into new versions of Boost. Consequently, I'm much in favour of allowing Boost library maintainers who wish to retain support for older compilers the latitude to do so. Dave

2 1

List of C++ 11 only Boost libraries and their status?
by Niall Douglas 13 Dec '14

13 Dec '14

For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list: * Boost.Spirit X3 ETA to Boost review: unknown, last commit was June 2014. * Boost.Proto 0x ETA to Boost review: unknown, last commit was Oct 2013. * Boost.Hana ETA to Boost review: Summer 2015, last commit was today. * Boost.AFIO ETA to Boost review: Already in review queue, last commit was two days ago. * Boost.BindLib ETA to Boost review: Q1 2015, last commit was two days ago. * Boost.Spinlock ETA to Boost review: Q2 2015, last commit was four days ago. * Boost.KernelAlloc ETA to Boost review: Q1 2015, last commit was today. * Boost.Expected ETA to Boost review: no later than Summer 2015 probably much earlier, last commit was two weeks ago. * Boost.CRUX ETA to Boost review: hopefully by end of 2015, last commit was three days ago. I have to admit surprise at how long the list I have collected already is. Are there any other C++ 11 only Boost libraries I am missing, or have I got the ETAs wrong? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

24 49

New Feature, MathString.
by Jakub trzciński 13 Dec '14

13 Dec '14

Hi. My name is Jacob and i am new here.i have idea for new feature in boost. Actually i write a little library whitch name MathString. As you see by name the library will be calcule Row's from string. But it's not all. I was write a interface which add own Mathematical functions for row and variables. If you accept my idea i will send whole code. Code for example MathString test("sqrt(x,2)"); test.LinkFunction(&sqrt,"sqrt"); test.pushVariable("x",4); cout<<test.getResluts(); This code will be return 2 (as you know root with level 2 of 4 equals 2)

3 2

C++ Concept-based tag dispatching using the Tick library
by pfultz2 13 Dec '14

13 Dec '14

Hello Everyone, For those interested. I added support for tag dispatching in the Tick. The reason it wasn't added earlier was concern over specialization. So now as a simple example, the `advance` function could be implemented like this: TICK_TRAIT(is_incrementable) { template<class T> auto requires_(T&& x) -> tick::valid< decltype(x++), decltype(++x) >; }; TICK_TRAIT(is_decrementable, is_incrementable<_>) { template<class T> auto requires_(T&& x) -> tick::valid< decltype(x--), decltype(--x) >; }; TICK_TRAIT(is_advanceable, is_decrementable<_>) { template<class T, class Number> auto requires_(T&& x, Number n) -> tick::valid< decltype(x += n) >; }; template<class Iterator> void advance_impl(Iterator& it, int n, tick::tag<is_advanceable>) { it += n; } template<class Iterator> void advance_impl(Iterator& it, int n, tick::tag<is_decrementable>) { if (n > 0) while (n--) ++it; else { n *= -1; while (n--) --it; } } template<class Iterator> void advance_impl(Iterator& it, int n, tick::tag<is_incrementable>) { while (n--) ++it; } template<class Iterator> void advance(Iterator& it, int n) { advance_impl(it, n, tick::most_refined<is_advanceable<Iterator>>()); } Now, specialization is still supported in a sane way. As an example, say there was an iterator called `foo_iterator` that fulfilled the type requirements for `is_incrementable`, `is_decrementable`, and `is_advanceable`, but it had an incorrect `+=` operator on it(perhaps it crahsed at runtime). So `is_advanceable` can be specialized to prevent this problem: template<> struct is_advanceable<foo_iterator> : std::false_type {}; Even though it is specialized to false, it can still dispatch to `tag<is_decrementable>` and `tag<is_incrementable>` tags. You can read more about it here: http://pfultz2.github.io/Tick/doc/html/tag/ Any feedback is appreciated. Thanks, Paul Fultz II -- View this message in context: http://boost.2283326.n4.nabble.com/C-Concept-based-tag-dispatching-using-th… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Duration of formal reviews
by Vladimir Prus 12 Dec '14

12 Dec '14

Some time ago we had a poll about formal reviews problems: https://plus.google.com/u/0/+VladimirPrus/posts/5spgjicc3fv The majority said that ten days are not enough. Of course, it's not very statistically significant, but that's the only data we've got, and we have a rather sparse schedule. How about trying two weeks for a formal review? Thanks, -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

4 3

Is Boost.Xpressive's sregex::compile() thread-safe for an object only used in that thread?
by Chambers, Matthew 12 Dec '14

12 Dec '14

I have a case where I am compiling a dynamic regex based on client code input, and it works except for when I run my multi-threaded unit test 100-1000 times. When I run it with 1 thread, it never fails. When I run it with 2 or 4 threads it fails at this rare frequency. Except on my build server, where it seems to fail most of the time, which is how I learned about the issue to begin with. It's not crashing though, it's just very rarely returning the wrong results, and not always in the same place in the unit test. So I'm trying to understand Xpressive's thread safety. I understand it as far as not using a regex object in multiple threads until it's finished compiling and not sharing a match_results across threads, but what about compiling different regex objects for each thread: if two threads are compiling two different regexes (or even the same const regex string but from different threads, which is possible with my test code), is that ok? I'm seeing this failure on MSVC 12 but I think I also got it with VC10, just not as reliably on the build server (but the build server had to be upgraded to Windows 2012 to install VC12, so maybe that OS change had an effect as well). Thanks, -Matt

2 2

[coroutine] x86 msvc11 stack corruption
by Tobias Loew 12 Dec '14

12 Dec '14

Hi, I use Boost 1.55 uni-directional coroutines to build an x86 MSVC11 application. I have a simple pull-type (boost::coroutines::coroutine<void>::pull_type) that under certain reproducable conditions destroys the stack after returning from the coroutine. Here is the corrupted stack as shown by VS2012 > ebs2000.exe!CScriptMainFrame::DoRun(CPascalEditorDoc * 0x00000000, int 0x00000000, int 0x00000000) Line 3372 C++ ebs2000.exe!CScriptMainFrame::OnDebugStepover() Line 4916 C++ mfc110u.dll!_AfxDispatchCmdMsg(CCmdTarget *, unsigned int, int, void (void) *, void *, unsigned int, AFX_CMDHANDLERINFO *) C++ 00000002() Unknown [Frames below may be incorrect and/or missing] mfc110u.dll!CCmdTarget::OnCmdMsg(unsigned int, int 0x00000000, void *, AFX_CMDHANDLERINFO *) Line 364 C++ mfc110u.dll!CWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line 2785 C++ mfc110u.dll!CFrameWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line 389 C++ ... This only happens in windows x86 32-bit release-builds when the coroutine finishes upon a user-action that also includes a windows WM_SETFOCUS message on my menu-bar. If at least one of the following is true, the stack-corruption does NOT happen: - debug-build - x64 build - using a different pull-type, e.g. enum status_enum{...}; boost::coroutines::coroutine<status_enum>::pull_type - not returning form the coroutine, but pushing just before the end of the coroutine and swapping the pull-type-variable with a default constructed "not-a-coroutine" Even though I have a lot of workarounds, I still would like to know, why this happens. regards Tobias PS: I had to recompile ml /safeseh /c make_i386_ms_pe_masm.asm ml /safeseh /c jump_i386_ms_pe_masm.asm to get SAFESEH-libraries. -- View this message in context: http://boost.2283326.n4.nabble.com/coroutine-x86-msvc11-stack-corruption-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[review] Last day for formal review for Sort library
by Edward Diener 12 Dec '14

12 Dec '14

Today is the last day for the formal review of the Sort library by Steven Ross, which started November 10. We have had some great discussions and reviews so far and I would like to thank everybody involved, but as always we need more formal reviews. If you need any delay for your review after today, please contact me at 'eldiener at tropicsoft dot com' and I will take your review into account if given within a reasonable period of time after today. About the Sort library ================== The Sort library is a library which implements hybrid sorting algorithms based on a Spreadsort ( http://en.wikipedia.org/wiki/Spreadsort ), of which the author of the library, Steven Ross, is the inventor. The algorithm provides a sort that is faster than O(n*log(n)). The library provides a generic implementation of high-speed sorting algorithms that outperform those in the C++ standard in both average and worst case performance. These algorithms only work on random access iterators. They are hybrids using both radix and comparison-based sorting, specialized to sorting common data types, such as integers, floats, and strings. These algorithms are encoded in a generic fashion and accept functors, enabling them to sort any object that can be processed like these basic data types. Where to get it =============== The library is available on github at https://github.com/spreadsort/sort. The library is in modular Boost format and can be cloned to libs/sort under your local modular boost directory. I have provided as the review manager online documentation at: http://eldiener.github.io/sort Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[sort]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 'eldiener at tropicsoft dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome.

6 11

Help test MSVC 14 CTP compiler
by Andrzej Krzemienski 11 Dec '14

11 Dec '14

Hi Everyone, I am trying to determine the root cause of the failure in one of Boost.Optional regression tests. Namely: http://www.boost.org/development/tests/develop/developer/output/teeks99-08f… Could anyone with the access to MSVC 14 CTP compiler check if the following code compiles? // BEGIN CODE #include <boost/static_assert.hpp> #include <boost/type_traits/is_nothrow_move_assignable.hpp> struct NothrowCtor { NothrowCtor(NothrowCtor&&) BOOST_NOEXCEPT_IF(true) {}; void operator=(NothrowCtor&&) BOOST_NOEXCEPT_IF(false) {}; }; BOOST_STATIC_ASSERT(!::boost::is_nothrow_move_assignable<NothrowCtor>::value); int main() {} // END CODE Regards, &rzej

5 13

Use of boost in safety critical work
by Andrew Marlow 11 Dec '14

11 Dec '14

Hello fellow boosters, I am currently considering a job which involves embedded safety critical. It is for a neonatal ventilator so the safety critical aspect really is critical rather than just 'jolly important'. The company says the development will be in C++ but they have not even heard of boost, let alone use it. They introduced me to a new acronym, well new to me anyway: SOUP. It stands for Software of Unknown Pedigree. They classify boost as SOUP. I have used boost before in embedded work but I have never done safety critical work before so I don't know how widely boost is used there. Can anyone who *has* worked on safety critical stuff comment please? -- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk

16 26

Re: [boost] [asio] Is Boost.Asio ported for Windows Runtime?
by Moshe Rubin 11 Dec '14

11 Dec '14

Hi Rob, The reason I posted an Asio-related question to this forum is because the Asio mailing list is all but dead. In October there were three (3) posts in all, in November zero posts, and this December only one post - mine. Sounds dead to me. Moshe >> On December 9, 2014 3:11:32 AM EST, Moshe Rubin <moshe(a)hyperlync.com> wrote: >> [snip] >>Can the Boost.Asio maintainer, or anyone else, verify if Boost.Asio can >>be built as-is for WinRT, or does it need to be ported? > I added "[asio]" to the subject to help attract the right audience, but you probably want the Asio mailing list for such a question: http://think-async.com/Asio/MailingList.

2 1

Re: [boost] Boost 1.57 hot-out-of-Git fails to compile for Windows Phone
by Moshe Rubin 11 Dec '14

11 Dec '14

Oliver, I forgot to mention that stack_traits.cpp has a typo: it should include: #include <boost/context/stack_context.hpp> rather than #include <boost/econtext/stack_context.hpp> (note the extra 'e') Moshe -------------------- > > I'm currently attempting to port libraries for Windows Phone 8.1 and have not started concentrating on the units tests (of course. Can you please educate me on how to run the boost.context units tests? > > compile the code in directory <boost>/libs/context/test and execute the binaries on WindowsPhone, please (remove untested.cpp in > build/Jamfile.v2) Oliver, I was able to compile and run the context test as a regular Windows app (i.e., not Windows Phone). Here are the results I got: C:\Private\Dev\3rdParty\Boost\boost_1.57-Port-for-WP81\boost\bin.v2\libs\context\test\test_context.test\msvc-12.0\debug\link-static\threading-multi>test_context.exe Running 9 test cases... f1: entered *** No errors detected Detected memory leaks! Dumping objects -> {478} normal block at 0x00530470, 65536 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {477} normal block at 0x00520440, 65536 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {473} normal block at 0x0051E3B0, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {469} normal block at 0x0050E320, 65536 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {465} normal block at 0x0050C290, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {461} normal block at 0x0050A200, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {457} normal block at 0x00508170, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {453} normal block at 0x005060E0, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {449} normal block at 0x005040B0, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {445} normal block at 0x00502080, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD Object dump complete. C:\Private\Dev\3rdParty\Boost\boost_1.57-Port-for-WP81\boost\bin.v2\libs\context\test\test_context.test\msvc-12.0\debug\link-static\threading-multi> It is not clear to me how to compile and run the context test on a Windows Phone. Windows Phone does not run regular executables, so a GUI client app would need to be written. It is not clear to me how to run the test for Windows Phone (I doubt the Boost.Test framework supports a Windows Phone interface). Please advise Moshe

1 0

Re: [boost] Boost 1.57 hot-out-of-Git fails to compile for Windows Phone
by Moshe Rubin 11 Dec '14

11 Dec '14

> > I'm currently attempting to port libraries for Windows Phone 8.1 and have not started concentrating on the units tests (of course. Can you please educate me on how to run the boost.context units tests? > > compile the code in directory <boost>/libs/context/test and execute the binaries on WindowsPhone, please (remove untested.cpp in > build/Jamfile.v2) Oliver, I was able to compile and run the context test as a regular Windows app (i.e., not Windows Phone). Here are the results I got: C:\Private\Dev\3rdParty\Boost\boost_1.57-Port-for-WP81\boost\bin.v2\libs\context\test\test_context.test\msvc-12.0\debug\link-static\threading-multi>test_context.exe Running 9 test cases... f1: entered *** No errors detected Detected memory leaks! Dumping objects -> {478} normal block at 0x00530470, 65536 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {477} normal block at 0x00520440, 65536 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {473} normal block at 0x0051E3B0, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {469} normal block at 0x0050E320, 65536 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {465} normal block at 0x0050C290, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {461} normal block at 0x0050A200, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {457} normal block at 0x00508170, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {453} normal block at 0x005060E0, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {449} normal block at 0x005040B0, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {445} normal block at 0x00502080, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD Object dump complete. C:\Private\Dev\3rdParty\Boost\boost_1.57-Port-for-WP81\boost\bin.v2\libs\context\test\test_context.test\msvc-12.0\debug\link-static\threading-multi> It is not clear to me how to compile and run the context test on a Windows Phone. Windows Phone does not run regular executables, so a GUI client app would need to be written. It is not clear to me how to run the test for Windows Phone (I doubt the Boost.Test framework supports a Windows Phone interface). Please advise Moshe

2 1

Re: [boost] Develop Tests Failing Again
by Tom Kent 11 Dec '14

11 Dec '14

On Mon, Dec 8, 2014 at 1:04 PM, Tom Kent <lists(a)teeks99.com> wrote: > It looks like my windows and linux tests have been failing since last > saturday, around 4pm pacific time. > > The end of results/bjam.log is as follows: > boost-test(RUN) "serialization/test_helper_support_xml_warchive" : > "libs/serialization/test/test_ > helper_support.cpp" > error: at D:/local/teeks99-08/a/boost_bb/src/kernel\modules.jam:107 > error: Unable to find file or target named > error: 'test_interrupts.cpp' > error: referred to from project at > error: '../libs/serialization/test' > > Tom > Apparently it is fixed now. Anyone know what happened, I didn't see any messages about it. Tom

2 1

Re: [boost] [Boost-build] Boost 1.57 hot-out-of-Git fails to compile for Windows Phone
by Jürgen Hunold 10 Dec '14

10 Dec '14

Hi Volodya, Am Freitag, 5. Dezember 2014, 11:19:25 schrieb Vladimir Prus: > On 12/04/2014 09:37 PM, Jürgen Hunold wrote: > > Since sometime last week, Boost.Context depends on Boost.System. > > Unfortunately, Boost.Context has to explicitly calculate the > > <address-model> and <architecture> properties in order to select the > > assembler needed, as those properties have no default value (yet). > > It so happens that Boost.System is once requested without those properties > > and a second time with them. And the <layout> rule is asked to build both > > target with the same effective name in stage/lib. => clash. > > > > So explicitly specifying the properties leads to the right solution. > > > > I cross-mail this to the Boost.Build list to see if someone has a > > solution. > > It would seem I'd have to make architecture and address-model always set, > possibly by lifting current boost.context code for same to the top level? > At least I don't see any other plausible soluton. Me neither. And I think this is not the only configuration code that needs uplifting. We have some duplicated configuration code for ICU and zlib. The main difficulty is the question of sensible default feature values for <address-model> and <architecture>. Especially for Windows with its path length limitations. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

1 0

Review request for Compute
by Antony Polukhin 10 Dec '14

10 Dec '14

Hi, Please add the the Compute library to the review schedule. Compute is a GPU/parallel-computing library for C++ based on OpenCL. Author: Kyle Lutz Source code: https://github.com/kylelutz/compute Documentation: http://kylelutz.github.io/compute/ Review Manager: Antony Polukhin Approximate review date: end of November - December 2014 -- Best regards, Antony Polukhin

2 2

Re: [boost] Boost 1.57 hot-out-of-Git fails to compile for Windows Phone
by Moshe Rubin 10 Dec '14

10 Dec '14

Oliver, I'm currently attempting to port libraries for Windows Phone 8.1 and have not started concentrating on the units tests (of course. Can you please educate me on how to run the boost.context units tests? Moshe > Hello Moshe, > could you tell me if boost.context passes its unit-tests on > Windows-Phone, please? > thx, > Oliver > > 2014-12-09 9:40 GMT+01:00 Moshe Rubin <moshe(a)hyperlync.com<mailto:moshe@hyperlync.com>>: > > A belated "thank you" to Juergen Hunold and Oliver Kowalke for their help in solving the problem. Indeed, when "address-model=32" was added to the command line it solved the problem and enabled me to build all the Windows Phone ARM libraries in one fell swoop. > > > > Thanks very much, > > > > Moshe

2 1

[iterators] Missing typedefs in v1.57
by news.gmane.org 10 Dec '14

10 Dec '14

I posted this a week ago in the user mailing list but it went unnoticed. Perhaps this developers' list is a better place to post it. The typedefs for difference_type and reference used to be in scope for classes derived from iterator_facade. Since v1.57 they have to be declared thus: typedef typename iterator_facade_::difference_type difference_type; typedef typename iterator_facade_::reference reference; This seems out of place for a class that was designed to reduce boiler plate code. However, if the change was intentional, please document it. Thanks, Keith MacDonald

3 5

[documentation] Are SVG's in documentation viable now?
by John Maddock 10 Dec '14

10 Dec '14

Folks I need your opinions, Since it's inception, Boost.Math has used PNG versions of equations and graphs even though scalable SVG versions have been available. Unfortunately, a variety of issues have prevented their use. Fortunately, the logjam now appears to have cleared, and use of SVG's appears viable. So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues? One that I'm aware of, is that the equations reference Window's specific fonts, but so far in my tests this appears not to be an issue. Many thanks, John. PS, I'm aware of MathJax and similar solutions for equations - but these generate so many security warnings on IE when used in local docs (not on a server), that it's a non-starter for now. Besides, we have the SVG's already, and it's a one line change to make use of them ;-)

13 22

Re: [boost] [RPC] Compile-time reflection for RPC and mocking
by Brian Wood 09 Dec '14

09 Dec '14

Peter Bindels writes: > 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 tend to agree with Bjorn's post about messaging middleware. For some reason, thinking in terms of messages is easier for me. For example, rather than serializing the name of the interface and function, I include a message id, which is often one byte. -- Brian Ebenezer Enterprises - So far G-d has helped us. http://webEbenezer.net

2 1

[container] locking for compact map
by Vicente J. Botet Escriba 09 Dec '14

09 Dec '14

Hi, I'm locking for a map<std::size_t, T> implemented as array<optional<T>, N>. When the key is on the range 0..N-1 and the map is dense enough, the advantages are * the whole data is much more compact, avoiding allocations and deallocations, and should reduce the cash misses. * the access insertion/removal/get is direct O(k) instead of O(logN). The liabilities, are the same as array. * iterating is not O(k), but O(N) (When the number of elements is not too high or when there is no too much holes, this should not be a problem) * The move constructor is not noexcept. An implementation using vector<optional<T>> should avoid this last issue. You could ask your self why I don't use directly array<optional<T>> or vector<optional<T>>. The answer is that I don't want the user manage the holes. I'm aware of/flat_(multi)map/set/ associative containers. The difference here is that as the key is the position on the array which make things perform even better for this particular case. Is there something similar in Boost already that I'm missing? Do you see other liabilities I have missed? Best, Vicente

2 4

Boost People section largely outdated
by Joaquin M Lopez Munoz 09 Dec '14

09 Dec '14

Hi, It is a pity that the Boost People section: http://www.boost.org/users/people.html is so outdated: many people there are no longer around, and, more importantly, many (most) current contributors are not listed. This is is a reminder for people to get themselves on that page! Instructions at http://www.boost.org/development/submissions.html#People Best Joaquín M López Muñoz Telefónica

3 2

[asio] introspecting boost::asio::detail::epoll_reactor::run
by Isidor Zeuner 09 Dec '14

09 Dec '14

Hi all, I am investigating a livelock in a running process inside boost::asio::detail::epoll_reactor::run and I was wondering if someone was in this situation before and may have some tools (gdb scripts?) handy which can be used to get a list of currently pending tasks inside the epoll reactor. Thanks in advance! Best regards, Isidor

1 0

Re: [boost] Boost 1.57 hot-out-of-Git fails to compile for Windows Phone
by Moshe Rubin 09 Dec '14

09 Dec '14

A belated "thank you" to Juergen Hunold and Oliver Kowalke for their help in solving the problem. Indeed, when "address-model=32" was added to the command line it solved the problem and enabled me to build all the Windows Phone ARM libraries in one fell swoop. Thanks very much, Moshe

2 1

boost::filesystem changes since version 1.55.0
by Armin Pies 09 Dec '14

09 Dec '14

I have tried to upgrade our software from using boost 1.55.0 to 1.57.0. Now we're getting unexpected exceptions in our code using filesystem::recursive_directory_iterator. Checking http://www.boost.org/users/history/version_1_56_0.html or http://www.boost.org/users/history/version_1_57_0.html there are no changes concerning boost::filesystem. Is there somebody who can tell me what has been changed in boost::filesystem, versions 1.56 and 1.57, and what impact it has on existing code or what I have to adapt to fix our software? Regards, Armin Pies

4 5

Re: [boost] boost::filesystem changes since version 1.55.0
by Armin Pies 09 Dec '14

09 Dec '14

Obviously the operator++ of the recursive_directory_iterator throws exceptions now, which it did not before 1.56. I have changed our code using the increment(system::error_code& ec) method to ignore the unexpected exceptions. Regards, Armin

2 2

Is Boost.Asio ported for Windows Runtime?
by Moshe Rubin 09 Dec '14

09 Dec '14

Boost.Asio is a headers-only library which makes use of Boost's 'system' library. Since the 'system' library has been ported to Windows Runtime (aka WinRT) by Steven Gates of Microsoft, I assumed that Boost.Asio should therefore work as-is for WinRT. When I wrote to Steven asking him to verify that Boost.Asio will work today for WinRT he answered: <quote> "I don't know if Boost.Asio works with the Windows Runtime. I would guess it doesn't entirely, but since it is a header file only library it might work depending on the features used. My recommendation would be to run the Windows App Cert Kit and if you didn't pull in any banned APIs then you might be good. When I look in the history of the Boost.Asio Github repository I can see the maintainer at least started some work for the Windows Runtime. I recommend you reach out to him or post of the Boost mailing forums to see." </quote> Can the Boost.Asio maintainer, or anyone else, verify if Boost.Asio can be built as-is for WinRT, or does it need to be ported? Thanks in advance, Moshe Rubin

2 1

Do we need BoostBook?
by Vladimir Prus 09 Dec '14

09 Dec '14

Hi, I've noticed that Boost.Build documentation, created with BoostBook, explicitly sets a small, and IMO unreadable, font, so I went to fix that, and some other things, as shown at: http://goo.gl/VWYh2P However, after a few easy tweaks, I'm stuck at the fact that BoostBook/DocBook produces fairly old-fashioned HTML. For example, the Boost logo at top is actually a table, and the "tip" block is also a table, which makes tweaking the layout with CSS quite a bit more complex. Also, some of the conceptually trivial things, like putting some front matter in index.html, appear to require XSLT customization. As heretic as it sounds, do we get any benefits from BoostBook? It's a complex vocabulary, with complex toolchain, and while PDF generation sounded nice 10 years ago, printing HTML into PDF is a viable option these days - and nobody would want to print entire Boost documentation anyway? Thoughts? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

12 33

[RFC][Patch][Boost.context] Allowing alternative context switch API
by microcai 09 Dec '14

09 Dec '14

Hi Oliver Kowalke, and others last weak, I report a bug that boost.context causes LoadLibrary to fail. And Oliver Kowalke response that might be because boost.context didn't swap all TIB parts. Allowing alternative context switch API other than reverse-engineered boost.context might solve the problem. So I speed some time to write the patch. users that wish to use Win32 API shoul define BOOST_COROUTINE_USE_FIBER then users should be responsibe to make sure all threads that might call coroutine must be converted to fiber first. since IsThreadAFIber() is not available on some windows platform. if the user can make 100% sure that the platform he/she wish to support has IsThreadAFIber(), then define BOOST_COROUTINE_USE_IS_THREAD_A_FIBER and boost.coroutine will take care of converting to fiber and converting back to thread. Best regards. --- >From 11668b6641c877a4ea154d51ad2171483eced921 Mon Sep 17 00:00:00 2001 From: microcai <microcaicai(a)gmail.com> Date: Sat, 6 Dec 2014 15:50:46 +0800 Subject: [PATCH] allow Win32 Fiber as alternative context switch API windows has some undocumented TIB parts, as boost.context can't keep 100% compatibility with all windows versions, and coroutine is essential to many building blocks. It has to be stable, to allowing alternative context switch API can be more use full. --- .../boost/coroutine/detail/coroutine_context.hpp | 11 ++++ .../coroutine/detail/pull_coroutine_object.hpp | 9 ++++ .../coroutine/detail/push_coroutine_object.hpp | 9 ++++ include/boost/coroutine/stack_allocator.hpp | 5 ++ .../coroutine/windows/null_stack_allocator.hpp | 53 +++++++++++++++++++ src/detail/coroutine_context.cpp | 60 ++++++++++++++++++++-- 6 files changed, 142 insertions(+), 5 deletions(-) create mode 100644 include/boost/coroutine/windows/null_stack_allocator.hpp diff --git a/include/boost/coroutine/detail/coroutine_context.hpp b/include/boost/coroutine/detail/coroutine_context.hpp index 6c4ebb6..f6a53e2 100644 --- a/include/boost/coroutine/detail/coroutine_context.hpp +++ b/include/boost/coroutine/detail/coroutine_context.hpp @@ -16,6 +16,9 @@ #include <boost/coroutine/detail/config.hpp> #include <boost/coroutine/stack_context.hpp> +#ifdef BOOST_COROUTINE_USE_FIBER +# include <windows.h> +#endif #ifdef BOOST_HAS_ABI_HEADERS # include BOOST_ABI_PREFIX #endif @@ -31,6 +34,12 @@ class BOOST_COROUTINES_DECL coroutine_context private: stack_context stack_ctx_; context::fcontext_t ctx_; +#ifdef BOOST_COROUTINE_USE_FIBER + void (*fn_)(intptr_t); + intptr_t param_; + LPVOID fiber_; + static VOID WINAPI fb_start_proc(LPVOID lpFiberParameter); +#endif // BOOST_COROUTINE_USE_FIBER public: typedef void( * ctx_fn)( intptr_t); @@ -51,6 +60,8 @@ public: stack_context & stack_ctx() { return stack_ctx_; } + + void destory(); }; }}} diff --git a/include/boost/coroutine/detail/pull_coroutine_object.hpp b/include/boost/coroutine/detail/pull_coroutine_object.hpp index cfe34bd..d15d94f 100644 --- a/include/boost/coroutine/detail/pull_coroutine_object.hpp +++ b/include/boost/coroutine/detail/pull_coroutine_object.hpp @@ -65,6 +65,9 @@ private: stack_context stack_ctx( obj->stack_ctx_); StackAllocator stack_alloc( obj->stack_alloc_); obj->unwind_stack(); +#ifdef BOOST_COROUTINE_USE_FIBER + obj->callee.destory(); +#endif obj->~obj_t(); stack_alloc.deallocate( stack_ctx); } @@ -153,6 +156,9 @@ private: stack_context stack_ctx( obj->stack_ctx_); StackAllocator stack_alloc( obj->stack_alloc_); obj->unwind_stack(); +#ifdef BOOST_COROUTINE_USE_FIBER + obj->callee.destory(); +#endif obj->~obj_t(); stack_alloc.deallocate( stack_ctx); } @@ -241,6 +247,9 @@ private: stack_context stack_ctx( obj->stack_ctx_); StackAllocator stack_alloc( obj->stack_alloc_); obj->unwind_stack(); +#ifdef BOOST_COROUTINE_USE_FIBER + obj->callee.destory(); +#endif obj->~obj_t(); stack_alloc.deallocate( stack_ctx); } diff --git a/include/boost/coroutine/detail/push_coroutine_object.hpp b/include/boost/coroutine/detail/push_coroutine_object.hpp index 1a39c07..b41a3b2 100644 --- a/include/boost/coroutine/detail/push_coroutine_object.hpp +++ b/include/boost/coroutine/detail/push_coroutine_object.hpp @@ -77,6 +77,9 @@ private: stack_context stack_ctx( obj->stack_ctx_); StackAllocator stack_alloc( obj->stack_alloc_); obj->unwind_stack(); +#ifdef BOOST_COROUTINE_USE_FIBER + obj->callee.destory(); +#endif obj->~obj_t(); stack_alloc.deallocate( stack_ctx); } @@ -165,6 +168,9 @@ private: stack_context stack_ctx( obj->stack_ctx_); StackAllocator stack_alloc( obj->stack_alloc_); obj->unwind_stack(); +#ifdef BOOST_COROUTINE_USE_FIBER + obj->callee.destory(); +#endif obj->~obj_t(); stack_alloc.deallocate( stack_ctx); } @@ -253,6 +259,9 @@ private: stack_context stack_ctx( obj->stack_ctx_); StackAllocator stack_alloc( obj->stack_alloc_); obj->unwind_stack(); +#ifdef BOOST_COROUTINE_USE_FIBER + obj->callee.destory(); +#endif obj->~obj_t(); stack_alloc.deallocate( stack_ctx); } diff --git a/include/boost/coroutine/stack_allocator.hpp b/include/boost/coroutine/stack_allocator.hpp index 662533e..811f352 100644 --- a/include/boost/coroutine/stack_allocator.hpp +++ b/include/boost/coroutine/stack_allocator.hpp @@ -14,6 +14,9 @@ #include <boost/context/detail/config.hpp> #include <boost/coroutine/segmented_stack_allocator.hpp> #include <boost/coroutine/standard_stack_allocator.hpp> +#if defined(BOOST_WINDOWS) +# include <boost/coroutine/windows/null_stack_allocator.hpp> +#endif #ifdef BOOST_HAS_ABI_HEADERS # include BOOST_ABI_PREFIX @@ -24,6 +27,8 @@ namespace coroutines { #if defined(BOOST_USE_SEGMENTED_STACKS) typedef segmented_stack_allocator stack_allocator; +#elif defined(BOOST_COROUTINE_USE_FIBER) +typedef null_stack_allocator stack_allocator; #else typedef standard_stack_allocator stack_allocator; #endif diff --git a/include/boost/coroutine/windows/null_stack_allocator.hpp b/include/boost/coroutine/windows/null_stack_allocator.hpp new file mode 100644 index 0000000..25f9b34 --- /dev/null +++ b/include/boost/coroutine/windows/null_stack_allocator.hpp @@ -0,0 +1,53 @@ + +// Copyright Oliver Kowalke 2009. +// Distributed under the Boost Software License, Version 1.0. +// (See accompanying file LICENSE_1_0.txt or copy at +// http://www.boost.org/LICENSE_1_0.txt) + +#ifndef BOOST_COROUTINES_NULL_STACK_ALLOCATOR_H +#define BOOST_COROUTINES_NULL_STACK_ALLOCATOR_H + +extern "C" { +#include <windows.h> +} + +#include <cmath> +#include <cstddef> +#include <new> + +#include <boost/config.hpp> + +#include <boost/coroutine/detail/config.hpp> +#include <boost/coroutine/stack_traits.hpp> + +#ifdef BOOST_HAS_ABI_HEADERS +# include BOOST_ABI_PREFIX +#endif + +namespace boost { +namespace coroutines { + +struct stack_context; + +template< typename traitsT > +struct basic_null_stack_allocator +{ + typedef traitsT traits_type; + + void allocate(stack_context & ctx, std::size_t size) + {} + + void deallocate(stack_context & ctx) + {} +}; + +typedef basic_null_stack_allocator< stack_traits > null_stack_allocator; + +} +} + +#ifdef BOOST_HAS_ABI_HEADERS +# include BOOST_ABI_SUFFIX +#endif + +#endif // BOOST_COROUTINES_NULL_STACK_ALLOCATOR_H diff --git a/src/detail/coroutine_context.cpp b/src/detail/coroutine_context.cpp index f63479e..e021281 100644 --- a/src/detail/coroutine_context.cpp +++ b/src/detail/coroutine_context.cpp @@ -28,6 +28,14 @@ void __splitstack_setcontext( void * [BOOST_COROUTINES_SEGMENTS]); namespace boost { namespace coroutines { namespace detail { +#ifdef BOOST_COROUTINE_USE_FIBER +VOID WINAPI coroutine_context::fb_start_proc(LPVOID lpFiberParameter) +{ + coroutine_context * ctx = (coroutine_context*)lpFiberParameter; + ctx->fn_(ctx->param_); + DeleteFiber(ctx->fiber_); +} +#endif coroutine_context::coroutine_context() : stack_ctx_(), @@ -35,18 +43,35 @@ coroutine_context::coroutine_context() : { #if defined(BOOST_USE_SEGMENTED_STACKS) __splitstack_getcontext( stack_ctx_.segments_ctx); +#elif defined(BOOST_COROUTINE_USE_FIBER) + fiber_ = NULL; + param_ = 0; + fn_ = 0; #endif } coroutine_context::coroutine_context( ctx_fn fn, stack_context const& stack_ctx) : - stack_ctx_( stack_ctx), - ctx_( context::make_fcontext( stack_ctx_.sp, stack_ctx_.size, fn) ) -{} + stack_ctx_( stack_ctx) +#ifndef BOOST_COROUTINE_USE_FIBER + , ctx_(context::make_fcontext( stack_ctx_.sp, stack_ctx_.size, fn) ) +#endif // !BOOST_COROUTINE_USE_FIBER +{ +#ifdef BOOST_COROUTINE_USE_FIBER + fn_ = fn; + fiber_ = CreateFiber(0, fb_start_proc, this); +#endif // BOOST_COROUTINE_USE_FIBER +} coroutine_context::coroutine_context( coroutine_context const& other) : stack_ctx_( other.stack_ctx_), ctx_( other.ctx_) -{} +{ +#ifdef BOOST_COROUTINE_USE_FIBER + real_fn = other.real_fn; + fiber_ = other.fiber_; + param_ = other.param_; +#endif // BOOST_COROUTINE_USE_FIBER +} coroutine_context & coroutine_context::operator=( coroutine_context const& other) @@ -55,7 +80,11 @@ coroutine_context::operator=( coroutine_context const& other) stack_ctx_ = other.stack_ctx_; ctx_ = other.ctx_; - +#ifdef BOOST_COROUTINE_USE_FIBER + real_fn = other.real_fn; + fiber_ = other.fiber_; + param_ = other.param_; +#endif // BOOST_COROUTINE_USE_FIBER return * this; } @@ -71,11 +100,32 @@ coroutine_context::jump( coroutine_context & other, intptr_t param, bool preserv __splitstack_setcontext( stack_ctx_.segments_ctx); return ret; +#elif BOOST_COROUTINE_USE_FIBER + other.param_ = param; +#ifdef BOOST_COROUTINE_USE_IS_THREAD_A_FIBER + if (!IsThreadAFiber()) + { + this->fiber_ = ConvertThreadToFiber(this); + SwitchToFiber(other.fiber_); + ConvertFiberToThread(); + this->fiber_ = NULL; + } + else +#endif // BOOST_COROUTINE_USE_IS_THREAD_A_FIBER + SwitchToFiber(other.fiber_); + return this->param_; #else return context::jump_fcontext( & ctx_, other.ctx_, param, preserve_fpu); #endif } +void coroutine_context::destory() +{ +#ifdef BOOST_COROUTINE_USE_FIBER + DeleteFiber(fiber_); +#endif +} + }}} #if defined(_MSC_VER) -- 2.2.0

1 1

What is the e-mail of the Boost webmaster ?
by Edward Diener 08 Dec '14

08 Dec '14

What is the e-mail of the Boost webmaster, as in "If you want to do some XXX on the Boost website, contact the Boost webmaster" ? The term "Boost webmaster" is used on the development portion of the website with no clue who that might be.

1 0

[serialization] Fwd: [Boost-testing] Develop Tests Failing Again
by Rene Rivera 08 Dec '14

08 Dec '14

---------- Forwarded message ---------- From: Tom Kent <teeks99(a)yahoo.com> Date: Mon, Dec 8, 2014 at 2:09 PM Subject: [Boost-testing] Develop Tests Failing Again To: Running Boost regression tests <boost-testing(a)lists.boost.org> It looks like my windows and linux tests have been failing since last saturday, around 4pm pacific time. The end of results/bjam.log is as follows: boost-test(RUN) "serialization/test_helper_ support_xml_warchive" : "libs/serialization/test/test_helper_support.cpp" error: at D:/local/teeks99-08/a/boost_bb/src/kernel\modules.jam:107 error: Unable to find file or target named error: 'test_interrupts.cpp' error: referred to from project at error: '../libs/serialization/test' Tom _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[graph] Lowest common ancestor (LCA), etc.
by Jeremy Murphy 08 Dec '14

08 Dec '14

Hi, I'm working on some graph algorithms that I thought might be useful additions to Boost.Graph, such as the classic LCA and more recent lowest single common ancestor (LSCA) [1]. Is there interest in having these added? I saw there was some discussion of LCA between Cromwell Enage and others back in 2004 but I'm unaware of the outcome (in terms of proposed code, etc). Cheers. Jeremy [1] https://github.com/jeremy-murphy/graph-algorithms

1 0

How to contact test runner "trippels_gcc-5.0_c++11"
by Antony Polukhin 08 Dec '14

08 Dec '14

Hi, There's a GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64218 that would possibly require some comments from test runner. Somebody knows how to contact test runner trippels_gcc-5.0? -- Best regards, Antony Polukhin

1 0

[mpl] [build] [testing] Merge pull requests
by Andrey Semashev 08 Dec '14

08 Dec '14

Hi, There were a lot of discussions about MPL recently, and I created a few pull requests to address issues: https://github.com/boostorg/boost/pull/39 Invoke 'headers' target before building testing tools. Note that several testers are currently failing to run because of this problem. Since this affects the testing process, I'd appreciate if someone familiar with it could take a look. https://github.com/boostorg/boost/pull/38 Add MPL.Core tests to the test report. These tests are currently not run by testers. https://github.com/boostorg/mpl/pull/12 Move a misplaced header from MPL to MPL.Core to resolve circular dependency between the two. I believe the first PR is especially critical. Could someone with permissions merge these? Thanks.

13 52

[quickbook] Where to put my pictures?
by Andrzej Krzemienski 05 Dec '14

05 Dec '14

Hi Everyone, How do I put images into QuickBook documentation? The manual says I should put: [$images/img.png] But in which location am I supposed to put the picture? Currently my documentation works if I put folder "images" with my PNG image inside folder "html". But the latter folder ("html") is generated by b2: it would not be there if I haven't run b2. Assuming I only want to keep QBK sources, but no generated files, where do I put my images, so that b2 works? Regards, &rzej

1 0

Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
by Felix Uhl 05 Dec '14

05 Dec '14

David Stone wrote: >I have been bitten in the past by operator<. I was converting code that >used unsigned with a 'magic value' to represent nullness to >boost::optional<std::uint32_t>. However, the maximum value it used was >std::numeric_limits<std::uint32_t>:max(). A simple find and replace for >this magic constant (which was referred to everywhere as DWORD_NULL) with >boost::none and fixing compile errors led to some erroneous code. We had >code that assumed an 'uninitialized' std::uint32_t was greater than any >valid value. >The concept of "value not present" is not inherently less-than or >greater-than any value, but because of operator<, code compiled that >shouldn't have. I suppose this is really an argument against any operator< >overload, not just the mixed-type comparison. I don't expect this to be a >major problem for new code, but there is a lot of code out there that uses >a magic value, and that is what optional is supposed to replace. I was irritated by it at first, too, and if you think about it the comparison brakes down to a philosophical problem: If I have a pair of pants and you don’t, are my pants smaller than yours? Hard to say, but to me the most logical solution is “no”. My pants aren’t smaller than yours, and my pants aren’t larger than yours. Also, your and my logic would apply to both the operator<(optional<T>, T) and operator<(optional<T>, optional<T>), but I think we’re only talking about the latter. --- Felix Uhl

14 67