- Boost-announce - lists.preview.boost.org

[boost][review] Review of Outcome (ends Sun-28-May)
by charleyb123 . 25 May '17

25 May '17

Hi, Everyone, First a (very-)big "thank-you!" to all participating in the ongoing (and vigorous) debate and review for the Outcome library. The spirited discussion touches on tricky issues for composition and error handling (with and without C++ exceptions enabled), where the community is clearly searching for best convention and common ground. Thus far: (a)- some 300+ emails discussing Outcome (and more emails off-list) (b)- participation from: *- Andrzej Krzemienski *- D25fe0be *- Deniz Bahadir *- Emil Dotchevski *- Gavin Lambert *- Glen Fernandes *- Gottlob Frege (Tony) *- Hartmut Kaiser *- Ion Gaztanaga *- Jonathan Muller *- Niall Douglas *- Paul Bristow *- Pete Bartlett *- Peter Dimov *- Robert Ramey *- Thomas Heller *- Vicente J. Botet Escriba *- Vinnie Falco *- ...(apologies if I've missed anyone) (c)- Some points-of-discussion relate to: *- Outcome efficiency (copy/move) on today’s compilers *- Outcome speed/overhead (exceptions) *- Outcome purpose/motivation *- Outcome Tutorials, documentation *- Outcome “formal-empty-state”, default-initialization *- Outcome compiling, compiler support *- Outcome ABI, namespace usage, use of preprocessor *- Outcome alternative APIs *- std::expected proposal, possible changes (d)- Reviews to date (sent publicly to the list): *- Paul Bristow -- accept, conditional (Tue-23-May) *- Deniz Bahadir -- accept, unconditional (Wed-24-May) *- Thomas Heller -- (almost a review), ?reject, "not-ready-yet?" (Wed-24-May) (e)- Significant other discussion also contributes to evaluation of Outcome as a Boost library. However, I encourage further reviews to make clear any conclusions from these discussions that I might have missed. The review continues for several more days, ending Sun-28-May. Please consider posting a review to the boost mailing list, or privately to the Review Manager (to me). Here are some questions you might want to answer in your review: - 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 most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley

1 0

[review] PolyCollection formal review results: ACCEPTED into Boost
by Ion Gaztañaga 22 May '17

22 May '17

Hi, Thank you for your participation in the PolyCollection review. I'll try to collect all votes and summarize the agreed changes on the library. ----- Votes ----- I count 8 (all positive) reviews and votes from Pete Bartlett Andrzej Krzemienski Hans Dembinski Thorsten Ottosen Vinnie Falco Edward Diener Brook Milligan Steven Watanabe -------- Comments -------- Additionally the following boosters did some positive comments on the library and made some questions Dominique Devienne Adam Wulkiewicz Myself No comment was blocking for the acceptance of the library so Boost.PolyCollection is accepted into Boost, congratulations to Joaquín! I recommend committing the library to the boostorg repo as soon as possible in order to start regressions and try to include the new library in Boost 1.65. Many of the proposed changes are one-liners in the documentation and code and hopefully will be ready for Boost 1.65. Deeper changes can wait until Boost 1.66. --------------------------------------- Summary of agreed comments and changes: --------------------------------------- ------------------ Dominique Devienne (positive comment) https://lists.boost.org/Archives/boost/2017/05/234672.php ------------------ "I suspect the new poly_collection could be used for more efficient parallel (and/or concurrent) processing of elements, and would be interested in examples and even a ::parallel_for_each() algorithm that leverages the collection's internal storage" Joaquín will try to play with this idea to see how it fares performancewise. ------------------ Pete Bartlett (positive review) https://lists.boost.org/Archives/boost/2017/05/234669.php ------------------ "It may be worth remarking in the docs what facilities are used for the type registries that are presumably behind the scenes. From the reference section I think RTTI is required. Is this a hard limit or could Boost.TypeIndex be used?" Additional comment from the review manager: Consider making RTTI customizable. Boost.TypeInfo should be easily usable. In any case document the use of RTTI in the documentation. Joaquín will consider the customizable RTTI, will document that RTTI is required by the library. ------------------ Andrzej Krzemienski (positive review) https://lists.boost.org/Archives/boost/2017/05/234716.php ------------------ [1] "Based on my experience OO-inheritance solutions are faster that using `variant`. As you say below, I was suggesting the alternative design: `variant_collection`." Joaquín: "Some have asked for a variant_collection to be part of Boost.PolyCollection roadmap." [2] "I am not comfortable with per-segment functions having the same name as container-wide functions" Joaquín: "On the contrary, I like name overloading better, because it looks terser yet sufficiently expressive" [3] "I observed that the following small program crashes (assertion fails). According to the documentation this should throw an exception upon insertion rather than firing assertions" Joaquín: I think the assertion will be removed. [4] Commenting c.insert(x) / c.insert(it,x) reference: "And maybe it is just me, but I cannot make the sense of it" Joaquín: There is a typo that will be fixed. Will reword the reference sections into a more digestible form. ------------------ Ion Gaztañaga (positive comment) https://lists.boost.org/Archives/boost/2017/05/234729.php https://lists.boost.org/Archives/boost/2017/05/234745.php ------------------ [1] Model-based polymorphism: "Wouldn't be a good idea to make this model-based polymorphism (or a refined one) public? Maybe the current model needs more work to support additional polymorphism models." Joaquín: I'd be really conservative here and withhold such a big move until real use cases are found. The problem is once this is made public the design of the lib becomes effectively frozen. Will study it for the future if there's demand. [2] Optimize memory-indirection caused by unique_ptr: "segment_type could directly hold the class derived from segment_backend as packed_segment/split_segment will need the same size and alignment requirements regardless of the ConcreteType they hold (as long as they use std::vector). This could improve insertion times and other operations. This optimization could also make easier to fix the following section (allocator propagation)." Joaquín: In principle if the optimization is reasonably implemented t'd be welcome. [3] Allocator propagation: The library does not correctly propagate the allocator to support the scoped allocator model. Joaquín will fix this. [4] In many operations the dynamic type of the object to be inserted or manipulated can be known at compile, so the internal virtual call overhead can be optimized. Specially in "insert" and "emplace", but many other operations that work with a single segment can be optimized as well. Joaquín will review operations and will try to "staticfy" as much as possible. [5] Documentation should reflect some operations, like size<T>(), empty<T>() and others are not constant-time cheap operations. Thorsten suggested: The documentation should defin k = # of segments in container and add in those operations "Complexity: linear in k" as the explanation. Joaquín will document it. --------------- Adam Wulkiewicz (comment, but positive) https://lists.boost.org/Archives/boost/2017/05/234662.php --------------- [1] Polycollection doesn't meet the requirements of C++ container as defined in the standard, specially section (23.2.1.3). Joaquín: The part about 23.2.1.3 is not listed among the differences, will include it. --------------- Hans Dembinski (positive review) https://lists.boost.org/Archives/boost/2017/05/234694.php --------------- [1] "boost::function_collection was not so clear to me. It is nice to keep the narrative of game development going, but like someone said before, I think it would help to give a simpler example" Joaquín will improve the explanation [2] "I felt that the benefit of using boost::function_collection was not so clearly presented as for boost::base_collection. The function pointers are all the same size, so how exactly does the optimisation enter" Joaquín will improve the explanation. [3] "I tried to compile the tests on a Mac with Apple-clang 8.0.0. It worked after I manually specified "cxxflags=-std=c++11" Note from the review manager: No fix was discovered, I suggest working on this as many Apple users will have this problem. --------------- Thorsten Ottosen (positive review) https://lists.boost.org/Archives/boost/2017/05/234697.php --------------- [1] "OO programming and copyability of classes is not something that everybody is going to like. (...) Would it be possible for the library to pick up a private or protected copy-constructor when needed, possible via a friend declaration? (...) being able to have your hierarchy non-copyable while allowing copyability within the container is important IMO." Moveability is already required to store classes in the segment. Joaquín will study the possibility of using a copying traits class to let users customize this point. [2] "I miss range versions of the various iteration patterns so I can use them directly with a range-based for. E.g. instead of" Joaquín will implement it. [3] "Inside the segments you store std::vector. I could easily imagine the need to store something else, (...) Therefore I would love to have a second defaulted argument set to std::vector" Element contiguity is a key property and this customization requires a lot of work. Deferred for the future if there is demand for it. [4] "Implementation of equality: do we need to be set like semantics (two-pass)? Why don't you just delegate to the segments after checking the size?" Joaquín proposed a new slightly better implementation. [5] "tutorial: consider using override where appropriate" Joaquín will review code to use it. [6] "why ==,!= but not <,>,>=, <=" Joaquín followed the interface of std::unordered_set, [Review manager's comment: Consider explaining this in the documentation] [7] "Clarify that boost::poly_collection::for_each <warrior,juggernaut,goblin,std::string,window>( //restituted types c.begin(),c.end(),[&](const auto& x) loops over all elements or only the specific" Joaquín will clarify it. [8] "It could be good to have a performance test of erase in the middle/front." Joaquín will test it. [9] "using the identifier "concept" may require change in the near future?"s Joaquín will change it. [10] "I wouldn't mind seeing separate graphs for 0-300 elements." Joaquín will add it. [11] 2clarify test are without use of reserve" Joaquín will clarify it. [12] The test are testing best possible scenario; a more realistic test would be to copy pointers to an std::vector<base*>, shuffle it and run update on that. Joaquín will consider this, maybe additionally for 1-1000 elements. --------------- Vinnie Falco (Positive review) https://lists.boost.org/Archives/boost/2017/05/234704.php --------------- [1] "Iterators returned by begin<T>() produce a long, ugly compile error when compared against iterators returned by begin<U>() or end<U>()." Joaquín will study the issue. He's not sure if this can be improved. --------------- Edward Diener (positive review) https://lists.boost.org/Archives/boost/2017/05/234762.php --------------- [1] "It is also hard to understand what the advantage of a poly collection of these objects entail over a more normal C++ collection ( vector, array etc. ) of std::function<Signature> objects, since the latter object type already represents a generalized callable construct in C++." Joaquín will think about how to make the intro part more accessible. [2] "I have mentioned previously that I think the documentation should be more specific about the types being used for the boost::function_collection" Joaquín will take these points, and try to improve docs so as to make these aspects clearer. --------------- Brook Milligan (positive review) https://lists.boost.org/Archives/boost/2017/05/234872.php --------------- [1] "The only problem was that the following test cases needed -std=c++14 (rather than c++11) because std::make_unique is not defined for c++11 on that compiler: algorithms, basic_function, and segmented_structure. Perhaps a mention of the need for c++14 in some examples?" Joaquín will fix in the corresponding Jamfile.v2 and will mention it in the examples. --------------- Steven Watanabe (positive review) https://lists.boost.org/Archives/boost/2017/05/234877.php --------------- [1] Several documentation fixes Joaquín will apply recommended fixes [2] Change type_erasure::is_subconcept<type_erasure::assignable<>,Concept2>::value as Boost.TypeErasure was recently extended to support move assignment. [3] Fix "type_erasure::is_subconcept<type_erasure::typeid_<>,Concept>::value " with "typeid_<remove_cv_t<remove_reference_t<T>>> " [4] Fix "static void* subaddress(T& x){return boost::addressof(x);}" as it does not support multiple inheritance [5] Fix "return r(std::forward<Args>(args)...);" that does not correctly handle "void" return types. Joaquín will fix all of them [6] "make_index_sequence<N>" can be implemented more efficiently: Joaquín will find a better implementation. Review manager's comment: see https://stackoverflow.com/questions/17424477/implementation-c14-make-intege… [7] poly_collection is defined in namespace detail, internal functions can be found by ADL Joaquín will try to limit what ADL can find.

1 0

[boost][review] Review of Outcome (starts Fri-19-May)
by charleyb123 . 19 May '17

19 May '17

Hi Everyone, The formal review of Niall Douglas' Outcome library starts today (Fri-19-May) and continues until Sun-28-May. Your participation is encouraged, as the proposed library is uncoupled and focused, and reviewers don't need to be domain experts to appreciate the potential usefulness of the library and to propose improvements. Everyone needs (and has suffered) error handling, and can compose an opinion on that topic. Outcome is a header-only C++14 library providing expressive and type-safe ultra-lightweight error handling, suitable for low-latency code bases. Key features: *- Makes using std::error_code from C++11's <system_error> more convenient and safe *- Provides high-quality implementation of proposed std::expected<T,E> (on C++20 standards track) *- Good focus on low-latency (with tests and benchmarks) *- Error-handling algorithmic composition with-or-without C++ exceptions enabled *- No dependencies (not even on Boost) This review is timely, as C++17 brings us std::optional<T>. The upcoming std::expected<T,E> (an implementation provided in Outcome) is a generalization of std::optional<T> that provides a <success|fail> value, where the unhappy result is a 'std::error_code' or an instance of "your-chosen-error-type". The library further provides 'outcome<T,error-code,exception-ptr>' for handling <success|error|exception> to safely wrap throwing APIs. Documentation: https://ned14.github.io/boost.outcome/index.html ACCU 2017 talk including design rationale: https://www.youtube.com/watch?v=XVofgKH-uu4 GitHub: https://github.com/ned14/boost.outcome Latest tarball: https://github.com/ned14/boost.outcome/releases/download/ boost_peer_review3/boost.outcome-v1.0-source-201705111650.tar.xz Note: Tarball might be easiest; but if you want to clone from GitHub directly, after the clone you should run the following command to get the source zip exactly: git submodule update --init --recursive Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - 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 most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley

1 0

[boost][review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
by charleyb123 . 11 May '17

11 May '17

Hi Everyone, ** HEADS UP, NEXT WEEK ** The formal review of Niall Douglas' Outcome library starts next week (Fri-19-May to Sun-28-May). Your participation is encouraged, as the proposed library is uncoupled and focused, and reviewers don't need to be domain experts to appreciate the potential usefulness of the library and to propose improvements. Everyone needs (and has suffered) error handling, and can compose an opinion on that topic. Outcome is a header-only C++14 library providing expressive and type-safe ultra-lightweight error handling, suitable for low-latency code bases. Key features: *- Makes using std::error_code from C++11's <system_error> more convenient and safe *- Provides high-quality implementation of proposed std::expected<T,E> (on C++20 standards track) *- Good focus on low-latency (with tests and benchmarks) *- Error-handling algorithmic composition with-or-without C++ exceptions enabled *- No dependencies (not even on Boost) This review is timely, as C++17 brings us std::optional<T>. The upcoming std::expected<T,E> (an implementation provided in Outcome) is a generalization of std::optional<T> that provides a <success|fail> value, where the unhappy result is a 'std::error_code' or an instance of "your-chosen-error-type". The library further provides 'outcome<T,error-code,exception-ptr>' for handling <success|error|exception> to safely wrap throwing APIs. Documentation: https://ned14.github.io/boost.outcome/index.html ACCU 2017 talk including design rationale: https://www.youtube.com/watch?v=XVofgKH-uu4 GitHub: https://github.com/ned14/boost.outcome Latest tarball: https://github.com/ned14/boost.outcome/releases/ download/boost_peer_review3/boost.outcome-v1.0-source-201705111650.tar.xz Note: Tarball might be easiest; but if you want to clone from GitHub directly, after the clone you should run the following command to get the source zip exactly: git submodule update --init --recursive NEXT WEEK (when the public review is started): Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - 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 most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley

1 0

[review] Review of PolyCollection starts today (May 3rd)
by Ion Gaztañaga 02 May '17

02 May '17

Hi everyone, The formal review of Joaquín M. López Muñoz's PolyCollection library starts today. I'd like to encourage your participation as the proposed library is small and focused, and reviewers don't need to be domain experts to appreciate the potential usefulness of the library and propose improvements. PolyCollection implements fast containers of polymorphic objects. Typically, polymorphic objects cannot be stored directly in regular containers and need be accessed through an indirection pointer, which introduces performance problems related to CPU caching and branch prediction. Boost.PolyCollection implements a novel data structure that is able to contiguously store polymorphic objects without such indirection, thus providing a value-semantics user interface and better performance. Three polymorphic collections are provided: * boost::base_collection * boost::function_collection * boost::any_collection dealing respectively with classic base/derived or OOP polymorphism, function wrapping in the spirit of std::function and so-called duck typing as implemented by Boost.TypeErasure. The library can be found here: Incubator: http://blincubator.com/bi_library/polycollection/?gform_post_id=1643 Github: https://github.com/joaquintides/poly_collection and the documentation here: http://rawgit.com/joaquintides/poly_collection/website/doc/html/index.html Please post your comments and review to the boost mailing list (preferably), the Boost Library Incubator. or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - 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 most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Waiting your reviews! Ion

1 0

[boost] [review] Review of PolyCollection will start in a few days
by Ion Gaztañaga via Boost 30 Apr '17

30 Apr '17

Dear Boost community, The formal review of Joaquín M López Muñoz's PolyCollection library will start on Wednesday, May 3rd and ends on May 12th. This library implements fast containers of polymorphic objects. Typically, polymorphic objects cannot be stored directly in regular containers and need be accessed through an indirection pointer, which introduces performance problems related to CPU caching and branch prediction. Boost.PolyCollection implements a novel data structure that is able to contiguously store polymorphic objects without such indirection, thus providing a value-semantics user interface and better performance. Three polymorphic collections are provided: * boost::base_collection * boost::function_collection * boost::any_collection dealing respectively with classic base/derived or OOP polymorphism, function wrapping in the spirit of std::function and so-called duck typing as implemented by Boost.TypeErasure. If you are interested, you can start preparing your review with the following information: Repositories: Incubator: http://blincubator.com/bi_library/polycollection/?gform_post_id=1643 Github: https://github.com/joaquintides/poly_collection and the documentation here: http://rawgit.com/joaquintides/poly_collection/website/doc/html/index.html See you on Wednesday! Ion _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[release] Boost 1.64.0
by Rene Rivera 20 Apr '17

20 Apr '17

Release 1.64.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains one new library and numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/history/version_1_64_0.html> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.64.0/> To install this release on your system, see < http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Vladimir Prus, Rene Rivera, Marshall Clow, Eric Niebler, Daniel James, Beman Dawes

2 1

[gsoc17] Help review Google Summer of Code proposals
by Niall Douglas 05 Apr '17

05 Apr '17

Dear Boost, Student proposals for Google Summer of Code are submitted, please help us decide which have the most merit. I have reduced the fifty something proposals submitted down to twenty seven which have some chance. To be able to view and rank the student proposals, please do the following: 1. Send to gsoc-admin(a)boost.org your Google login. We will invite you to view the student proposals on the Boost Google Drive. Until you receive the invitation email, you won't be able to view the proposals. 2. Go to https://goo.gl/forms/EVppdHsHMnjkcUoD3 which is a Google form where you can score the proposals. We have linked each proposal there to the Google Drive item and there you can rank a proposal between 1 and 5. Make sure you use the same email as your Google login in the form, otherwise we will ignore any forms submitted to prevent gaming the results. 3. Even if you can't rank all twenty seven proposals, try to do as many as you can and then PRESS SUBMIT at the end of the form (forgetting to press SUBMIT means we never get your rankings). The proposals are presented in random order per person so any work you do will be useful. 4. Please try to have your rankings done by Monday 10th. You may find reviewing the page at https://svn.boost.org/trac/boost/wiki/SoC2017 useful. 5. Finally, if you'd like to mentor any of the proposals, send to gsoc-admin(a)boost.org your Google login so we may invite you onto the Google website as a mentor. Many thanks in advance. Niall & Bryce

1 0

[release] Boost 1.64.0 Beta 2
by Rene Rivera 30 Mar '17

30 Mar '17

Boost release 1.64.0 beta 2 is now available at: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.2/source/> The SHA256 checksums are as follows: 49c9339b9d8e7b2610ef84c80cd10b2252c119ebcc3222450beb0e94c1da1522 boost_1_64_0_b2.7z 92ec7cbf1e77c5979e381dd8104f9e96c0471c276e566272751a981d806db94b boost_1_64_0_b2.tar.bz2 da5670892b7b572808491b13a7b9421c3c18e6f395d6a5ec822466db466eda01 boost_1_64_0_b2.tar.gz 61d6e29e8a1d7503fe13a9d916842f0ec2e625f733b98b29ce563f8cbdb482bf boost_1_64_0_b2.zip The notable difference from Beta 1 is the inclusion of the missing Boost Process library. For details of what's in the release, see < http://www.boost.org/users/history/version_1_64_0.html>. Note that the links to files on this web page are for the final release - use the link above to get the beta files. There are also pre-built libraries provided by Tom Kent here: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.2/binaries/> Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team -- -- 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

[Stacktrace] Review 2 Manager report
by Niall Douglas 30 Mar '17

30 Mar '17

Many thanks to all those who participated in the second review of proposed Boost.Stacktrace. I received the following formal reviews: 1. Peter Dimov (ACCEPT) 2. Vladimir Batov (ACCEPT) 3. Artyom Bellis (CONDITIONAL ACCEPT) 4. Bjorn Reese (ACCEPT) 5. Edward Diener (ACCEPT) Extensive comments without a formal recommendation were also made by: 1. Mark Bartosik 2. Florian Weimer Some of the more important conditions for acceptance as judged by the review manager are: * Problems on FreeBSD (and by inference OS X?). * Per frame execution of addr2line rather than calling it once. * Throw-with-trace was asked for by a lot of people. * One reviewer suggested that the addr2line backend was async signal unsafe. My reading of the code is that it is async signal unsafe to parse a stacktrace (and unavoidably so on any platform), but the capture of backtraces is now fully async signal safe. * Some disliked the bringing in of windows.h and the COM headers on Windows. For a header only library I consider this acceptable, Stacktrace when configured in non-header only mode does not inject windows.h into everything including stacktrace. Congratulations to Antony on getting yet another library of his into Boost! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0