- Boost - lists.preview.boost.org

[hana] Review
by edouard＠fausse.info 16 Jun '15

16 Jun '15

Dear all, Please find attached my review of Hana. > - Whether you believe the library should be accepted into Boost > * Conditions for acceptance Definitely yes. I just have a very minor remark considering the documentation. > - Your name Edouard Alligand > - Your knowledge of the problem domain. I have been writing C++ professionally for 15 years and done a lot of TMP for many software project, for things such as compile-time introspection for serialization, enhanced checks at compile-time to improve correctness and compile-time pre-computations. I've done that with Boost.MPL, Boost.Fusion and some custom MPL. > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design I am very much impressed by the design of Hana and the cleverness of the usage of C++ 14 lambdas. > * Implementation As far as I can judge it is very well implemented. > * Documentation I think writing "using namespace boost::hana" for the documentation is confusion. I know it might be nit-picking, but I think the example is easier to understand when you read struct Fish { std::string name; }; struct Cat { std::string name; }; struct Dog { std::string name; }; auto animals = boost::hana::make_tuple(Fish{"Nemo"}, Cat{"Garfield"}, Dog{"Snoopy"}); instead of struct Fish { std::string name; }; struct Cat { std::string name; }; struct Dog { std::string name; }; auto animals = make_tuple(Fish{"Nemo"}, Cat{"Garfield"}, Dog{"Snoopy"}); Because if you read diagonally (and let's be realistic, we all read diagonally documentation) you might miss what is going on. At least some namespace alias would be helpful. I personally think redundancy is good in documentations. > * Tests There is a satisfactory number of tests and the developer does continuous integration. The developer tests on several compiler versions at every change which is a must for a MPL. > * Usefulness Boost.Hana is extremely useful, especially the compile-time introspection it adds. It uses macros but as long as the language doesn't provide features to do compile-time introspection, there is no way around this (that I can think of) It has a lot of algorithms out of the box (at least I couldn't find one I would need that was missing). I like the compile-time arithmetic part of the library and find it very convenient. I'm a big fan of Boost.Fusion and I use Boost.MPL a lot. Hana replaces both libraries and compiles faster at the cost of requiring recent compilers. It is, to me, a very acceptable tradeoff. > - Did you attempt to use the library? If so: > * Which compiler(s) Clang 3.5 on FreeBSD 10.1 and libc++ > * What was the experience? Any problems? The only problem I have with Hana is that it doesn't work with Visual Studio. The lack of VS is the only reason why we didn't adopt Hana on our product. Nevertheless, I don't think it a showstopper. Hana is an advanced MPL and the problem will solve by itself with time. It works, in my opinion, on a sufficient number on platforms at the moment to be accepted into Boost. > - How much effort did you put into your evaluation of the review? I ran by the examples again as I would if I were trying the library for the first time. I have been following Boost.Hana since Louis' presentation at last year cppcon in Bellevue, Wa. Kind regards. --Edouard

2 1

different Problem cross-compiling against boost.context for Raspberry Pi (2)
by Biddiscombe, John A. 16 Jun '15

16 Jun '15

When compiling HPX against the now built boost, I have this error message /home/biddisco/apps/boost-1_58_0/include/boost-1_58/boost/context/execution_context.hpp:202:52: error: âstd::index_sequenceâ has not been declared std::index_sequence< I ... >) { index_sequence appears to be c++14, I'm using -std=c++11, can one tell if this likely a mistake on my part somewhere, or a possible problem with boost.context? (Is there a BOOST_FLAG_SOMETHING, I should add to prevent t being used?) thanks JB

2 3

[Advice] Documenting the "refined by" relation for concepts
by Louis Dionne 15 Jun '15

15 Jun '15

Dear all, When documenting a concept in a generic library, it is common to include what this concept is a "refinement of", i.e. which other concept(s) it specializes. For example, see the ForwardContainer concept from the SGI STL [1], which is a refinement of the Container concept. I find documenting this relation very useful. However, I have never seen the reverse relation of being "refined by" documented. It has been suggested to me [2] that Hana should document this "refined by" relation. Having never seen it done before, I'd like to know what the seasoned generic library writers think about it. The possibilities I personally see are 1. It's just not useful, and that's why it's not done 2. It's actually harmful, because you can't predict who is going to refine a concept 3. There's no "logical" reason behind this, it just happened to work that way in the SGI STL and everybody else followed that lead. Any input is appreciated. Regards, Louis [1]: https://www.sgi.com/tech/stl/ForwardContainer.html [2]: https://github.com/ldionne/hana/issues/104

5 10

Genetics library - advice needed.
by Andy Thomason 15 Jun '15

15 Jun '15

Hi All, I am getting close to rolling out the first draft of our genetics library. https://github.com/andy-thomason/Boost.Genetics This library allows you to search gene sequences - most commonly the human genome - (eg. ENSEMBL .fa files) for inexact matches. At present the library emphasises thoroughness over performance but the latter will improve. The algorithms are all single-threaded at present as the user should provide the thread control. Feedback would be useful. I appreciate that this is still a little way from being a final submission, in particular we need: * documentation * more examples (currently only a python binding example) * more tests I'll be setting these as a task for my students. Don't expect it to build and run out of the box except for the unit tests and they might not wor in 32 bit builds. I'd also apreciate help with the build system as getting a build on 64 bit windows is a challenge for Boost.Python at present and some wisdom would go far. Are there plans for VC2013/15 solution generation from BJAM? That would be useful. Is there a continuous integration system we could use to pre-check the library? Andy. --- This email is free from viruses and malware because avast! Antivirus protection is active. https://www.avast.com/antivirus

5 7

[Graphs] Bug in directed edge-connectivity algorithm
by Michele Borassi 15 Jun '15

15 Jun '15

Dear all, my name is Michele Borassi, and I am a user of Boost Graph library, version 1.58.0. I have found a problem in the edge connectivity algorithm: if the input is a directed path with 3 vertices (0, 1, 2) and 2 edges ((0,1), (1,2)), the output is 1 (while it should be 0, since the graph is not strongly connected). However, if edge (1,0) is added, the output becomes (correctly) 0. A minimal working example that shows this issue is attached; my output is: Path of 3 vertices and 2 edges. The edge connectivity is 1. Added edge (1,0): now there are 3 edges. The edge connectivity becomes 0. Could you also explain me which is the best way to report a bug? I have checked your web page http://www.boost.org/development/bugs.html, but all links seem to be broken. Waiting for your answer, I thank you in advance, Michele Borassi

4 5

[Better Enums] More complete release - feedback requested
by Anton Bachin 15 Jun '15

15 Jun '15

Hello, I posted to the mailing list some weeks ago concerning a reflective enum library. I’ve since done a lot of work and made a new release. I’d like to get feedback from anyone that is interested. The library can be found at: https://github.com/aantron/better-enums At the risk of repeating myself, let me summarize for those who didn’t read the original thread: the library generates reflective enums that support string conversion and iteration, but with a nicer syntax than seen to date. Also, in C++11, the reflective capabilities are accessible at compile time. Since the original thread, I have made the library work with C++98 with the variadic macro extension, tested it thoroughly on clang, gcc, and msvc, rewrote the documentation, and made the interface (potentially) completely constexpr. The reason I say potentially is that there is one slow feature, which is disabled by default, but can be opted into easily. There is a tutorial starting here: http://aantron.github.io/better-enums/tutorial/HelloWorld.html and a few examples of “advanced” usage, the most interesting one of which I think is: http://aantron.github.io/better-enums/demo/SpecialValues.html (Thanks to Gottlob Frege for making a suggestion, which I adapted to improve this example.) I’d like to take this as far as possible towards solving the problems with C++ enum maintainability, and providing improved enum types that are as near to first-class as possible. I would be very happy if you just tried this out and let me know what you think and what problems you ran into. Thank you, Anton

6 27

a thread pool that allows recursive calls
by Frédéric Bron 13 Jun '15

13 Jun '15

Dear boosters, I need to perform some tasks in parallel and want to control the number of CPUs that are used. A threadpool seems to be what I want and http://threadpool.sourceforge.net/ looks good. However, my tasks may also want to launch some parallel sub-tasks and the sub-tasks may also want to launch tome parallel sub-sub-tasks... and this is not possible with this implementation of threadpool. I have programmed something that works and I wonder if anyone had also already done that because my implementation is very rudimental for now and if something already exists I do not want to reinvent the wheel. Having said that, if there is nothing publicly available (I mean open-source), do you think it would be valuable I share what I did and make it available to boost as a library? This would require some advices/reviews from thread experts and a lot of work from me but I would be happy to contribute. Kind regards, Frédéric

4 5

Heterogeneous Container Library (HCL) Feedback and Testing
by James Armstrong 13 Jun '15

13 Jun '15

I send out a little feeler about a month ago for interest in a container library which natively allows users to insert a heterogeneous set of types. After getting some really good feedback, I think I have settled into something that is efficient, has a nice clean interface, and provides some useful capabilities. I am hoping people can take a look at the code, test it out, and provide an additional feedback in terms of interface, implementation, bugs, or additional features/classes that would be useful. I have implemented a set of containers which mimic the capabilities of the STL containers. These are (so far) * heterovector * heterostack * heteroqueue * heterolist * heteroforward_list * heterodeque These containers were implemented using variadic templates and were somewhat inspired from the posts of Joaquín Muñoz. http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.html In addition, I have an adaptor class which provides a simple interface for accessing data of a specific type from a container of type_erased objects (boost::any, boost::variant, etc). The code is hosted at https://github.com/armstrhu/HCL and the directory structure there should be simple to navigate. There is an include directory which contains the header files needed, and an examples directory which provides examples for using the containers and the adaptors. As they mimic the STL containers, once you see how to use them (basically just provide an additional template parameter) you should be able to use them smoothly. One note is I focused mainly on developing the heterovector class, and the remainders are primarily copies of that class where std::vector has been replaced with std::deque, std::list, etc, and associated methods added/removed as needed. I have primarily tested with the heterovector, so having people check out the other classes would be nice :) Any and all feedback is much appreciated. Thanks! -- James Armstrong

7 18

[Geometry] Wrong results for dissolve Polygon
by Andreas Wimmer 12 Jun '15

12 Jun '15

Dear Boost Geometry Contributors, I am testing the boost::geometry::dissolve function upon some invalid polygons that are produced by a certain in-house segmentation alg. The fact that the algorithm is producing possibly invalid polygons cannot be changed easily so I thought I will fix them afterwards using dissolve from “geometry/extensions/algorithms/dissolve.hpp” for the latest boost 1.58 version. Unfortunately I stumbled over the following polygons for which dissolve produces wrong results. The following code illustrates the result using namespace boost::geometry; using namespace boost::geometry::model; using namespace boost::geometry::model::d2; int main(int argc, _TCHAR* argv[]) { polygon< point_xy<float> > Poly; read_wkt("POLYGON((10 10, 10 20, 20 20, 15 12, 15 18, 20 10, 10 10))", Poly); multi_polygon< polygon< point_xy< float > > > Dissolved; boost::geometry::dissolve(Poly, Dissolved); } Which results in a polygon including the small intersection part which should be excluded from the polygon And even more problematic the following example (same polygon with and additional self-touching outer ring) results in missing the entire main part of the polygon int main(int argc, _TCHAR* argv[]) { polygon< point_xy<float> > Poly; read_wkt("POLYGON((10 10, 10 20, 20 20, 20 25, 22 25, 20 20, 15 12, 15 18, 20 10, 10 10))", Poly); multi_polygon< polygon< point_xy< float > > > Dissolved; boost::geometry::dissolve(Poly, Dissolved); } I hope somebody can show me what I did wrong or what I can to too work around this problem. Best regards, Andreas Wimmer

2 1

Appveyor
by Mathieu Champlon 12 Jun '15

12 Jun '15

Hello, I've seen it mentioned a few times on the mailing list. Can anyone point me to a boost library (or a library which makes use of boost) which builds on appveyor ? A find for appveyor.xml in the boost/libs directory does not yield anything and I couldn't find a way to search for projects on appveyor itself... Thank you ! MAT.

3 4

[status] How should boost/status master be updated?
by Adam Wulkiewicz 11 Jun '15

11 Jun '15

Hi, Some time ago I prepared a PR for develop version of boost/status. Now I'd like to propagate the changes to master. How should I do that? I saw that there are some changes made only in develop and other only in master. Some commits were cherry-picked. What should be the practice in this case? Shouldn't status be made a separate module? It'd greately simplify the synchronization of branches. Regards, Adam

1 0

[boost.lockfree] spsc_queue read/write_available
by Philip Bennefall 11 Jun '15

11 Jun '15

Hi all, I am debugging a crash that I am getting inside of the pop method in spsc_queue from boost.lockfree. I am not sure exactly what is happening yet, but I do have one question. I call read_available and write_available a few times, and am wondering why read_available can only be called from the producer thread and why write_available can only be called from the consumer thread? Wouldn't it make sense to call read_available from the consumer, and write_available from the producer? Why is it the other way around? Currently I call write_available from the thread that pops, and read_available from the thread that pushes. Did I interpret the documentation correctly? If so, some clarifications would be much appreciated. Thanks! Kind regards, Philip Bennefall

2 2

sourceforge and release hosting
by Adam Walling 11 Jun '15

11 Jun '15

Should releases be hosted somewhere other than sourceforge? I've ran across this regarding boost twice this week, and I'm sure we are all well aware of the history of problems that sourceforge has been accumulating. Personally I think twice now every time I happen upon sourceforge, and despite being a source target than binary release, I can't help but be disturbed by these recent events. And I certainly don't want boost associated. Are there any strong feelings among us here regarding this?

7 10

[BestPracticeHandbook] Try the library online
by Krzysztof Jusiak 10 Jun '15

10 Jun '15

Hi, I've recently added a new badge (try boost.di | online) to proposed boost.di library. It uses Wandbox (awesome) facilities to check the library using online compiler (Wandbox supports newest gcc/clang). IMHO this approach is really useful for reviews and new users, since they don't have to install anything, just click the link and its done. They can experiment and then if they like it, clone the library and explore it more. You can check the badge here: http://krzysztof-jusiak.github.io/di/cpp14/boost/libs/di/doc/html And, for inpatients, direct link to online compiler with the library: http://melpon.org/wandbox/permlink/O3ABWKU3VBV3WG8J Let me know, what do you think. Cheers, Kris

2 2

[Config] Support for switching between std:: and boost:: equivalents.
by John Maddock 10 Jun '15

10 Jun '15

There is a pull-request for Config to provide support for switching between boost:: and std:: library equivalents: https://github.com/boostorg/config/pull/63 My questions are: * Is this the right approach? And, * Is Boost.Config the right place for it? Thanks for your comments, John.

10 53

Interest in B-Tree and B+-Tree Implementation?
by Timo Bingmann 10 Jun '15

10 Jun '15

Hello people, I want to ask if there is an interest in adding an in-memory B+-Tree container implementation that I wrote some time ago: https://github.com/bingmann/stx-btree http://panthema.net/2007/stx-btree/ It emulates the std::set/map/multiset/multimap interfaces as far as possible (there are some unavoidable minor exceptions). And since I keep telling my collegues to stop using std::map for bigger instances, I think adding it to Boost would be a good idea. So ... I could clean up my old implementation, add C++11/Boost move semantics, use of uninitialized objects, boostify various things, etc, etc, and then things should be pretty fine. I also have an idea to modify/fork the implementation to create a B-tree (non-plus) container, which should be a bit slower, but provide an interface even closer to std::map (only remaining unavoidable incompatibility would be with iterator invalidation). My main question before starting this is whether it is a better idea to add it to Ion's existing Container library, or to add it as a separate "library" under Boost like the existing circular_buffer, which is pretty old. Apparently libraries have gotten bigger over Boost's life. So which variant would be better? The "Container" library seems to be more targeted at reimplementing STL containers with new features, and simple new containers, not complexer ones? But it should still be a good match. In the incubator I found the "STL Extensions" submission, which appears to be dead. It aims to provide "augmented array based B+ trees", which is different from the usual trees where nodes are dynamically allocated. Best Regards, Timo Bingmann

4 5

[regression] Displaying test categories in the regression matrix
by Adam Wulkiewicz 09 Jun '15

09 Jun '15

Some time ago I defined the categories for tests in Geometry in the explicit-failures-markup.xml file in develop: https://github.com/boostorg/boost/pull/80/files What I'd like to achieve is a matrix similar to the Chrono's one: http://www.boost.org/development/tests/develop/developer/chrono.html However after merging the PR there are no categories in the Geometry matrix. Am I doing it in the correct way? Which version of the explicit-failures-markup.xml is used by the report program, from the develop or master branch? Or maybe must the file be manually placed somewhere? Regards, Adam

1 0

[hana]Either generalization & missing variant
by Larry Evans 09 Jun '15

09 Jun '15

The page: http://ldionne.com/hana/structboost_1_1hana_1_1Either.html contains: An Either contains either a left value or a right value, both of which may have different data types. An Either containing a left value a is represented as left(a), and an Either containing a right value b is represented as right(b). which makes anyone familiar with boost::variant to think that hana's Either is simply a binary boost::variant, and left(a) ~=~ variant<A,B>(a) right(b) ~=~ variant<A,B>(b) where ~=~ means some sort of similarity. However, since the left and right functions only have 1 argument and no template arguments, they can't produce something like variant<A,B> where the left and right types are known. IOW, it seems that left and right are just wrapper's around the types. Looking at the code, the wrappers, _left and _right are defined here: https://github.com/ldionne/hana/blob/master/include/boost/hana/either.hpp#L… https://github.com/ldionne/hana/blob/master/include/boost/hana/either.hpp#L… But why should Either be limited just to _left and _right wrappers. Why not provide wrapper's tagged by some enumerable? For example, something like this: template < typename X , typename Enumerable=unsigned , Enumerable tag=Tag() > struct _tagged //instead of _left and _right : operators::adl { X value; . . . template <typename... F> constexpr decltype(auto) go(F...&& f) const& { return (hana::arg<unsigned(tag)>(f...))(value); } . . . }; This would be more general than the binary Either. In addition, _tagged could be used elsewhere. For example, it could be used in a multiple inheritance implementation of tuple. _tagged is already present in a more general form, in fusion: http://www.boost.org/doc/libs/1_39_0/libs/fusion/doc/html/fusion/support/pa… where: _tagged<X,0> ~=~ fusion::pair<int_<0>,X> The obvious advantage of Either is that it doesn't require memory use equal to the max of the components when the component with the minimum size is used. IOW, left(a) only requires sizeof(A) and right(b) only requires sizeof(B). OTOH, Either, or the generalization described above, can't be used where a true variant is needed, for example, in spirit's attributes for the alternative parser. And this brings up another question. Although hana has a tuple, it doesn't have a variant. Is there any reason for excluding variant from hana? -regards, Larry

4 8

[metaparse] Review period starts May 25th and ends June 7th - ongoing
by Christophe Henry 09 Jun '15

09 Jun '15

Dear all, The review of the metaparse library started last Monday. Please consider taking the time to review it and post comments or reviews on this list. Thanks, Christophe ------------------------------------------------------------------------------------------ Dear all, The review of the Metaparse library starts next Monday, May 25th and ends June 7th. Metaparse was written by Abel Sinkovics. Metaparse is a parser generator library for template metaprograms. The purpose of this library is to support the creation of parsers that parse at compile time. This library is intended to be used for embedded domain specific language creation for C++ and can help libraries provide a better interface. It is similar to Boost.Spirit, however while parsers built with Spirit parse at run-time, parsers built with Metaparse parse at compile-time. It makes it possible for library authors to provide an interface that follows the common notation of the problem domain of the library. (eg. SQL queries, grammars, etc written in their common notation instead of similar-looking C++ expressions). For example there is a (yet incomplete) interface for Boost.Spirit that makes it possible to write MPLLIBS_REGEX("^[abcd][3-8]\\.foo$") instead of bos >> set[as_xpr('a')|'b'|'c'|'d'] >> range('3','8') >> '.' >> 'f' >> 'o' >> 'o' >> eos and make the parser built with Metaparse generate the latter expression from the former one. (It can be found here: https://github.com/istvans/mpllibs/tree/master/libs/xlxpressive) Since the library is based on template metaprogramming, the DSLs can be used for type validation as well. This is demonstrated by the type-safe printf implementation ( http://abel.web.elte.hu/mpllibs/safe_printf/index.html) It type-checks the arguments of a printf call based on the format string and has zero runtime overhead compared to unchecked printf. Parsers can be constructed in a declarative manner and (even though this is template metaprogramming based) remain readable. The implementation reflects the grammar it parses (with additional elements for semantic actions). Even though the library requires the parser author to write template metaprograms, the development of parsers is well supported by tools like Metashell and MDB. An important aspect of parsers (built with this library or another one) is error reporting for invalid input. The library offers tools for the parser authors to be able to provide useful error messages in case of parsing errors. Here is an example error report by a parser built with Metaparse (the parser can be found in the Getting Started guide of the library): ..... x__________________PARSING_FAILED__________________x<1, 5, unpaired<1, 1, literal_expected<')'>>> .... It is an error report letting the developer know that a closing paren is missing at line 1, column 5 and the unclosed opening paren is in line 1, column 1. Metaparse can be downloaded from Github: https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse And a very complete tutorial: http://abel.web.elte.hu/mpllibs/metaparse/getting_started.html The tutorial also offers the nice feature of a link to metashell for quick-starting trying out the library: http://abel.web.elte.hu/shell/metashell.html Boost.Msm v3 also implements a new compile-time strings based front-end called eUML2 to demonstrate the power of the library and the conciseness and expressiveness it allows. Please have a look at the documentation: https://htmlpreview.github.io/?https://raw.githubusercontent.com/boostorg/m… Everybody on this list is invited to participate in this formal review. I hope to see your review of Metaparse, including your vote on acceptance, and I welcome your participation in the ensuing discussions on the Boost developers' mailing list. Please always include in your review a vote as to whether the library should be accepted into Boost. Additionally please consider giving feedback on the following general topics: - 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? Regards, Christophe Review Manager

9 28

Github and forks
by Edward Diener 08 Jun '15

08 Jun '15

My use case is: I want to create a Github PR request against a Boost submodule repository. I then want to create a separate Github PR request against the same Boost submodule repository. I understand the Github mechanism of forking a repository and creating a PR request. For some reason which I do not understand Github will not allow their online forking mechanism to fork the same repository more than once to different names within a user account. In other words if I fork a Boost submodule repository to my user account, rename the repository, and then fork the same Boost repository to my user account again it will just update the renamed repository rather than create a new forked repository again. Considering that Github allows any repository you can find there to be forked to your user account, can anybody think of why Github will not allow the same repository to be forked twice to different repositories ? Of course I can get around this Github forking limitation by creating a new Github repository in myn user account, cloning an existing Github repository locally, and then pushing that cloned repository to my new Github repository. That will create two different repositories off of the same Github repository in my user account. But in this case I can't use the online PR mechanism on this second repository against the original Github repository.

3 3

Dependency report for develop-8fa72a7
by Peter Dimov 08 Jun '15

08 Jun '15

The latest dependency report, which reflects the new "version 2" type traits, is here: http://pdimov.com/tmp/report-develop-8fa72a7/module-overview.html http://pdimov.com/tmp/report-develop-8fa72a7/module-levels.html http://pdimov.com/tmp/report-develop-8fa72a7/module-weights.html

1 0

[Boost-announce] [metaparse] Review period starts May 25th and ends June 7th
by Christophe Henry 08 Jun '15

08 Jun '15

Dear all, The review of the Metaparse library starts next Monday, May 25th and ends June 7th. Metaparse was written by Abel Sinkovics. Metaparse is a parser generator library for template metaprograms. The purpose of this library is to support the creation of parsers that parse at compile time. This library is intended to be used for embedded domain specific language creation for C++ and can help libraries provide a better interface. It is similar to Boost.Spirit, however while parsers built with Spirit parse at run-time, parsers built with Metaparse parse at compile-time. It makes it possible for library authors to provide an interface that follows the common notation of the problem domain of the library. (eg. SQL queries, grammars, etc written in their common notation instead of similar-looking C++ expressions). For example there is a (yet incomplete) interface for Boost.Spirit that makes it possible to write MPLLIBS_REGEX("^[abcd][3-8]\\.foo$") instead of bos >> set[as_xpr('a')|'b'|'c'|'d'] >> range('3','8') >> '.' >> 'f' >> 'o' >> 'o' >> eos and make the parser built with Metaparse generate the latter expression from the former one. (It can be found here: https://github.com/istvans/mpllibs/tree/master/libs/xlxpressive) Since the library is based on template metaprogramming, the DSLs can be used for type validation as well. This is demonstrated by the type-safe printf implementation ( http://abel.web.elte.hu/mpllibs/safe_printf/index.html) It type-checks the arguments of a printf call based on the format string and has zero runtime overhead compared to unchecked printf. Parsers can be constructed in a declarative manner and (even though this is template metaprogramming based) remain readable. The implementation reflects the grammar it parses (with additional elements for semantic actions). Even though the library requires the parser author to write template metaprograms, the development of parsers is well supported by tools like Metashell and MDB. An important aspect of parsers (built with this library or another one) is error reporting for invalid input. The library offers tools for the parser authors to be able to provide useful error messages in case of parsing errors. Here is an example error report by a parser built with Metaparse (the parser can be found in the Getting Started guide of the library): ..... x__________________PARSING_FAILED__________________x<1, 5, unpaired<1, 1, literal_expected<')'>>> .... It is an error report letting the developer know that a closing paren is missing at line 1, column 5 and the unclosed opening paren is in line 1, column 1. Metaparse can be downloaded from Github: https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse And a very complete tutorial: http://abel.web.elte.hu/mpllibs/metaparse/getting_started.html The tutorial also offers the nice feature of a link to metashell for quick-starting trying out the library: http://abel.web.elte.hu/shell/metashell.html Boost.Msm v3 also implements a new compile-time strings based front-end called eUML2 to demonstrate the power of the library and the conciseness and expressiveness it allows. Please have a look at the documentation: https://htmlpreview.github.io/?https://raw.githubusercontent.com/boostorg/m… Everybody on this list is invited to participate in this formal review. I hope to see your review of Metaparse, including your vote on acceptance, and I welcome your participation in the ensuing discussions on the Boost developers' mailing list. Please always include in your review a vote as to whether the library should be accepted into Boost. Additionally please consider giving feedback on the following general topics: - 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? Regards, Christophe Review Manager

23 76

Correct spelling of "suppress"
by Alex Henrie 08 Jun '15

08 Jun '15

Hi, Could you guys take a look at these two pull requests? https://github.com/boostorg/assign/pull/9/files https://github.com/boostorg/iostreams/pull/12/files I thought they would be uncontroversial, but it has been months and they have still not been merged. -Alex

1 0

Boost.Container and tests: why is Boost.Test bypassed
by Thorsten Ottosen 08 Jun '15

08 Jun '15

Hi Ion, I have a GSOC student writing some containers that fit naturally into Boost.Container. So he tries to do things the way that you have done, which is fine. I do wonder why the tests are written with assertions and not using Boost.Test? Is it a dependency problem or? Thanks -Thorsten

7 12

What would make tool authors happier..
by Rene Rivera 08 Jun '15

08 Jun '15

Warning.. Some of this may sound contentious at times.. But that's life ;-) There are a number of disparate discussions going on at the moment that can be summarized as: * A tool author suggesting a change (to structure, or process, or something else) that would make writing tools easier and less error prone. * Lots of responses about how such a change would be disruptive to current practices. * Some responses about how such a change is beneficial to the future of Boost, its growth and possible real modular future. * Some more responses about how the tool authors should just account for all the special cases of the current practices and still bring about the vaunted modular future. So I want to summarize some key changes, as I understand them, that I think will make movement towards a better tooling and development future less painful for the minuscule minority of the people who write the tools that aim to bring that future into existence. First the key aspects of the changes are: 1. Normalized and regular directory structure of libraries, tools, and root. 2. Minimal non-library content and structure. 3. Stricter rules and guidelines for library authors to follow regarding the needs of the infrastructure tools. Some of the specific changes some of us have mentioned that touch on the above aspects are.. * Making the combined library headers go into boost-root/include. See separate post from Peter Dimov about this. This touches on #1 as it makes for a user and tool expected location. That is, users are accustomed to looking for a top level include. And having such a location would reduce the documentation and instruction needed to point them away from their intuitive behavior. External tools also expect to find such a directory for a library, which is what a monolithic Boost looks like to tools. Hence it would make it easier to use, incorporate, author, etc tools. * What I've mentioned as "flattening" of libraries. Which touches on #1 and #3 above. This has multiple parts/meanings so let me explain each one separately. First, it means is banning of git sub-modules outside of directly under boost-root/libs and boost-root/tools. Dealing with git sub-modules is difficult enough even when it's just a handful of sub-modules. But dealing with the 130 sub-modules we have now is an insanity inducing experience when there needs to be handling for special locations. Currently the only culprit of this is "libs/numeric". And I understand that it was done this way because that was the old structure converted to the modular git form. But I think it's time to truly abandon the old structures as they are standing in the way of better tools and user experience. As an example of user experience, I once tried to set up my own subset of Boost as a git repo that had all the libraries and tools needed for the documentation toolchain. It was excruciating to manually discover what all those libraries where particularly because of no initially knowing about this aspect of our current sub-modules. Second, it means formalizing and regulating the top level structure of libraries. For the longest time we've had an accepted top level structure. Unfortunately library authors have added to that top level structure. For example to manage "sub-libraries" or "sub-parts" of their library... Which is understandable. But it makes life more difficult for the tools that rely on the structure assertions. For example currently the testing scripts rely on people updating a single listing file at "boost-root/status/Jamfile.v2". When in an ideal world the test tools would be able to automatically discover that information. Practically it means that currently that Jamfile lists 127 test dirs. But a cursory discovery of test dirs goes up to a possible 197. As far as following the top-level library structure.. There are currently 279 files and directories at the library top level that are not in the accepted set (and I'm already excluding things like readmes and changelogs, even though changelogs should be in docs). But do note.. That I'm not suggesting that we immediately ban the old structure. But that we start discussing what are the needs of library authors and that we come up with a consistent and enforced structure that can relied upon by users and tools. Some changes that may be the first time I bring them up.. * Remove as much as possible from boost-root. This is mostly #2 above. First, I would like to remove the "boost-root/more" directory. Stuff in it are docs of various kinds and should be placed in "boost-root/doc", in the website, in tool docs, or in library docs. While doing that I'm sure we will likely also rewrite/clean-up those documents to better reflect the present. Second, I would like to move as many of the root build files to a "boost-root/build" directory. Ideally they would all be moved but it may not be possible, and practical, to do so. This would mirror the general top-level structure and hence make it a bit more intuitive for new authors and users to find. Third, I would like to clean up the various CSS and HTML sources at the root to either a smaller number (do we really need index.htm *and* index.html?), or to the doc directory. I know.. This isn't exactly in the vein of what makes it easier for tool developers. But it does make it easier for users to initially navigate (because there's less noise for them to look at). Last, I would like to re/move the "boost-root/status" directory. Two options I'm considering are moving to be "boost-root/test" to match the usual name for testing scripts. Or removing it and replacing it logic in the regression tools that is equivalent (i.e. move the functionality to the separate regression git repo). I believe that all those changes will help in moving us toward what I'm starting to call a "comprehensive" Boost release. Such a release would not follow the monolithic structure we currently have of needing the big include directory. But instead would be a plain collection of the individual libraries and tools that users can enable/install from the comprehensive package they download. Or possibly use directly if they add the individual libraries to their project search (and obviously build for the ones that need it). Such a "comprehensive" release would make the release process, and the tools driving it, a much simpler process and almost certainly increase the frequency of comprehensive release (possibly even to an almost weekly or daily occurrence). Last note.. It's never too late to fix problems even if there's work needed to adjust to the fixes. After all, programmers are accustomed to change. We deal with it and move on. So if we can make changes that reduce our future pain, we should do those changes. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

9 38

[testing][regression] Heads up: compilation warnings are available for passing tests.
by Adam Wulkiewicz 08 Jun '15

08 Jun '15

Hi, For passing tests which are expected to pass, if warnings are generated during the compilation they can be seen after clicking on the "pass" link. If the link isn't there it means that there were no warnings. I hope it will allow us to improve the quality of the libraries even more. Regards, Adam

4 10

[winapi] Problem with the latest clang on Windows
by Edward Diener 08 Jun '15

08 Jun '15

Updates to clang on Windows have broken the use of clang with the [winapi] library. I do not know if this has occurred in the past but it seems to have occurred recently when I build the latest clang from source and use it on Windows to compile build Boost libraries which use the internal winapi library. Preprocessing clang and gcc output for a given call in the Boost winapi library and in the corresponding mingw windows.h shows that both compilers view the same source but treat them differently. As an example let's look at the GetSystemTimeAsFileTime call. The preprocessed source for both clang and gcc shows: In the Boost winapi it is: __attribute__((dllimport)) void __attribute__((__stdcall__)) GetSystemTimeAsFileTime(FILETIME_* lpFileTime); In the mingw/gcc windows.h it is: void __attribute__((__stdcall__)) GetSystemTimeAsFileTime(LPFILETIME); where the FILETIME_ and LPFILETIME are the same. When gcc sees these two declarations in the two different headers it says everything is OK. When clang sees these two declarations in the two different headers it gives an error: In file included from test_winapi.cpp:9: In file included from /mingw/include\windows.h:62: /mingw/include\winbase.h:1397:24: error: conflicting types for 'GetSystemTimeAsFileTime' WINBASEAPI void WINAPI GetSystemTimeAsFileTime(LPFILETIME); ^ ..\..\..\boost/detail/winapi/time.hpp:70:9: note: previous declaration is here GetSystemTimeAsFileTime(FILETIME_* lpFileTime); ^ For this line in boost/detail/winapi/time.hpp __declspec(dllimport) void WINAPI GetSystemTimeAsFileTime(FILETIME_* lpFileTime); It seems like the fix for clang is to leave out the __declspec(dllimport) portion of all these Boost winapi calls while leaving it in for everybody else. I am discussing this on the clang developers mailing list but it seems like they are pretty adamant that if they see __attribute__((dllimport)) in from of a function declaration and do not see it in front of another function declaration, despite the rest of the signatire being the same, the two declarations are not the same function being declared and therefore an error because of ODR.

7 28

[hana]missing link on http://ldionne.com/hana/index.html#tutorial-integral
by Larry Evans 07 Jun '15

07 Jun '15

The link with name: boost::hana::literals takes my browser to: http://ldionne.com/hana/namespaceboost_1_1hana_1_1literals.html which my browser (firefox) displays with: Louis Dionne Programming and Categories, Oh My! 404: Page not found

2 3

[metaparse] performance comparisons?
by Peter Dimov 07 Jun '15

07 Jun '15

Abel, After looking at Metaparse, I inquired on the c++std-ext list as to whether user-defined operators can create char packs from integer or floating point literals, but not from string literals, as this would have made the MPLLIBS_STRING macro unnecessary. As it turns out, there has been such a proposal, N3599: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3599.html later referenced by two competing proposals for compile-time string literals, N4121 and N4236: https://isocpp.org/files/papers/n4121.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4236.html N3599 has been however rejected, as the committee apparently feels that representing compile-time strings as char packs is inefficient and impractical, and prefers constexpr char arrays. I cited Metaparse as an argument that char packs are quite obviously practical if they work in practice, and was asked whether measurement data has been presented as part of the formal review, perhaps compared to alternatives. I'm not aware of any alternatives to Metaparse though, so this question may be hard to answer. :-) Either way, the only performance data I see is http://abel.web.elte.hu/mpllibs/metaparse/performance.html which seems rather slim. Is there any other? (On an unrelated note, the cpp-next.com link is dead, but archive.org still has it at http://web.archive.org/web/20140217173026/http://cpp-next.com/archive/2012/…)

5 19

Boost documentation with ability for users to post comments
by Krzysztof Jusiak 06 Jun '15

06 Jun '15

Hi, Recently I come across presentation from CppCon 2015 (Boost 2.0 by Robert Ramey). One of the points mentioned was related to adding possibility to allow users to post comments on the documentation pages. I have recently added such functionality to Boost.DI documentation using https://disqus.com service. It allows you to have comments on each page. It's also really easy to do add it to qbk based documentation: 1. Create an account on disqus service and add your website (consider allowing anonymous posts in settings) 2. Generate html doc using boost quickbook as usual 3. Add comments with simple script: find html -iname "*.html" | xargs sed -i -e '/<\/body>/{r comments.html' -e 'd}' -e 's/<\/html>/<\/body><\/html>/' where comments.html content is taken from disqus service -> https://github.com/krzysztof-jusiak/di/blob/cpp14/doc/comments.html 4. Deploy and enjoy users being able to add/read comments.... (on the bottom of each page) That's all, you can try it out and post, preferably useful feedback, on Boost.DI documentation website: http://krzysztof-jusiak.github.io/di/cpp14/boost/libs/di/doc/html/ Cheers, Kris

8 13

Help with adding BOOST_INCLUDE to Jamroot?
by Peter Dimov 06 Jun '15

06 Jun '15

I'm trying to add a BOOST_INCLUDE variable to Jamroot, with an initial value $(BOOST_ROOT): path-constant BOOST_ROOT : . ; +path-constant BOOST_INCLUDE : . ; I then replaced the places where . is used directly as the include path (see diff at end of mail.) Now "b2 headers" works as expected, but when I remove boost/ and go into, for instance, libs/smart_ptr/test and run b2, it doesn't recreate the header links, whereas it did so before. I've no idea why. Can anyone help? diff --git a/Jamroot b/Jamroot index eda4fb4..a999a57 100644 --- a/Jamroot +++ b/Jamroot @@ -131,6 +131,7 @@ import path ; import link ; path-constant BOOST_ROOT : . ; +path-constant BOOST_INCLUDE : . ; constant BOOST_VERSION : 1.59.0 ; constant BOOST_JAMROOT_MODULE : $(__name__) ; @@ -143,7 +144,7 @@ local all-headers = for dir in $(all-headers) { - link-directory $(dir)-headers : libs/$(dir)/include/boost : <location>. ; + link-directory $(dir)-headers : libs/$(dir)/include/boost : <location>$(BOOST_INCLUDE) ; explicit $(dir)-headers ; } @@ -153,7 +154,7 @@ if $(all-headers) } project boost - : requirements <include>. + : requirements <include>$(BOOST_INCLUDE) [ boostcpp.architecture ] [ boostcpp.address-model ] @@ -169,7 +170,7 @@ project boost <toolset>como-linux:<define>_GNU_SOURCE=1 # When building docs within Boost, we want the standard Boost style <xsl:param>boost.defaults=Boost - : usage-requirements <include>. + : usage-requirements <include>$(BOOST_INCLUDE) : build-dir bin.v2 ; @@ -234,7 +235,7 @@ for local l in $(all-libraries) # Log has an additional target explicit-alias log_setup : libs/log/build//boost_log_setup ; -alias headers : $(all-headers)-headers : : : <include>. ; +alias headers : $(all-headers)-headers : : : <include>$(BOOST_INCLUDE) ; explicit headers ; # Make project ids of all libraries known. @@ -281,9 +282,9 @@ rule boost-install ( libraries * ) headers = # The .SUNWCCh files are present in tr1 include directory and have to be # installed (see http://lists.boost.org/Archives/boost/2007/05/121430.php) - [ path.glob-tree $(BOOST_ROOT)/boost : *.hpp *.ipp *.h *.inc *.SUNWCCh : CVS .svn ] - [ path.glob-tree $(BOOST_ROOT)/boost/compatibility/cpp_c_headers : c* : CVS .svn ] - [ path.glob boost/tr1/tr1 : * : bcc32 sun CVS .svn ] + [ path.glob-tree $(BOOST_INCLUDE)/boost : *.hpp *.ipp *.h *.inc *.SUNWCCh : CVS .svn ] + [ path.glob-tree $(BOOST_INCLUDE)/boost/compatibility/cpp_c_headers : c* : CVS .svn ] + [ path.glob $(BOOST_INCLUDE)/boost/tr1/tr1 : * : bcc32 sun CVS .svn ] ; # Declare special top-level targets that build and install the desired variants

1 0

[context] Fwd: [Boost-testing] Master regression shunts not finding asm/make_i386_ms_pe_gas.asm
by Rene Rivera 06 Jun '15

06 Jun '15

---------- Forwarded message ---------- From: Jim Bell <Jim(a)jc-bell.com> Date: Sat, Jun 6, 2015 at 8:04 AM Subject: [Boost-testing] Master regression shunts not finding asm/make_i386_ms_pe_gas.asm To: Running Boost regression tests <boost-testing(a)lists.boost.org> error: Unable to find file or target named error: 'asm/make_i386_ms_pe_gas.asm' error: referred to from project at error: '../libs/context/build' _______________________________________________ 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

2 1

IOStreams zlib_decompressor does not check crc for empty string
by John Wallace 05 Jun '15

05 Jun '15

When decompressing an empty file, the zlib_decompressor does not check the crc, which can cause an exception to be raised on a correctly-formatted gzip file, especially when the gzip file is created by concatenating compressed blocks. This comes up especially when working with bgzip files (see specification at: http://bioinformatics.oxfordjournals.org/content/27/5/718.full; all bgzip files end in a special empty block) I have attached a demonstration file (zlib_test.cpp) that illustrates the problem. This program simply reads a compressed input line by line from stdin and outputs to stdout (nearly equivalent to zcat). Assuming we compile to a.out, the following BASH commands illustrate the issue: $ cat <(echo "foo" | gzip -c) <(echo -n "" | gzip) <(echo "bar" | gzip) | ./a.out foo Whereas, we expect the following: $ cat <(echo "foo" | gzip -c) <(echo -n "" | gzip) <(echo "bar" | gzip) | zcat foo bar I have attached a patch to zlib.cpp (base version 1.51, but I confirmed that it persists in 1.58) which I believe should resolve the issue by simply setting the crc to 0 when an empty string is decompressed. Thanks for your time, John Wallace

1 0

[metaparse] review
by Andrzej Krzemienski 05 Jun '15

05 Jun '15

Hi, I wish I had more time to thoroughly review and test the implementation, but as this is not possible I will have to take risk and vote without the in-depth investigation. I vote YES, this library is needed in Boost. Although it will be used only by a fraction of community, it is an essential complimentary part to the Standard C++ user-defined literals (in raw form). The Standard offers a way to decompose a a user-defined literal into a sequence of characters each passed as a separate template argument. This enables to build at compile time constants of user defined numeric types, but doing it is hard, and the Standard offers little help. This is where Abel's library comes into rescue. Although it was designed to do much more, it also fills this sort of hole in the Standard. I have read Abel's posts, and know he has been working on the subject for a couple of years now, so I am confident in his competence. In a way, I see two components inside: (1) A tool for converting a string literal into instantiation of string<> template. (2) tools for parsing those string<>s. I see use cases for each of these components separately. Parsing templates with characters, is painstaking but fairly easy, so I may want to do it myself, provided I have a way to convert a string literal to a template. I was trying to hack it for a long while, without success. There is quite a bit of trickery put into it. It is really ingenious. On the other hand, when processing my raw user-defined literals, I may need your parsers, but I care not about BOOST_MS_STRING() (or how you want to call it). The standard questions: - What is your evaluation of the design? > Adequate: this is string parsing what the library does, so the parser interface seems the right choice. > - What is your evaluation of the implementation? > I haven't looked at the parsers. Regarding, BOOST_MS_STRING(), it is a nice trick to implement the impossible. > - What is your evaluation of the documentation? > Well, after having read it, I understood what to expect of it, so in that sense, it is adequate. But there is something about it that makes it "heavy". Maybe it is just the problem domain, I do not know. > - What is your evaluation of the potential usefulness of the library? > It is useful, although to a fraction of community: libraries with user-defined literals, printf, other EDSLs. > - Did you try to use the library? > I tested BOOST_MP_STRING() (couldn't believe it works). - With what compiler? MinGW on Windows, GCC 4.8.2 - Did you have any problems? > Nope > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > I read the docs (not all of them); downloaded and played with BOOST_MP_STRING(). -- two hours. - Are you knowledgeable about the problem domain? I never had to do parse at compile time for my commercial programs, but as a hobby I studied the subject, and have even written some posts about it. Thanks Abel, the library is cool. --&rzej

2 5

[metaparse] Update review
by Edward Diener 04 Jun '15

04 Jun '15

This is an updated review of the metaparse library. In my initial review I reacted to the fact that library presentation had changed during the review period. Although I feel I made a point I was too harsh in doing so. So now I would like to review the library as it has been presented in its form suitable for review as a modular boost library. - What is your evaluation of the design? The design of the library appears well thought out to me, providing both low-level and higher-level metafunctions for use. The higher level metafunctions take other metafunctions as input in a classic design of metafunction programming as explained in MPL. The design of the library makes it easy for anybody with knowledge of MPL to understand how to use the metafunctions in the library and to create one's own higher level metafunctions for particular parsing tasks if necessary. A couple of quibbles about the design based merely on my own sense of 'naming'. Since I have roundly criticized "naming wars" <g> in the past I no doubt leave myself open for criticism, but these are just personal suggestions, which I can live without: * BOOST_STRING is very generic and can easily lead to a macro clash. Something like BOOST_METAPARSE_STRING or maybe BOOST_MPS_STRING would be more distinct and safer. I favor shortened names for libraries in macros to be 3 characters rather than 2 characters so as to decrease macro clashes. * The various 'foldxxx' names, even with the Cheat-Sheet explanation of their name formation in the docs, seems needlessly confusing. Would it not be better to make longer, less confusing names, which actually spell out what the metafunctions are about. Is it really so hard to write "fold_left', 'fold_right', 'fold_left_fail' etc. etc. Sometimes clarity trumps how many keys one types. - What is your evaluation of the implementation? I didn't look at the code of the implementation. I generally trust that if the code works as documented an experienced programmer's implementation is his own affair. - What is your evaluation of the documentation? The documentation is fairly profuse approaching the subject of compile-time parsing in many different ways. I found that the work needed to produce a solid set of documentation had been done. I have some quibbles and a few suggestions so let me give it as a general list of items: * A general discussion about the purpose of the functionality of the library would be welcome. Such as the possible metaprogramming scenarios in which a programmer would want to accept and analyze ( parse ) an MPL string in creating his metafunctions. * A general comparison of when it might be better/worse to use Metaparse as oppose to Boost.Spirit. Pluses and minuses of both approaches might be discussed. * On the first page of documentation it mentions the various types of output which Metaparse can generate. Both 'types' and 'metafunctions' are very understandable, but whatever is meant by "Objects" and "Callable C++ functions" doesn't follow the definition of these terms in C++ which I know. Some discussion, or link, of what these two types of output mean in the context of Metaparse should be given. * The Versioning section appears to be wrong in quite a number of places. Please proofread what was written there and correct/update it. * In the Reference section, among the items enumerated at the end are 'Metafunctions and metafunction classes' and "Utilities' but when you click on the links to go the actual headings it looks like the metafunctions are split before and after the utilities. - What is your evaluation of the potential usefulness of the library? I think it give the template programmer another important tool for designing templates for end-users. As such it has intrinsic value for programmers writing templates for end-users to use. - Did you try to use the library? Yes. - With what compiler? I used the Metashell tool to test things out. I then tried manually compiling some examples in the documentation with Mingw/gcc-4.9.2 with '-std=c++11'. I also ran the tests successfully with Mingw/gcc-4.9.2 with '-std=c++11'. - Did you have any problems? No. Everything worked as expected. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? My main effort was in trying to understand how the parts of the library worked with each other. It is not easy to understand everything, and I do not claim that I do, but I could understand from the documentation how the major areas of parsing worked and what metafunctions are used for what tasks. I could also see that if would be easy to incorporate one's own metafunctions into generalized parsing tasks using what Metaparse provides. I did need the full documentation set, which is profuse, to understand the parts of the library. Part of my initial reaction when the library was first presented was that I could only find the documentation for the 'Getting Started' link, and I am one of those people who is just mentally incapable of understanding code from the point of view of "here's how to use" documentation only. Once I discovered the full documentation in the updated presentation of the library in modular Boost form I could see and understand the library much better. - Are you knowledgeable about the problem domain? Generally knowledgable about parsers and how they work, but not an expert. Finally I vote YES to accept the library into Boost, reversing my previous initial vote. The library will prove useful for template programming in some contexts, has obviously been designed thoughtfully, and the full documentation presents everything one would need to use the library, explaining things in various effective ways, one or more of which ways should satisfy all programmers who do template programming.

5 4

Link to Bind library doc broken.
by Alex Mohr 04 Jun '15

04 Jun '15

This link for the Bind library is broken on this page: http://www.boost.org/doc/libs/ The link goes here, which gives a 404 not found: http://www.boost.org/doc/libs/1_58_0/libs/bind/doc/html/bind.html Alex

2 1

Moving the include directory to $BOOST_ROOT/include? (again)
by Peter Dimov 04 Jun '15

04 Jun '15

I want to reiterate my suggestion that we move Boost's include directory from $BOOST_ROOT to $BOOST_ROOT/include. This has the following benefits: - it follows the established naming practice, - it does not make the whole Boost reachable from the include path as it does now, - when building Boost, the message given at the end would be The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: C:\Projects\boost-git\boost\include The following directory should be added to linker library paths: C:\Projects\boost-git\boost\stage\lib instead of the current The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: C:\Projects\boost-git\boost The following directory should be added to linker library paths: C:\Projects\boost-git\boost\stage\lib which is more in line with a user's expectations. - it's more consistent because it builds the virtual include/ subdirectory from the contents of the multiple libs/*/include/ subdirectories. For backward compatibility, "b2 headers" could create a boost/ symlink to include/boost/. Also for backward compatibility, monolithic releases can continue to ship the headers in boost/ if moving the directory would be seen as too disruptive. Failing acceptance of the above proposal, can we at least use a path constant (BOOST_INCLUDE?) somewhere in Jamroot or boostcpp.jam that identifies where the header links are to be placed? Its current contents would be "." but I would be able to change that to "include" instead of locating and patching all the places that refer to the include path.

8 19

[metaparse] review
by Gordon Woodhull 04 Jun '15

04 Jun '15

Hi all, I believe that Metaparse should be accepted into Boost. > - What is your evaluation of the potential usefulness of the library? As mentioned by others, Metaparse is a library for library developers. In terms of functionality, it is closest to Boost.Proto, although it allows defining arbitrary EDSLs as strings, instead of using the built-in C++ operators. In order to test the effectiveness of Metaparse, I built a parser for the Graphviz "dot" language [1]. This is of practical importance to me, because I have an interest in graph metaprogramming [2], specifically generating types and networks of types from graph metadata. Having a nice language for defining graphs in metadata, to support a syntax beyond angle brackets, would be very helpful. One limitation of this class of EDSL is that it can produce arbitrarily complex types, but it can't refer to any existing types. E.g. you might have the string "int" in your EDSL, but in order for it to refer to the C++ int type, you are going to need an mpl::map from type-strings to types. I didn't get this far in my evaluation, but it's really beyond the scope of the library. > - Are you knowledgeable about the problem domain? Fairly knowledgeable. I have built an experimental parser for compile-time EDSLs over type expressions called "Angly" [4] (presented at C++Now 2012). I have learned from the considerably simpler design of Metaparse, and hope to apply it to my own library (in particular using recursive descent rather than trying to wrangle a deterministic finite automaton). > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I spent about 5 hours getting set up and working through the tutorial, and about 7 hours getting up and running with my own parser. Once I "got it", it only took an hour or two to implement the rest of the grammar (and about 4 hours to write this review). My results (grammar and a few basic tests) are in a Gist available here: [3]. My grammar is able to parse "dot" graph descriptions that look like this "graph g { A [x=y]; \ B->C [y=z, w=a]; \ D->E; \ F; \ G->H [a=b, b=c, c=d, d=e, e=f, f=g]; \ I->J; \ }" Because I ran out of time, my parser only produces an AST; it does not yet produce MPL.Graph or Fusion.Graph types. > - Did you try to use the library? > - With what compiler? > - Did you have any problems? I mostly used metashell for my evaluation, but I also tested compilation times with clang 3.5 once I had something running. Any problems I had were the usual difficulties of TMP. I was not expecting the compile times to be tolerable, but even in metashell, the turnaround was usually around 15-20s. Compiling my longest test with clang, just shy of 256 characters, took only about 4-5 seconds. > - What is your evaluation of the documentation? Excellent. Working through the tutorial was enough for me to absorb the particular constructs needed for building grammars and semantic actions. I also used the reference documentation when building my own parser. This documentation is more terse, very much in the style of the MPL documentation. But it functions. I only skimmed the user manual, since the content looks a little bit stale (doesn't mention build_parser) and somewhat redundant with the tutorial. As Andrzej mentions, there may need to be an introduction concerning the scope of the library and what you can and can't do with this kind of EDSL, where you would use Proto instead of Metaparse, etc. I think that as the library evolves, the documentation will probably need more general parsing background, of the sort you will find in Spirit documentation. For example, the tutorial covers the unary `-` operator, but it doesn't mention why there is no ambiguity with the binary `-` operator. Also, it seems (as mentioned in the design discussion below) that the grammar must be unambiguous, and this is mentioned nowhere. Overall, the documentation is stronger on the meta- than the -parse. > - What is your evaluation of the implementation? I did not peer into the code very much, beyond finding some examples I needed. My impression from Abel's walk-through at C++Now 2012 is that the implementation is quite simple and straightforward, based on established techniques from parsers in Haskell. > - What is your evaluation of the design? Very good. However, I think the API might be fleshed out a little bit once the library gets more usage. In particular, I found myself writing a few helper metafunctions that looked like this: template<typename EdgeDecl> struct declare_edge { typedef edge_decl<typename mpl::at_c<EdgeDecl, 0>::type, typename mpl::at_c<EdgeDecl, 2>::type, typename mpl::at_c<EdgeDecl, 3>::type> type; }; invoked from a transform like this: using edge_stmt = transform< sequence<ID, arrow_token, ID, opt<attr_list, mpl::vector<>>>, mpl::quote1<declare_edge> >; It may be my inexperience, but it struck me that it would be helpful to have a "spread" or "apply" transform so that the items in the mpl::vector produced by sequence would be supplied as parameters to declare_edge, instead of having to pull them out using mpl::at_c. There may be some trick I don't know here. I will mention two other points of confusion. These are probably not design flaws in the library, but I thought I would bring them up in case they are. First, I started out defining my AST nodes like this: template<typename Tail, typename Head, typename Attrs> struct edge_decl {}; Seems like a reasonable basic type-holder to me. As shown above, this is instantiated and returned by a helper metafunction invoked by the transform which pulls stuff out of an mpl::vector. But then somewhere in metaparse, it tries to again "invoke" this result with ::type when appending it to another mpl::vector. Really? So my transform needs to return not the value, but a metafunction which returns a value? I couldn't figure this out, so I gave each of my AST nodes a self-referential ::type in the way that mpl::vector has: template<typename Tail, typename Head, typename Attrs> struct edge_decl { typedef edge_decl type; //why? }; Something is not right here! The second problem I encountered is about ambiguous grammars. For the "dot" language it seems natural to define a statement this way: using stmt = one_of<node_stmt, edge_stmt>; where a node statement looks like ID [attr=value, attr=value]; and an edge statement looks like ID -> ID [attr=value]; But there's an ambiguity here, and once the parser successfully reads a node, it is going to get upset if it sees a `->`. So the rule has to be written the other way: using stmt = one_of<edge_stmt, node_stmt>; Similarly, the `;` separator for declarations is optional in the "dot" language, but I couldn't figure out how to implement this, because if you try to have an optional element at the beginning of a rule: template<typename Parser, typename Default = void> using opt = one_of<Parser, return_<Default>>; using stmt_list = foldlp< sequence<opt<semi_token>, stmt>, transform<stmt, mpl::quote1<mpl::vector1>>, // ... then the parser will greedily eat the epsilon and have nowhere to go (at least according to my amateur understanding of parsers). I gave up here and made the separator mandatory. Again, this is probably not a flaw in the design, but the documentation should describe what kinds of grammars will work, and perhaps give pointers to other resources about disambiguating grammars. Probably there is a different construct which would help here. Cheers, Gordon [1] http://www.graphviz.org/doc/info/lang.html [2] http://metagraph.info/wp-content/uploads/2011/05/mpl.graph_.pdf [3] https://gist.github.com/gordonwoodhull/dcbb332eea06dd3279b9 [4] https://github.com/gordonwoodhull/metagraph

2 5

[build] Error building bjam on cygwin
by Emil Dotchevski 03 Jun '15

03 Jun '15

I'm trying to build bjam from Boost 1.56.0 under cygwin. Running ./build.bat mingw errs with: gcc -DNT -o bootstrap\jam0.exe command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c filent.c:46:20: fatal error: direct.h: No such file or directory #include <direct.h> ^ compilation terminated More errors follow. What am I doing wrong? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

[thread] Problem with thread test 'failed to write output file'
by Edward Diener 03 Jun '15

03 Jun '15

Attempting to run the 'thread' tests locally I get: failed to write output file '..\..\..\bin.v2\libs\thread\test\upg_lock_cons_move_ctor_sh_lock_untl_p_lib.test\msvc-12.0\debug\threading-multi\sync\mutual_exclusion\locks\upgrade_lock\cons\move_ctor_shared_lock_until_pass.obj.rsp'! This is with the --abbreviated-path option. If I try using --hash or not using either on the b2 command line I still get the same result of 'failed to write output file ... etc,' probably because the output file spec is still too long. This happens on Windows thread tests with msvc-12.0 but not with gcc-4.9.2. Any ideas how I can get this to run successfully ?

1 1

[admin] General Boost email?
by Rene Rivera 02 Jun '15

02 Jun '15

I've been experimenting with the various cloud based CI systems out there in an effort to make it easy to have all Boost libraries CI tested. As part of that I'm trying to set up an organization account in Appveyor and I'm stuck.. As I need a global org email to register. Hence I would like to request that we set up an "owners(a)boost.org" email that we can use for such circumstances (that just forwards to the git boostorg owners). Does that sound OK? Whom would set up such an email? -- -- 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

[test] possible bug in 1.47.0
by Damian Vicino 02 Jun '15

02 Jun '15

Hi, I’m working in the safe_float library and while working on it I defined a partial specialisation of numeric_limits for safe_float. I wanted the safe_float<T> to mimic the T numeric_limits in most of the values and just change a few, but nothing complex, one liners only. Then, I created a test for validating those methods/attributes mimicking the internal T are equal to those on T, as follows: //types to be tested using test_types=boost::mpl::list< float, double, long double >; using namespace boost::safe_float; BOOST_AUTO_TEST_CASE_TEMPLATE( safe_float_numeric_limits_basic_fp_types, FPT, test_types){ BOOST_CHECK_EQUAL(std::numeric_limits<safe_float<FPT>>::is_specialized, std::numeric_limits<FPT>::is_specialized); } The test does not even compile: Undefined symbols for architecture x86_64: "std::__1::numeric_limits<boost::safe_float::safe_float<double, boost::safe_float::policy::check_addition_overflow, boost::safe_float::policy::on_fail_throw, boost::safe_float::policy::cast_none> >::is_specialized", referenced from: safe_float_numeric_limits_suite::safe_float_numeric_limits_basic_fp_types<double>::test_method() in numeric_limits_test.o After looking at the numeric_limits specialisation for a while, I tried changing the test as follows: if (std::numeric_limits<safe_float<FPT>>::is_specialized == std::numeric_limits<FPT>::is_specialized){ BOOST_CHECK(true); } else { BOOST_CHECK(false); } And as follows: BOOST_CHECK(std::numeric_limits<safe_float<FPT>>::is_specialized == std::numeric_limits<FPT>::is_specialized); Both alternatives work. Is there something wrong with BOOST_CHECK_EQUAL? I’m using version 1.47.0 Best regards, Damian

2 1

Boost.Test v3 is here
by Gennadiy Rozental 02 Jun '15

02 Jun '15

Boost.Test team is proud to present new version of Boost.Test library. This milestone release among many other thing includes: * Completely updated (and hopefully improved) documentation * New universal testing tool BOOST_TEST * Support for decorators * Support for data driven test cases * and much more (you can see changelog here: http://raffienficiaud.github.io/test/boost_test/change_log.html This release would not be possible without Raffi Enficiaud, who joined the team and jump started documentation rework and Andrzej Krzemieński's major contribution to the new documentation. We invite everyone to review and comment on new documentation (http://raffienficiaud.github.io/test/index.html) We will be happy to accept your pull requests with improvements and notes in the mailing list. Unless we find any major showstopper we plan to merge to the master branch in 2-3 weeks time. We do not anticipate backward compatibility issues, but please report any you observe and we'll try to address them in a timely manner. Once again, please review the new documentation and feel free to comment here or by sending us pull requests. Regards, Gennadiy Rozental

8 12

Running regression tests locally
by Andrzej Krzemienski 01 Jun '15

01 Jun '15

Hi Everyone, I need an advice here. When I look at the test matrix online, I can easily see how many tests failed. In contrast, when I run the tests locally (call b2 in folder 'test') I get a bunch of output, but I cannot easily figure out if and how many tests have failed. Is there a way to do it? Or to build a summary of some sort? Regards, &rzej

2 1

[b2] Need help with b2
by Andrzej Krzemienski 01 Jun '15

01 Jun '15

Hi everyone, Today after doing a `git pull --rebase` on modular Boost, b2 stopped working for me. I keep getting the following error. Can someone help me figure out what this is? Regards, &rzej C:/source/modular-boost/tools/build/src/build\feature.jam:139: in feature.feature from module feature error: unknown attributes: hidden error: in feature declaration: error: feature "deduced-address-model" : "32" "64" : "propagated" "optional" "composite" "hidden" C:/source/modular-boost\boostcpp.jam:570: in load from module boostcpp C:/source/modular-boost/tools/build/src/kernel\modules.jam:289: in modules.import from module modules C:/source/modular-boost/tools/build/src/build\project.jam:1024: in import from module Jamfile<C:\source\modular-boost> ..\..\..\Jamroot:124: in modules.load from module Jamfile<C:\source\modular-boost> C:/source/modular-boost/tools/build/src/build\project.jam:311: in load-jamfile from module project C:/source/modular-boost/tools/build/src/build\project.jam:64: in load from module project C:/source/modular-boost/tools/build/src/build\project.jam:113: in load-parent from module project C:/source/modular-boost/tools/build/src/build\project.jam:449: in initialize from module project C:/source/modular-boost/tools/build/src/build\project.jam:301: in load-jamfile from module project C:/source/modular-boost/tools/build/src/build\project.jam:64: in load from module project C:/source/modular-boost/tools/build/src/build\project.jam:113: in load-parent from module project C:/source/modular-boost/tools/build/src/build\project.jam:449: in initialize from module project C:/source/modular-boost/tools/build/src/build\project.jam:301: in load-jamfile from module project C:/source/modular-boost/tools/build/src/build\project.jam:64: in load from module project C:/source/modular-boost/tools/build/src/build\project.jam:145: in project.find from module project C:/source/modular-boost/tools/build/src\build-system.jam:535: in load from module build-system C:\source\modular-boost\tools\build\src/kernel\modules.jam:289: in import from module modules C:\source\modular-boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build from module C:\source\modular-boost\boost-build.jam:17: in module scope from module

2 2

Correct Mutext Destroy Behaviour, Pthreads and Boost
by Robert Bell 01 Jun '15

01 Jun '15

If an object is implemented to support reference counting, and has an internal raw pthread mutex, the open group is pretty clear in the pthread_mutex_destroy doc on what different implementations must ensure (http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_dest…) Note the following statement at the bottom: "A mutex can be destroyed immediately after it is unlocked. For example, consider the following code:" obj_done(struct obj *op) { pthread_mutex_lock(&op->om); if (--op->refcnt == 0) { pthread_mutex_unlock(&op->om); (A) pthread_mutex_destroy(&op->om); (B) free(op); } else (C) pthread_mutex_unlock(&op->om); } In this case obj is reference counted and obj_done() is called whenever a reference to the object is dropped. Implementations are required to allow an object to be destroyed and freed and potentially unmapped (for example, lines A and B) immediately after the object is unlocked (line C)." On moving some of my underlying libraries to Boost, I took a look at Boost's Mutex object. The implementation of the Mutex object's destructor call does: ~mutex() { int const res = posix::pthread_mutex_destroy(&m); boost::ignore_unused(res); BOOST_ASSERT(!res); } My question centres on whether Boost's implementation violates the open group's requirement. The calls to posix::pthread_mutex_destroy (Boost's wrapper), usually perform a straight-through call to ::pthread_mutex_destroy, but it occurs inside the destructor, and so does this call occur "immediately after" an unlock by the group's definition? In straight pthreads, if I want to make sure I can rely on various implementations of the standard, I can simply do exactly what the open group says, unlock, and the next line destroy. But in the case of Boost, is it safe to do something like: mutex->unlock(); delete mutex_; One thing I did note of interest is that Apple's implementation seems to lock the mutex from within the destroy call, which is curious: int pthread_mutex_destroy(pthread_mutex_t *mutex) { int res; LOCK(mutex->lock); if (mutex->sig == _PTHREAD_MUTEX_SIG) { if (mutex->owner == (pthread_t)NULL && mutex->busy == (pthread_cond_t *)NULL) { mutex->sig = _PTHREAD_NO_SIG; res = ESUCCESS; } else res = EBUSY; } else res = EINVAL; UNLOCK(mutex->lock); return (res); } There seems, generally, to be a good deal of confusion surrounding when it is safe to destroy the resources associated with a mutex, and most people offer widely inaccurate comments based largely on opinion. My question points to whether code adjacency is a requirement of correct behaviour in some implementations, and if not, why not? If I have missed an obvious explanation somewhere, my apologies. I read through the different patterns of Boost threading listed in the documentation, but was not convinced the question was addressed. Thanks in advance…

4 5

Resources available for testing on 64-bit MSVC
by pfultz2 01 Jun '15

01 Jun '15

Hello, Recently, I have been working on adding MSVC support for the Fit library, and I have been fairly successful. Using the VMs at modern.ie, I was to able to get all the tests to pass on 32-bit Visual Studio 2015 RC. Unfortunately, a few tests fail on the 64-bit MSVC, and I have been unable to find a VM I can use to debug the problem. All the VMs at modern.ie are 32-bit, it seems. Does anyone know of resources available to test and debug libraries with 64-bit MSVC? Thanks, Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Resources-available-for-testing-on-64-bi… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[next gen future-promise] What to call the monadic return type?
by Niall Douglas 01 Jun '15

01 Jun '15

Dear list, As AFIO looks likely to be finally getting a community review soon, I've made a start on a final non-allocating constexpr-collapsing next generation future-promise such that the AFIO you review is "API final". You may remember my experimentations on those from: http://boost.2283326.n4.nabble.com/Non-allocating-future-promise-td466 8339.html. Essentially the win is that future-promise generates no code at all on recent C++ 11 compilers unless it has to [1], and when it does it generates an optimally minimal set with no memory allocation unless T does so. This should make these future-promises several orders of magnitude faster than the current ones in the C++ standard and solve their scalability problems for use with things like ASIO. They also have major wins for resumable functions which currently always construct a promise every resumable function entry - these next gen future-promises should completely vanish if the resumable function never suspends, saving a few hundred cycles each call. Anyway, my earlier experiments were all very promising, but they all had one big problem: the effect on compile time. My final design is therefore ridiculously simple: a future<T> can return only these options: * A T. * An error_code (i.e. non-type erased error, optimally lightweight) * An exception_ptr (i.e. type erased exception type, allocates memory, you should avoid this if you want performance) In other words, it's a fixed function monad where the expected return is T, and the unexpected return can be either exception_ptr or error_code. The next gen future provides Haskell type monadic operations similar to Boost.Thread + Boost.Expected, and thanks to the constexpr collapse this: future<int> test() { future<int> f(5); return f; } test().get(); ... turns into a "mov $5, %eax", so future<T> is now also a lightweight monadic return transport capable of being directly constructed. In case you might want to know why a monadic return transport might be so useful as to be a whole new design idiom for C++ 11, try reading https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:S tronglyconsiderusingconstexprsemanticwrappertransporttypestoreturnstat esfromfunctions. However, future<T> doesn't seem named very "monadic", so I am inclined to turn future<T> into a subclass of a type better named. Options are: * result<T> * maybe<T> Or anything else you guys can think of? future<T> is then a very simple subclass of the monadic implementation type, and is simply some type sugar for promise<T> to use to construct a future<T>. Let the bike shedding begin! And my thanks in advance. Niall [1]: Compiler optimiser bugs notwithstanding. Currently only very recent GCCs get this pattern right. clang isn't bad and spills a dozen or so completely unnecessary opcodes, and I'll follow up with Chandler with some bug reports to get clang fixed. Poor old MSVC spits out about 3000 lines of assembler, it can't do constexpr folding at all yet. -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

16 122

RFC: Separating Boost.Python from Boost
by Stefan Seefeld 31 May '15

31 May '15

Hello, as I have mentioned here before, I would very much like to continue the modularization effort, by fully separating the Boost.Python project from the rest of Boost. For avoidance of doubt: my intent is not to remove Boost.Python out of the Boost organization. Rather, I would like to separate the build and release processes. For the sake of keeping the discussion focused, I would like to avoid getting into too many (technical) details (there already is a related discussion on the Boost.Build list). Rather, I would like to know whether people here (and Boost.Python users in particular) have any particular thoughts about this proposal. Any strong reasons not to move forward with this ? Things to consider while doing it ? Etc. (My hope is that if the operation succeeds, other Boost libraries may want to do the same, which would help Boost in the long term to become more manageable.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

18 62

Thoughts on Trac wiki page commenting facility
by Niall Douglas 31 May '15

31 May '15

Something Robert raised during the meetings at C++ Now was why can't people comment on Boost's Trac wiki pages? The simple answer is because Trac doesn't allow it and hasn't got to implementing it in many years (http://trac.edgewall.org/ticket/11676) despite it being technically as simple as appending a ticket's comments to a wiki page, so I spent some time researching what options are available: 1. https://trac-hacks.org/wiki/WikiCommentsPlugin This works by inserting the comments directly into the article text. Pros: The comments are the document. This lets the page author fix the problem and delete the comment where that is appropriate. Cons: You need a trac login and editing privs to comment, which until a Trac 1.0 upgrade remains manually awarded by a Boost admin. No preview, so you need to know Trac wiki markup. 2. Disqus https://disqus.com/ This is the grand daddy of free commenting services. This works by you inserting some Javascript into the page where you want the comments to appear. AJAX does the rest. This could very easily patched into Trac for every wiki page by tweaking its template as per the instructions at http://trac.edgewall.org/wiki/TracInterfaceCustomization. Pros: Very well understood by users, in fact by everyone. Built in excellent spam protection. Nice UI. Just works. I also have a ton of ready to go infrastructure from nedprod.com for Disqus, so it's really very little effort for me to integrate this. Cons: They own all your data. They serve adverts in the comment stream, though apparently you can now opt out. They track user visits and sell the information, so AdBlock and Ghostery default block Disqus. Comment load times can be very slow. Comments aren't indexed by Google, and this may decrease the value of the system. 3. Keep looking Niall! Like none of the above? There are open source clones of Disqus you can host on your own infrastructure, but I have no experience with any of the those. If the community really doesn't like either of the two above, I guess I can keep looking. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 5

[locale] Build failure on develop
by Marcel Raad 30 May '15

30 May '15

Hi, since Tuesday, all Boost.Locale tests have been failing on all compilers: http://www.boost.org/development/tests/dev elop/developer/locale.html The MSVC results only mention an expected has_iconv.cpp build failure and it seems all other results only say "Error extracting file: No matching files were found." I tested on my local machine with MSVC 14 RC and the library wouldn't compile because of a missing "#include <map>": https://github.com/boostorg/locale/pull/8

1 0

[bind] Placeholders suggestion, std and boost
by Edward Diener 30 May '15

30 May '15

I realize that changing boost::bind so by default that placeholders of the form _n needing some sort of namespace in front of it will break plenty of code, so I am not suggesting doing that. What I would like to suggest is a Boost.bind macro, which when used before including <boost/bind>, would put the boost::bind placeholders of the form _n in a boost::placeholders namespace. The reason for this suggestion is so that boost::bind and std::bind can be similar syntactically enough so that one could choose one or the other depending on compiler support. Since in the C++ std the placeholders are in the std::placeholders namespace, having a means to have the boost::bind placeholders in the boost::placeholders namespace would be a means to that end.

5 16

[type_traits] Big changes in develop
by John Maddock 30 May '15

30 May '15

A heads up that the "Version2" rewrite of type traits is now in develop. There's still lots to do - more PR's will happen over the coming weeks to remove obsoleted code from other libraries (and quash the warnings that they'd otherwise generate). The docs also need a major update. In the mean time please do shout loudly if there are any regressions caused by this change. Thanks, John.

8 26

[test] Fwd: [Boost-testing] All test runners (windows and linux) crashing
by Rene Rivera 29 May '15

29 May '15

Boost Test developers please fix ASAP. ---------- Forwarded message ---------- From: Tom Kent <lists(a)teeks99.com> Date: Thu, May 28, 2015 at 8:26 PM Subject: Re: [Boost-testing] All test runners (windows and linux) crashing To: Running Boost regression tests <boost-testing(a)lists.boost.org>, Boost Developers List <boost(a)lists.boost.org> On Thu, May 28, 2015 at 6:24 PM, Tom Kent <lists(a)teeks99.com> wrote: > All my test runners are quickly crashing during each run...here's the end > of the output in my results/bjam.log file: > > boost-test(RUN) "test/doc_boost_test_macro1" : > "libs/test/doc/examples/boost_test_macro1.cpp" > boost-test(RUN_FAIL) "test/doc_boost_test_macro2" : > "libs/test/doc/examples/boost_test_macro2.cpp" > boost-test(RUN_FAIL) "test/doc_boost_test_macro3" : > "libs/test/doc/examples/boost_test_macro3.cpp" > error: at D:/t08/c/boost_bb/src/kernel\modules.jam:107 > error: Unable to find file or target named > error: '../doc/examples/test_float_01.cpp' > error: referred to from project at > error: '../libs/test/test' > > Any thoughts? > Tom > I should have specified, that is on the develop branch. Master seems fine. _______________________________________________ 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

2 2

All test runners (windows and linux) crashing
by Tom Kent 29 May '15

29 May '15

All my test runners are quickly crashing during each run...here's the end of the output in my results/bjam.log file: boost-test(RUN) "test/doc_boost_test_macro1" : "libs/test/doc/examples/boost_test_macro1.cpp" boost-test(RUN_FAIL) "test/doc_boost_test_macro2" : "libs/test/doc/examples/boost_test_macro2.cpp" boost-test(RUN_FAIL) "test/doc_boost_test_macro3" : "libs/test/doc/examples/boost_test_macro3.cpp" error: at D:/t08/c/boost_bb/src/kernel\modules.jam:107 error: Unable to find file or target named error: '../doc/examples/test_float_01.cpp' error: referred to from project at error: '../libs/test/test' Any thoughts? Tom

1 1

[type_traits][units] migrating from ice_and
by Jürgen Hunold 28 May '15

28 May '15

Hi! I've noticed that boost/type_traits/detail/ice_or.hpp and boost/type_traits/detail/ice_and.hpp have been deprecated. Both headers are used as an implementation detail in boost/units/scaled_base_unit.hpp, now resulting in lots of warnings: In file included from .../boost/units/scaled_base_unit.hpp:20: .../boost/type_traits/detail/ice_or.hpp:17:10: warning: NOTE: Use of this header (ice_or.hpp) is deprecated [-W#pragma-messages] # pragma message("NOTE: Use of this header (ice_or.hpp) is deprecated") Question: Is there a known migration path from type_traits to what? MPL? Or am I better off copying both files to Boost.Units and be done? 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

3 4

[testing][teeks] MSVC-14 errors about MSPDB140.DLL
by Andrey Semashev 27 May '15

27 May '15

Hi, All tests for Boost.Log (and I suspect any other built libraries) on MSVC-14 are failing because of this error: LINK : fatal error LNK1101: incorrect MSPDB140.DLL version; recheck installation of this product See here for example: http://www.boost.org/development/tests/develop/developer/output/teeks99-08f… Could this be fixed?

4 7

[typeof] Weird VC++ compiler bug
by Edward Diener 27 May '15

27 May '15

I discovered a strange VC++ bug using Boost.typeof. I am not posting this to rag VC++ but wondering if there is some known workaround in Boost or in Boost.config. #include <boost/typeof/typeof.hpp> template <class T> struct dereference { typedef BOOST_TYPEOF_TPL(*T()) type; }; int main() { } Compiling this with VC++12 gives: test_vc_type_of_indirection.cpp(6) : error C2100: illegal indirection test_vc_type_of_indirection.cpp(7) : see reference to class template instantiation 'dereference<T>' being compiled Notice that I am not even instantiating 'dereference'. But if I write: #include <boost/typeof/typeof.hpp> template <class T> struct dereference { void afunction() { typedef BOOST_TYPEOF_TPL(*T()) type; } }; int main() { } all is well, for all the good it does me. BOOST_TYPEOF_TPL(*T()) expands to: typename boost::type_of::msvc_typeid_wrapper<sizeof(*boost::type_of::encode_start(*T()))>::type and if I substitute this directly the same results occur. I can report this to the VC++ bug tracker but wanted to see if this is a known problem with VC++ in Boost, some weird error for which maybe Boost has some workaround syntax.

6 13

Fwd: Binary Region Differentials
by Kenneth Adam Miller 27 May '15

27 May '15

Suppose I have a rather huge binary region. Transferring it by any means is an expensive operation. But changes to it will only be some fraction at worst case as large as the binary region itself, but in practice will typically be regional byte blobs, mostly not more than a single kilobyte long.. Is there any data structure that already handles this, where I could say, have every instance start off from the original binary region, and calculate what any other instance of that data structure has by "applicating the deltas"?

3 4

svn.boost.org SSL cert errro
by Olaf van der Spek 26 May '15

26 May '15

Hi, The certificatie of svn.boost.org has expired (two weeks ago).. -- Olaf

10 19

[branch master] add library to regression tests
by Oliver Kowalke 26 May '15

26 May '15

Hello, could you please add boost.coroutine2 to the regression tests of branch master?! best regards, Oliver

1 0

Aho - Corasick String Search (for searching multiple patterns) Interface
by meghana madhyastha 26 May '15

26 May '15

Hi, In some of my previous mails I had suggested that the Rabin Karp and Aho - Corasick string search algorithms be implemented as a part of the Boost algorithm library. This is primarily because these algorithms perform well for searching for multiple patterns. The Aho - Corasick algorithm works by building a trie (a tree with each node corresponding to an ASCII character) of the patterns strings and traversing the trie to search for the pattern in a given text. Additionally, the Aho - Corasick introduced the concept of "failure pointer/failure node" which is the node to be traversed when there is a mismatch. For more information: http://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_string_matching_algorithm The interface I propose is as follows. 1. The input of the patterns should be strings within a *container*. This is because these algorithms are primarily used for multiple pattern searching. The user can input pointers/iterators to the first and last pattern . The final output which is returned is a container with each pattern and a iterator/pointer to their occurrences (There are multiple patterns so just returning an iterator/pointer to where the patterns first occurs in the pattern will not suffice). 2. Just like the previous string searching algorithms that have been implemented in Boost, there can be an object based interface as well as a procedure based interface. In the object based interface, the trie is constructed and the failure nodes are computed in the constructor (while creating the object). The user can then search the text using the operator(). template <typename patIter> class aho_corasick { public: aho_corasick(patIter first, patIter last): pat_first(first), pat_last(last), head(std::shared_ptr<trie_node>(new trie_node)) { //first and last are pointers/iterators to the first and last patterns in the container gotoFn(head); failureFn(head); } ~aho_corasick () {}; template <typename corpusIter> corpusIter operator ()(corpusIter corpus_first, corpusIter corpus_last) //Note: using the same notation as used in the other search algorithms. Corpus- refers to the text to be searched. I've implemented this and would like to get feedback/suggestions on the code as well as the interface. Where should I put up the code for it to be reviewed ? Thanks, Meghana

1 0

boost [vmd]: configuration issue in Jamfile.v2 for Oracle Solaris Studio compiler
by Aparna Kumta 26 May '15

26 May '15

I am looking at my test run for vmd in develop branch. http://www.boost.org/development/tests/develop/developer/vmd.html under SunOS. My tests are run with cxxflags="-compat=5 -library=stlport4" as configured in user-config.jam An example of a test, http://www.boost.org/development/tests/develop/developer/output/oracle-spar… The test fails as follows: "CC" -std=c++0x -std=c++11 -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -c -o "/export/home/sstrunk-tester/boost_regression/boost_sparc-S2_stlport4/results/boost/bin.v2/libs/vmd/test/test_after_identifier_elem.test/sun-stlport4/release/threading-multi/test_after_identifier_elem.o" "../libs/vmd/test/test_after_identifier_elem.cpp" CC: -compat=5 can not be used with -std CC: -library=stlport4 cannot be used with -std=c++11 If I compile the test manually without '-std=c++0x -std=c++11', the test compiles OK. %CC -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -m64 -KPIC -DBOOST_AL0%L_NO_LIB=1 -DNDEBUG -I.. -c -o ./test_after_identifier_elem.o ../libs/vmd/test/test_after_identifier_elem.cpp % It looks like boost_root/libs/vmd/test/Jamfile.v2 needs to be modified for this compiler. Any ideas on how this can be done? Thanks, Aparna

2 3

boost::bind C2664 error with two non-const references
by Nicolas FRANCOIS 25 May '15

25 May '15

Hi, Relatively to this thread http://lists.boost.org/Archives/boost/2015/03/220930.php and this correcting commit 42b5cef177603328ead66bc6a98a3067aebc433d, I still have errors using boost::bind. #include <boost/bind.hpp> #include <boost/function.hpp> struct A { void f(int&, std::vector<int*>&); }; int main(){ A a; auto f = boost::bind(&A:f, &a, _1, _2); } results in error C2664: cannot convert from 'const std::vector<int*> &' to 'std::vector<int*> &' Defining BOOST_NO_CXX11_RVALUE_REFERENCES solves the issue for now. Nicolas FRANCOIS Software Department L-ACOUSTICS Tel : +33 (0) 1 69 63 23 90 Fax : +33 (0) 1 69 63 69 64 www.l-acoustics.com<http://www.l-acoustics.com/> Please consider the environment before printing this email.

2 7

Environment Variables Library?
by Michael Ainsworth 24 May '15

24 May '15

StackOverflow regarding the (non) standardisation of the "setenv" function, does Boost provide a library to interact with environment variables? http://stackoverflow.com/questions/30292642/c-standard-library-stdsetenv-vs… Michael

10 34

[testing][CrystaX.NET] Missing header
by Andrey Semashev 23 May '15

23 May '15

Hi, Many of the CrystaX.NET testers fail to compile tests because of this error: fatal error: crystax/google/sys/select.h: No such file or directory See here for example: http://www.boost.org/development/tests/develop/developer/CrystaX-NET-apilev… Could this be fixed?

2 1

boostdep documentation?
by Robert Ramey 22 May '15

22 May '15

I am interesting in taking a look at boostdep. I see the code in tools/... but I don't see any documentation. Is there any? will there be in the future? Robert Ramey

2 3

Re: [boost] [Better Enums] Interest in/feedback on C++11 enums library
by Anton Bachin 22 May '15

22 May '15

I've been keeping away because I am doing a ton of work on the library, and I don't want to attract too much attention until the work is ready, since there are lots of changes. But, I think I should reply, and I will also give a brief update of the progress at the end of the message. > I suspect this code: > > Depth depth = default_<Depth>(); > > could be made to look like this: > > Depth depth = _default; > > > ie all enums have a constructor that takes a default_t type. The > constructor then calls default_<T>(). > Or something like that. And then change the names to get > > Depth depth = default_; // calls default_impl<T>(); That’s a good idea. I hadn't thought of such a constructor. I will try it out, but I am not sure that it would belong directly in the library, if that's what you mean. It's not clear where one should stop. Should there also be an "invalid" constructor for projects that have such a notion? Are there other special values we can't predict? Perhaps this could be achieved with some kind of extension facility. I will eventually be adding either support for subclassing, or extra macros, or some kind of template-based extensibility. To the other commenters: thanks :) As for progress: there are substantial improvements. - The entire interface is now constexpr, including string functions and iterators. - I ported the interface to C++98, though it still requires __VA_ARGS__. This makes the topic of this message inaccurate. Should I start a new thread for the new version when it's up? - The C++98 conversion means that, in theory, the library should work on MSVC down to VS2005. I will be testing that when I get my new notebook in a few days. If successful, Better Enums will be compatible with the 3 major compiler families. - Eliminated all weak symbols, leaving only standard C++. Some may be brought back later for optimization, but they are no longer required. - When compiling for C++11, there are no more implicit conversions to integers. - The library is now a single header file, containing both the C++11 version and the C++98 port, and all helper macros. - The documentation is getting a major improvement, so please don't look now. The all-constexpr version is unfortunately noticeably slower to compile. The performance test that was previously two times faster than including iostream is now twice as slow, but I can mitigate this with some combination of opt-in and optimization. Anton

1 0

[build][test][gsoc] question about compiling tests with multiple compile params using b2
by Damian Vicino 22 May '15

22 May '15

Hi, I’m working in the safe_float library for the GSOC. For testing I’m using the boost.test library and for building I’m using b2. The implementation have several pieces that are implemented in two flavours, one for compilers supporting FLOAT_ENV and one for those not supporting it. (this is a C++11 feature missed in at least clang and gcc compilers) Right now, the implementation is selected with an #ifdef and I #define them with a -D parameter. My config file for test is: using testing ; lib boost_unit_test_framework ; unit-test test : main-test.cpp [ glob *_test.cpp ] boost_unit_test_framework ; I guess I can generate 2 different executables using 2 targets, duplicating last line and adding something to tell it to pass -DFENV_AVAILABLE, but I couldn’t find how to do that. Having 2 executables for the tests and running them both will provide testing for both compilation paths (when using a compiler supporting FENV). Also, I’m wondering if B2 has the inteligence detect and pass a parameter when using a compiler supporting FENV. Is there any common approach for these situations where conditionally compiling based on a c++ feature support? In the case a Boost.Build needs to define a test for detecting if the compiler supports the feature (autoconf-like) it can be tested compiling a one-liner file: test.fenv.cpp #pragma STDC FENV_ACCESS ON When compiled: clang++ -c test.fenv.cpp test.clang.cpp:1:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] #pragma STDC FENV_ACCESS ON The warning means the feature is not supported. Thanks for any guidance in this area, I’m pretty newbie with the b2 system. Best regards, Damian

2 1

[Better Enums] Interest in/feedback on C++11 enums library
by Anton Bachin 21 May '15

21 May '15

Hello, I’ve just released an enum library that takes advantage of constexpr functions and literal types to provide a nice declaration syntax and decent feature set: https://github.com/aantron/better-enums <https://github.com/aantron/better-enums> I’d like to get feedback on it from the experienced developers here at Boost. Is this approach useful? Are any major features missing? Would this be an interesting candidate for enums in Boost? I am very willing to do further development on this project. The library's basic features are string conversions, value and name listing, some type safety, and a declaration syntax that is based on built-in enums and is easy to learn and use. A much more "advanced” feature is that the generated class is a literal type, and almost everything is constexpr. Here is a simple example, that takes advantage of this, of a compile-time encoding of project policy: https://github.com/aantron/better-enums/blob/master/example/6-traits.cc <https://github.com/aantron/better-enums/blob/master/example/6-traits.cc> . Once I make the iterators constexpr as well, by providing a way to increment them other than mutation (++), it will be easy to write rather involved compile-time algorithms that process Better Enums declarations. Here is an example of a whole bunch of simple compile-time processing already possible: https://github.com/aantron/better-enums/blob/master/example/4-constexpr.cc <https://github.com/aantron/better-enums/blob/master/example/4-constexpr.cc> . Some of that could be useful when C++ declarations are generated by script. The library is all standard C++11 (to the best of my knowledge), except for the usage of weak symbols for some generated constexpr static arrays. I have tested it successfully on clang and g++, but I would need help getting access to more compilers. I believe weak symbols are not a problem for MSVC, but I still don’t believe the library will compile on MSVC since I don’t think MSVC supports enough of C++11 yet. Performance is what I would call excellent. I compared compilation times of these two files to each other: https://github.com/aantron/better-enums/blob/master/test/performance/4-decl… <https://github.com/aantron/better-enums/blob/master/test/performance/4-decl…> https://github.com/aantron/better-enums/blob/master/test/performance/5-iost… <https://github.com/aantron/better-enums/blob/master/test/performance/5-iost…> The first file includes enum.h and declares a bunch of enums, and the second merely includes iostream. On my machine, clang compiled all those enums in about half the time it took to process iostream. g++ was faster on iostream, but only slightly. Using a lot of compile-time expressions would have additional cost, but it has been too small to measure for “realistic” examples from my own usage. I haven’t yet made an example that repeatedly deals with a very large enum at compile time to properly measure that impact. I’ve also explored an alternative interface where the constexpr properties provided by the library are in a traits class parametrized by a normal C++11 enum class, but the interface seemed too verbose. There is also a bitset type that has a very slightly nicer interface than std::bitset for usage with enums, but I didn’t think the improvement was worth the user’s learning effort. I can put these in branches if there is interest, however. Please let me know what you think. Best, Anton

5 4

[BOOST_FOREACH] Problem to iterate on a non-copyable container...
by nico 21 May '15

21 May '15

I'm not sure of the title, because I'm not sure the issue comes from the "copyablility" of my container. I tryied quite everything but I can't get rid of this error. Here is a simplified version of my code (please do not challenge the class design, I really would like to keep the end-used syntax in the BOOST_FOREACH): template <typename T> class MyContainer { public: typedef typename std::vector<T>::iterator iterator; typedef typename std::vector<T>::const_iterator const_iterator; MyContainer(std::vector<T>& vec, boost::mutex& mutex) : m_vector(vec), m_lock(mutex) { } iterator begin() { return m_vector.begin(); } const_iterator begin() const { return m_vector.begin(); } iterator end() { return m_vector.end(); } const_iterator end() const { return m_vector.end(); } private: std::vector<T>& m_vector; boost::lock_guard<boost::mutex> m_lock; }; template <typename T> struct GetContainer { GetContainer(std::vector<T>& vec, boost::mutex& mutex) : m_vector(vec), m_mutex(mutex) { } MyContainer<T> Get() { return MyContainer<T>(m_vector, m_mutex); } std::vector<T>& m_vector; boost::mutex& m_mutex; }; int main() { std::vector<int> v; v.push_back(1); v.push_back(2); boost::mutex m; GetContainer<int> getter(v, m); BOOST_FOREACH(int i, getter.Get()) { std::cout << i << std::endl; } return 0; } The compiler complains about not having a copy constructor for MyContainer<int>::MyContainer(const MyContainer<int>&) I also have : error: no matching function for call to ‘MyContainer<int>::MyContainer(boost::foreach_detail_::rvalue_probe<const MyContainer<int> >::value_type)’ I follow the extensibility tips: http://www.boost.org/doc/libs/1_58_0/doc/html/foreach/extensibility.html#fo… But, making MyContainer<T> : private boost::noncopyable doesn't solve the issue. Nor defining the function boost_foreach_is_noncopyable or specializing the template struct is_noncopyable for MyContainer<int> (in fact, how would I specialize this template for a template type ?) Last "tip": If I remove the mutex and the lock from everywhere (I just pass the vector to GetContainer and to MyContainer<T>, it works. But it doesn't work if I make MyContainer<T> : private boost::noncopyable (I expected it should, so I'm not sure my problem is with BOOST_FOREACH, but maybe because I return a copy of MyContainer with my getter ?) I thank you if you read me until here, and thanks in advance for help.

3 4

What does "xml this : this.qbk" do?
by Peter Dimov 21 May '15

21 May '15

Documentation Jamfiles often contain a line like xml core : core.qbk ; What does this line do? Is "xml" a rule? I haven't been able to find it anywhere.

2 1

Questions about upcoming review of Boost.AFIO
by Niall Douglas 21 May '15

21 May '15

Dear list, Ahmed has volunteered to review manage AFIO (thanks Ahmed!), however I wanted to get the list's feedback on some things first. 1. After collecting feedback at C++ Now from members of WG21 on the shape and preferred future of a race free Filesystem TS, the next iteration of AFIO will have a radically different API consisting of the form: std::vector<afio::future<T>> afio::batch(...) afio::future<T> afio::async_io_handle::operation(inputs) noexcept(is_nothrow_move_constructible<T>) T afio::io_handle::operation(inputs) T afio::io_handle::operation(error_code &ec, inputs) The internal engine is the same very well tested code, just the API is very different from before. The current API was forced by VS2010's limitations and the lack of constexpr in MSVC - now VS2015 RTM has C++ 11 constexpr, I can adopt the custom future based API I always originally wanted. This new API will require C++ 14 in the compiler. Question: Given the API will so radically change, is now the time for a community review? Do note that APIBind allows me to support the existing API and the new API concurrently without issue. 2. AFIO requires APIBind which is a separate library. APIBind is not yet in the review queue and it is pending me writing up its documentation and a more useful unit test suite. Is this a problem? Do note that you the user of AFIO will never need to know about APIBind, it is entirely an internal implementation detail. Comments appreciated. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

8 10

More cool free github tooling: https://reviewable.io/
by Niall Douglas 21 May '15

21 May '15

Dear list, I'm not sure about other libraries, but in Boost.Thread Vicente the primary maintainer does the lion's share of dealing with pull requests but he occasionally needs someone else to review a patchset or a pull request before it can be merged. Github's facilities for this are okay - you can comment per line of a pull request, and overall. It works, though one wishes for something more gerrit like. So enter a new free tool with github integration: https://reviewable.io/. One click install into your github project. You now gain an alternative UI for pull requests, one which is much better than the default Github UI, specifically: * Per file review gating like gerrit * Can publish a group of per-line comments as a single thing (and just one email notification) * Doesn't hide deleted change history * Diffs are much better calculated and presented I've turned it on for AFIO. We'll see how it goes. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Some statistics about the C++ 11/14 mandatory Boost libraries
by Niall Douglas 21 May '15

21 May '15

Tomorrow at 11am after Eric's talk I'll be presenting at C++ Now a review of the upcoming C++ 11/14 mandatory Boost libraries. I looked at fifteen libraries and decided ten were worth further investigation. I'm sure you all remember my colour coded ranking of those ten libraries by "nearness" to entering Boost: https://goo.gl/6l1KiH I sadly only have time to review four of those libraries during my talk, but one (APIBind) enables an alternative Boost 2.0 approach and I will spend 45 mins on that library alone. And here is my alternative Boost 2.0 vision: Boost 2.0 is a alternative distro of modular standalone Boost libraries which can be each downloaded separately. Each has contemporary per commit CI testing and is nightly dashboarded by quality score by a web service under the 19 quality score headings listed at https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook (still unfinished, but nearly there). APIBind allows the library end user to dependency inject what dependencies that library uses. This allows a Boost library, in a single codebase, to be part of both the monolithic Boost 1.x distro and to be modular and standalone and part of the Boost 2.x distro. Motivated library maintainers port their Boost 1.x library to the APIBind platform, and therefore can be part of both 1.x and 2.x distros if they want. Those libraries not ported to APIBind remain in the 1.x distro, which I would assume will gradually fade into obsolescence over time. This makes sense, as if a maintainer is not motivated to do the port then it seems proper that library should gracefully deprecate. There is some empirical data supporting the inevitability of this alternative vision of Boost 2.0. Of the ten libraries I examined in any detail: * Just 1.5 libraries have any dependencies on Boost headers at all (the 0.5 is because that library is currently removing its Boost dependencies). * Just 3 libraries can use Boost.Test. * Just 3 libraries use Boost Docs. * Just 2 libraries require using Boost.Build. The rest are header only, or use cmake. * Just 6 libraries use Travis/Appveyor for free CI testing on Linux, OS X and Windows. * Just 3 libraries use valgrind as part of their unit testing (two are mine!). * Just 3 libraries use coveralls for coverage reporting (two are mine!). Personally speaking, I think the new library authors are overwhelmingly voting for a complete break with Boost 1.x. It makes no sense to bundle these new libraries into a 1.x monolithic distro when they have no dependencies on Boost. I believe now is the time we start establishing the infrastructure to shape the new Boost 2.0 distro instead of wasting resources on trying to refactor the 1.x distro. APIBind is there for maintainers wanting to be part of both distros. Let's make a clean break. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

28 133

Deprecation Policy
by Rob Stewart 21 May '15

21 May '15

Some Boost libraries are unmaintained, some are under-maintained, and others have been replaced by newer libraries or by the Standard Library. Boost needs to decide whether to deprecate such libraries, and if so, how and when to do it. Please consider my initial thoughts below and provide ideas on such a policy. I will try to capture your ideas and create a policy statement for later review. It would seem obvious that unmaintained libraries should be deprecated, but a library that works, even if it has some known bugs, doesn't grow worse over time. Thus, if an unmaintained library was included in one Boost release, continuing to include it is no worse than before. That implies that deprecating Unmaintained libraries is not a given. Another issue is deciding when a library is unmaintained. Boost prefers that library authors and maintainers seek a replacement when no longer able to provide maintenance. Unfortunately, that doesn't always happen. Thus, establishing criteria by which to judge a library as unmaintained is warranted. Many continue to use C++03 and benefit from the presence of libraries that only support that language. I think it a non-starter to suggest that a library is unmaintained, or under-maintained, because it hasn't been updated to use C++11/14. Indeed, a replacement library may be the better way forward, while the old library might remain in Boost releases. Some have suggested that libraries with Standard Library equivalents be considered deprecated. Note that such libraries provide equivalent or similar functionality for older compilers, so I think that they should be treated the same as C++03-only libraries. Libraries that have superior replacements in Boost releases seem like obvious candidates for deprecation. There is precedent for that: Boost.Signals was deprecated in favor of Boost.Signals2. There are some likely libraries in this category, such as Boost.Lambda. Once we reach consensus on how to identify libraries to deprecate, we then must decide on the process. How long should a deprecated library be released before it is removed from Boost releases? How do we mark deprecated libraries? What do we do with deprecated libraries that have been removed from Boost releases? ___ Rob (Sent from my portable computation engine)

12 33

[preprocessor] Link to Boostpro site for introduction to preprocessor metaprogramming
by Edward Diener 20 May '15

20 May '15

The preprocessor documentation has a link to the Boostpro site which had an html version of the Appendix A of "C++ Template Metaprogramming" by Abrahams and Gurtovoy. Appendix A is "An Introduction to Preprocessor Metaprogramming", which is all about Boost PP. Alas Boostpro is no more and the link in the preprocessor documentation goes nowhere. I can remove the link and any notice of the introduction. But If either David Abrahams or Aleksey Gurtovoy are still around it would be nice to get the html pages which existed before and incorporate them into the Boost PP docs. Does anyone know how to contact either of them ? I can try their addresses in maintainers.txt but I do not want to directly encroach on their privacy if there is a better way.

2 4

Interest in non-intrusive signal/slot lib?
by Emil Dotchevski 20 May '15

20 May '15

Hello, I realize that Boost has Signals library already, but I've implemented a non-intrusive one which approaches the problem differently, and I'm pretty sure that there is no overlap between the two. It turned out more generic than I originally anticipated, so I thought I'd ask if others would find it useful as well. Specifically I was motivated by wanting to use Qt without MOCing. I asked the Qt community if that was possible which generated several rather annoyed negative responses. :) The issue is that while in Qt it's possible to use any function as a Slot, to define a new Qt signal for an existing Qt type one needs to derive from the Qt type, define the signal (as a member function) and do the MOC dance -- which I wanted to avoid. The result is a small, non-intrusive signals/slots library that allows objects of any type to be used as signal emitters, e.g. one of the included examples shows how signals can be emitted by a Windows HWND object. Documentation and source code released under the Boost license can be found here: http://www.revergestudios.com/boost-synapse/. Thanks, Emil P.S. Thanks to Peter Dimov for his feedback and for coming up with the name Synapse. :)

9 48

Version mismatch on develop
by Peter Dimov 20 May '15

20 May '15

On the current develop, autolink wants to link to (for instance) libboost_filesystem-vc80-mt-s-1_59.lib, but b2 builds libboost_filesystem-vc80-mt-s-1_58.lib. That's because BOOST_VERSION has been updated to 1.59 in boost/version.hpp, but is still 1.58 in Jamroot.

2 1

[type_traits] A bug in has_nothrow_default_constructor
by Andrzej Krzemienski 20 May '15

20 May '15

Hi All, I have submitted a new ticket: https://svn.boost.org/trac/boost/ticket/11324 Given the information floating around that Boost.TypeTraits are unmaintained and that they are to be replaced with the rewrite, is there any chance that this is fixed, or at least the test case added to regression matrix? BTW, does type_traits v2 handle this case correctly? Regards, &rzej

2 2

[Testing] Android clang tests
by John Maddock 20 May '15

20 May '15

Since all the Android/clang tests which use PCH are failing, can we either: * Change the build options to disable PCH, or better, * Fix the clang toolset? Someone who understands clang on Android would have to do the latter. See http://www.boost.org/development/tests/develop/developer/output/CrystaX-NET… for an example fail. Many thanks, John.

3 4

crash in boost/date_time/microsec_time_clock.hpp:70 v1.55
by George Georgiev 20 May '15

20 May '15

Hi, I am having crash in in local_time () at boost155_lin32_gcc480//include/boost/date_time/microsec_time_clock.hpp:70 I can call this in isolation and there is no issues, but in the production calls it crashes 100% reproducible with Program terminated with signal SIGABRT, Aborted. The only difference I could think about it is that the call is made from a dynamically loaded library. Is there any known issue about this? Thanks, George

4 3

Getting a trac id
by Steven Ross 19 May '15

19 May '15

I have a bug filed against my library, but with no trac ID I can't modify the bug. How do I get a trac ID?

2 1

RemoteCall framework for RPC
by Alex Marmer 19 May '15

19 May '15

Hello, I created a C++ framework RemoteCall which allows to use RPC the same way as local C++ calls are used. For declaration, implementation and call used macros: DECLARE_REMOTE, IMPLEMENT_REMOTE, CALL_REMOTE.Return and parameters (In and In/Out) can be any type except pointers. For instance: std::tuple<in, bool> DECLARE_REMOTE(Test)(std::vector<std::string>& vInOut, const std::wstring& sIn). Implementation is on https://github.com/amarmer/RemoteCall Would it be useful to add this framework in Boost? Sincerely,Alex

4 8

[all][testing] Regression summary upgrades
by Adam Wulkiewicz 18 May '15

18 May '15

Hi, Recently the regression summary was upgraded. The cells corresponding to the failing tests can have names comp, link, run or fail. This way we can see what's the nature of the failure without going into details. See, e.g. the tests for Math: http://www.boost.org/development/tests/develop/developer/math.html The last category of failures (generic "fail") is for the others or unknown. Currently the "Lib" errors are falling into this category. There are some in Math, e.g.: http://www.boost.org/development/tests/develop/developer/output/CrystaX-NET… So we could mark them explicitly as "lib" failures and then the other/unknown failures could be marked as "unkn" or left as it is now - "fail". This has sense if there can be other "types" of failures, e.g. caused by some error in the testing scripts, Build or Regression, for which the reason is somehow unknown. Though I haven't seen them. I propose to go further with this and to mark the compilation failures for which we know the reason of the failure in a special way: - "file" - file too big (reported on Windows, e.g. http://www.boost.org/development/tests/develop/developer/output/MinGW-w64-4…) - "time" - time limit exceeded (e.g. http://www.boost.org/development/tests/develop/developer/output/teeks99-03b…) I saw them in many libraries and I think it would be very useful for libraries having many tests like Math or Geometry. The other types of failures I could think of aren't that important for me personally but maybe someone could appreciate them, e.g. the compilers developers: - "ierr" or "cerr" - internal compiler error or segmentation fault during compilation (e.g. http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_… or http://www.boost.org/development/tests/develop/developer/output/teeks99-03h…) - "segf" - segmentation fault during run (http://www.boost.org/development/tests/develop/developer/output/BenPope%20x…) Furthermore I propose to use various colors for different failure reasons. You can see the examples here: https://github.com/awulkiew/summary-enhancer https://github.com/awulkiew/summary-enhancer/tree/master/example/pages Of course the colors could be changed. We should be able to modify them in the master.css file. In the examples above they are varying much to make a clear distinction between them. But if you like the yelow collor then all of the new failures could be yelowish with a slight accent of another color, e.g. compilation errors could be yellow with orange accent and "time"/"file" errors with green accent. Regards, Adam

11 27

Spirit 3.0.0
by Joel de Guzman 18 May '15

18 May '15

Hello! C++ Now 2015. Today is the official release of Spirit X3, aka Spirit 3.0.0. X3 will be in beta, coexisting side by side with Qi, Karma, Lex and Classic. If you are a Qi user. The best place to start are the examples, especially rexpr and x3 fun. Remember to use a compiler with c++14 capabilities: clang 3.4 or greater gcc 4.9 or greater Follow this link for more: http://boost-spirit.com/home/2015/05/16/spirit-3-0-0/ Cheers! -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/

4 5

[type_traits] Time to upgrade to "version 2" ?
by John Maddock 17 May '15

17 May '15

Now that the release is out it's decision time: I'd like to merge the "Version2" branch of type_traits to develop, it passes all the tests, and I've been using it exclusively for testing and development locally for a few months now without issues. But.... it's a big change with the potential to break a lot of folks stuff if things go wrong given that this is such a core component. To recap the main advantages are: * Removed all the redundant cruft that's no longer required for old/broken compilers we don't support anymore anyway. * Very nearly dependency free (other than Config), there's just comon_type which still has dependencies elsewhere - and even that disappears for a C++11 compiler. * Much cleaner, easier to understand code, now that the horrid obfuscating macros introduced by MPL have gone. * Fewer template instantiations than before as much of the indirection / forwarding templates have been removed. * As a result code using these headers should be somewhat faster to compile - both with fewer template instantiations, and a much lighter #include load. Note that as a result of this change, a number of undocumented headers which were none the less being used in Boost have been deprecated. The headers still exist, but warn loud and clear about their deprecated status, so folks will get a lot of warnings to begin with. I know Edward Diener has submitted some PR's to fix these, but I plan to make a concerted attack on any remaining once the new version is in develop. So here's the question, how do we proceed? My thoughts are to basically go ahead and merge, but not merge to master until after the next release at the earliest to give everything a chance to bed down, and the required changes in other libraries to filter through. Or we could have some sort of mini-review either formally or informally to check things out before the merge - of course folks are most welcome to do this anyway! Let me know what you think, best, John.

9 14

[type_traits] difference in decay semantic between boost and standard library
by Anton Bikineev 17 May '15

17 May '15

Hi Boost, Is it expected semantic of boost::decay not to strip top-level constness? Thanks.

1 0

[testing] Regression unresolved issues page
by Adam Wulkiewicz 15 May '15

15 May '15

Hi, The unresolved issues page seems to be outdated (only msvc-8.0 failures can be found there): http://www.boost.org/development/tests/develop/developer/issues.html It's because from all required toolsets mentioned here: https://github.com/boostorg/boost/blob/develop/status/explicit-failures-mar… only the msvc-8.0 is currently tested. The required compilers are quite old ones. I'm not sure how we should addres this issue. I get an impression that in the past this page was used differently than it is now. I'm not sure how though. The ToC/menu is also missing. Anyway, we could: - add only some specific, more modern required toolsets to the explicit-failures-markup.xml - ignore the required toolsets entries and display the issues detected in a library for all non-disabled toolsets - remove the issues page I'd probably go with the second option and treat this page as a complement of the regression matrix. What do you think? Regards, Adam

1 0

[ELFIO] - New library proposal
by Serge Lamikhov-Center 15 May '15

15 May '15

Hello Boost community! I'd like to determine interest in possible new library submission. ELFIO is header-only C++ library that provides a simple interface for reading and generating files in ELF binary format. It is a mature library and is in use by a number of open source and commercial projects. It is a part of some Linux distributions as well as Cygwin project. Would you please have a look at the library's home page located at: http://elfio.sourceforge.net Documentation: http://elfio.sourceforge.net/elfio.pdf Library download: http://sourceforge.net/projects/elfio/files/ELFIO-sources/ELFIO-3.1/ and its source code available through: http://github.com/serge1/ELFIO Please share your opinion on making this library be a part of the Boost. Thank you and Best regards, Serge

5 6

[test] Problem with BOOST_TEST_MESSAGE
by Edward Diener 15 May '15

15 May '15

In testing out a library with Boost.Test I want to inject informational messages that will appear in the output of the test results. When I use BOOST_TEST_MESSAGE with the correct logging level my message appears in the output if there is some sort of Boost.Test error during my tests. However if my unit test does not have a Boost.Test error my BOOST_TEST_MESSAGE does not appear. Needless to say I always want my BOOST_TEST_MESSAGE messages to always appear in the output. Is there a solution to this ?

4 12

[website] Broken uBLAS link
by Renato Florentino Garcia 14 May '15

14 May '15

Hi, The link to uBLAS documentation page on http://www.boost.org/doc/libs points to http://www.boost.org/doc/libs/release/libs/numeric/ublas/doc/index.htm instead of http://www.boost.org/doc/libs/release/libs/numeric/ublas/doc/index.html There are a missing l on .html Regards, Renato Garcia

1 0

[testing] Looking for test runner owner
by Andrzej Krzemienski 14 May '15

14 May '15

Hi All, The test matrix in branch 'master' contains these two test runners: oracle-intel-S2-stlport4 <http://www.boost.org/development/tests/master/oracle-intel-S2-stlport4.html> and oracle-sparc-S2-stlport4 <http://www.boost.org/development/tests/master/oracle-sparc-S2-stlport4.html> Could the owner of these reply to me? I am trying to fix a bug on this platform in Boost.Optional, and would require some assistance. Regards, &rzej

2 1

[variant] 1.58 boost/variant/get.hpp compile errors
by Maarten de Vries 14 May '15

14 May '15

Hello list, I recently updated to boost 1.58 and one of my programs didn't compile any more. The reason was the <boost/variant/get.hpp> header. A simple test program and compiler output is attached below. Swapping the order of the includes or including <boost/type_traits/remove_cv.hpp> before <boost/variant/get.hpp> in the test program will get rid of the errors. It would appear that <boost/variant/detail/element_index.hpp> should include <boost/type_traits/remove_cv.hpp>. Kind regards, Maarten de Vries Test program: #include <boost/variant/get.hpp> > #include <boost/variant/variant.hpp> > > int main() { > return 0; > } > Compiler output g++ (GCC) 4.9.2 20150304 (prerelease): In file included from /usr/include/boost/variant/get.hpp:24:0, > from test.cpp:1: > /usr/include/boost/variant/detail/element_index.hpp:38:69: error: > ‘remove_cv’ in namespace ‘boost’ does not name a template type > variant_element_functor<boost::mpl::_1, typename > boost::remove_cv<T>::type > > ^ > /usr/include/boost/variant/detail/element_index.hpp:38:78: error: expected > template-argument before ‘<’ token > variant_element_functor<boost::mpl::_1, typename > boost::remove_cv<T>::type > > > ^ > /usr/include/boost/variant/detail/element_index.hpp:38:78: error: expected > ‘>’ before ‘<’ token > /usr/include/boost/variant/detail/element_index.hpp:38:88: error: template > argument 2 is invalid > variant_element_functor<boost::mpl::_1, typename > boost::remove_cv<T>::type > > > ^ > /usr/include/boost/variant/detail/element_index.hpp:39:9: error: expected > ‘::’ before ‘>’ token > > > ^ > /usr/include/boost/variant/detail/element_index.hpp:39:9: error: expected > identifier before ‘>’ token > /usr/include/boost/variant/detail/element_index.hpp:39:9: error: template > argument 2 is invalid > /usr/include/boost/variant/detail/element_index.hpp:40:5: error: expected > ‘::’ before ‘>’ token > > > ^ > /usr/include/boost/variant/detail/element_index.hpp:40:5: error: expected > identifier before ‘>’ token > /usr/include/boost/variant/detail/element_index.hpp:40:5: error: template > argument 2 is invalid > /usr/include/boost/variant/detail/element_index.hpp:41:1: error: expected > ‘::’ before ‘{’ token > {}; > ^ > /usr/include/boost/variant/detail/element_index.hpp:41:1: error: expected > class-name before ‘{’ token >

3 3

Community Maintainence Team - a Modest proposal
by Robert Ramey 13 May '15

13 May '15

Today at 12:45 in Bethe is the operations meeting of the Boost Community Library Maintainence team. In advance of that meeting I'd like to render my proposal on this list so I have it written down. Premise:The library maintainence team does not and will likely never have sufficient resources to maintain libraries without current maintainers. Proposal: a) The CMT will solicit volunteers to take over maintainence of specific libraries. b) The most likely source of such volunteers are those working in companies which use and depend upon the libraries in maintainence. Such companies will be expected to support the library maintainence by permitting the maintainer to undertake this effort using company time and resources. c) Since we don't have a list of which companies are using which libraries, we will send a solicitation to volunteer to every person who has posted a bug report for the library in question on the TRAC system. I believe this is the most likely source for prospective maintainers. d) Companies that support maintainence of a particular library will be permited to place their logo and link on the TRAC page for that library. So they will receive the following benefits from sponsoring the maintainece of the library. 1) They will be demonstrating their commitment to the high standard of software development that Boost supports. 2) By placing their logo and link on the track page, they will be encouraging and facilitating prospective employees who desire to work for such an organization to contact them. That is, they will have a leg up on attracting the highest quality C++ programmers. 3) They will be guarenteed timely and rigorous maintainence of the library which they depend on. 4) They will have the inside track on proposing and implementing any library enhancements that they desire. 5) They will benefit from collaboration of the boost community which provides numerous valuable benefits: Bug fixes submitted by users, suggestions for enhancements. etc. The value of all these benefits to the sponsoring company will far, far out weigh the incremental cost of the employee time. In many cases, since employees have to maintain the library anyway - the incremental cost is zero anyway. This moves the responsibility for library maintainence to those most willing and able to undertake it. The role of the CMT would be to promote, recruit, certify, and monitor library maintainence. The CMT would have the authority to move the responsability from maintainer to another. The current practice of having a single person/entity responsible for maintainence of a library would continue unchanged. Robert Ramey

4 7

boost serialization and new archive types
by Robert Ramey 13 May '15

13 May '15

I'm here at C++Now and some have approached me about some enhancements to the serialization library. Specifically there is interest in moving the implementation of XML serialization to the latest C++11 of boost. I've gone them one better - While they're at it, how about including JSON and YAML as well? I would be happy to meet with anyone and everyone interested in this while here at the conference. I'm commited to all the operations meetings 12:45 so that time would be out - I'm flexible. Robert Ramey

2 1

Windows XP support survey
by Niall Douglas 13 May '15

13 May '15

The Boost SC suggested I ask about Microsoft Windows XP support in Boost libraries here, so I'd appreciate if library maintainers could state: 1. If they still support Microsoft Windows XP i.e. actively do not use APIs not supported by XP. And if SP3 is the only service pack supported, or if any XP is okay. 2. Whether they regularly test their libraries on a Windows XP machine to ensure their libraries work there. 3. Their personal opinion about when would be best to drop mandatory Microsoft Windows XP support. Individual library maintainers can of course choose to keep supporting it. As we all know, Microsoft Windows XP is no longer supported by Microsoft as of April 2014, however a widely available registry tweak reenables support and updates until 2019. However Visual Studio 2012 cannot run on XP, nor by default can produce binaries which execute on XP, so testing and developing for XP compatibility is going to become increasingly difficult. It may become wise to announce a date that XP support guarantees will be dropped, and any users needing XP support must remain on an older Boost version and/or make use of Boost modularity to mux their own Boost distro. One big reason for thinking about this is that the first C++ 11 mandatory Boost libraries are just around the corner, and they of course need VS2013 or even VS2015 and so therefore cannot promise Windows XP support. There are also a number of post-XP APIs the assumption of which would make some library authors very pleased. For example, I would assume any Boost.Thread v5 would use the Vista only condvar APIs as one can then skip emulating condvars with win32 semaphores which would be an enormous saving of code complexity. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

14 41

Re: [boost] Interest in a container which can hold multiple data types?
by James Armstrong 12 May '15

12 May '15

You're correct in that a vector<boost::any> can achieve the same thing, and that would probably be the better way to implement this internally. I guess the proposal would be to provide the container interface to give some data modification functions and iterators which iterate over only a given type and such. That way there would be a standardized container with methods to deal with the data in a type specific way. -- James Armstrong

5 17

Re: [boost] [boost.org website] Incorrect links on Boost website
by Marek Kurdej 12 May '15

12 May '15

> > From: Daniel James <dnljms(a)gmail.com> > To: boost(a)lists.boost.org > Cc: > Date: Sun, 10 May 2015 20:04:10 +0100 > Subject: Re: [boost] [boost.org website] Incorrect links on Boost website > On 10 May 2015 at 16:10, Michael Levine <shmuel.levine(a)gmail.com> wrote: > > I was browsing through the Boost website this morning and the links on > the > > right sidebar caught my attention. It appears that there is a duplicate > > entry for "coding guidelines for constant integral expressions", under > > Development / Requirements and Guidelines. The first of these links > points > > to the correct page. The second links to a page regarding library > > metadata. I'm not sure who, exactly, to contact for this, so I figured > this > > list would be the most appropriate means to have this addressed. > It's fixed now. Hi, Along these lines, I have spotted a curious detail on 3 Boost mailing lists. The logos (C++ Boost / Boost C++ libraries) point to web pages that are not affiliated in any way to boost. The concerned lists are: - http://lists.boost.org/boost-docs/ points to www [dot] boost [dot] com - http://lists.boost.org/boost-testing/ points to www [dot] boost [dot] com - http://lists.boost.org/geometry/ points to www [dot] osl [dot] iu [dot] edu There are maybe more wrong links that I haven't caught. Can it be fixed, please?. Regards, Marek Kurdej

2 1

A summary of testing with sanitizers
by Ben Pope 12 May '15

12 May '15

Hello all. Now that I've finally managed to get the sanitizers all working properly (correctly linking against the sanitized runtimes) I'd like to present a summary of its output (which I hope doesn't wrap). I would like to point out that the sanitizers may not be able to completely determine whether the code is correct or not, perhaps merely that they do not understand it (inline asm, etc.), and it also looks like some of the errors are in libc++, not Boost. If the code is determined to be correct, I could add entries to the blacklist to make sure the sanitizers ignore the output, but I would prefer not to. Perhaps a better approach would be to mark up the code so that all users of sanitizers benefit, rather than just the test matrix. Suggestions on how to reduce this output (I hope to publish summaries on a regular basis) in the best possible way are welcomed. I've ordered the output by the number of test failures that result from a particular complaint as determined by the command below: cat bjam.log | grep SUMMARY | sort | uniq -c | sort -n -r Count Warning 89 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/detail/shared_count.hpp:449:49 in boost::detail::shared_count::shared_count(boost::detail::shared_count const&) 70 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/shared_ptr.hpp:392:63 in boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) 69 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/detail/sp_counted_base_clang.hpp:31:5 in boost::detail::atomic_increment(int _Atomic*) 44 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/shared_ptr.hpp:392:57 in boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) 44 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/detail/shared_count.hpp:449:43 in boost::detail::shared_count::shared_count(boost::detail::shared_count const&) 33 SUMMARY: ThreadSanitizer: data race on vptr (ctor/dtor vs virtual call) /home/ben/development/boost/test/build/boost_root/status/../libs/thread/src/pthread/thread.cpp:168:21 in boost::(anonymous namespace)::thread_proxy(void*) 22 SUMMARY: ThreadSanitizer: data race (/home/ben/development/llvm/trunk/build/release/projects/compiler-rt/lib/tsan/libcxx_tsan/lib/libc++.so.1+0x43962) in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::assign(char const*, unsigned long) 21 SUMMARY: ThreadSanitizer: data race (/home/ben/development/llvm/trunk/build/release/projects/compiler-rt/lib/tsan/libcxx_tsan/lib/libc++.so.1+0x43991) in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::assign(char const*, unsigned long) 21 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/test/utils/basic_cstring/basic_cstring.hpp:384:13 in boost::unit_test::basic_cstring<char const>::operator=(boost::unit_test::basic_cstring<char const> const&) 21 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/test/utils/basic_cstring/basic_cstring.hpp:383:13 in boost::unit_test::basic_cstring<char const>::operator=(boost::unit_test::basic_cstring<char const> const&) 21 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/test/impl/unit_test_log.ipp:118:41 in boost::unit_test::(anonymous namespace)::unit_test_log_impl::set_checkpoint(boost::unit_test::basic_cstring<char const>, unsigned long, boost::unit_test::basic_cstring<char const>) 18 SUMMARY: ThreadSanitizer: data race /usr/local/bin/../include/c++/v1/ios:499:12 in std::__1::ios_base::width() const 15 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:331:10 in boost::multiprecision::backends::detail::gmp_float_imp<50u>::~gmp_float_imp() 12 SUMMARY: ThreadSanitizer: heap-use-after-free /home/ben/development/boost/test/build/boost_root/status/../boost/chrono/time_point.hpp:196:20 in boost::chrono::time_point<boost::chrono::steady_clock, boost::chrono::duration<long, boost::ratio<1l, 1000000000l> > >::time_since_epoch() const 11 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/detail/invoke.hpp:134:14 in _ZN5boost6detail6invokeIPFvNS_7promiseIRiEEEJS4_EEEDTclclsr5boostE7forwardIT_Efp_Espclsr5boostE7forwardIT0_Efp0_EEEOS7_DpOS8_ 11 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/shared_ptr.hpp:392:63 in boost::shared_ptr<boost::detail::shared_state<int&> >::shared_ptr(boost::shared_ptr<boost::detail::shared_state<int&> > const&) 10 SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/local/bin/../include/c++/v1/string:640:63 in std::__1::char_traits<char>::length(char const*) 10 SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s). 8 SUMMARY: AddressSanitizer: 552 byte(s) leaked in 23 allocation(s). 7 SUMMARY: ThreadSanitizer: data race /usr/local/bin/../include/c++/v1/ios:742:54 in std::__1::basic_ios<char, std::__1::char_traits<char> >::fill() const 6 SUMMARY: ThreadSanitizer: data race /usr/local/bin/../include/c++/v1/ios:437:12 in std::__1::ios_base::flags() const 6 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/detail/invoke.hpp:134:14 in _ZN5boost6detail6invokeIPFvNS_7promiseIiEEEJS3_EEEDTclclsr5boostE7forwardIT_Efp_Espclsr5boostE7forwardIT0_Efp0_EEEOS6_DpOS7_ 6 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/shared_ptr.hpp:392:63 in boost::shared_ptr<boost::detail::shared_state<int> >::shared_ptr(boost::shared_ptr<boost::detail::shared_state<int> > const&) 5 SUMMARY: ThreadSanitizer: data race /usr/local/bin/../include/c++/v1/map:1006:47 in std::__1::map<void const*, boost::detail::tss_data_node, std::__1::less<void const*>, std::__1::allocator<std::__1::pair<void const* const, boost::detail::tss_data_node> > >::empty() const 5 SUMMARY: ThreadSanitizer: data race /usr/local/bin/../include/c++/v1/ios:506:22 in std::__1::ios_base::width(long) 5 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/src/pthread/thread.cpp:85:78 in boost::detail::(anonymous namespace)::tls_destructor(void*) 5 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/serialization/test/test_shared_ptr.cpp:123:5 in void save_and_load<boost::shared_ptr<A> >(boost::shared_ptr<A>&) 5 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/serialization/test/test_shared_ptr_132.cpp:117:5 in void save_and_load<boost_132::shared_ptr<A> >(boost_132::shared_ptr<A> const&) 5 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/serialization/src/basic_iarchive.cpp:443:16 in boost::archive::detail::basic_iarchive_impl::load_pointer(boost::archive::detail::basic_iarchive&, void*&, boost::archive::detail::basic_pointer_iserializer const*, boost::archive::detail::basic_pointer_iserializer const* (*)(boost::serialization::extended_type_info const&)) 5 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/numeric/odeint/stepper/bulirsch_stoer.hpp:202:13 in boost::numeric::odeint::controlled_step_result boost::numeric::odeint::bulirsch_stoer<std::__1::vector<double, std::__1::allocator<double> >, double, std::__1::vector<double, std::__1::allocator<double> >, double, boost::numeric::odeint::range_algebra, boost::numeric::odeint::default_operations, boost::numeric::odeint::initially_resizer>::try_step<void (*)(std::__1::vector<double, std::__1::allocator<double> > const&, std::__1::vector<double, std::__1::allocator<double> >&, double), std::__1::vector<double, std::__1::allocator<double> >, std::__1::vector<double, std::__1::allocator<double> >, std::__1::vector<double, std::__1::allocator<double> > >(void (*)(std::__1::vector<double, std::__1::allocator<double> > const&, std::__1::vector<double, std::__1::allocator<double> >&, double), std::__1::vector<double, std::__1::allocator<double> > co 5 SUMMARY: AddressSanitizer: heap-use-after-free /home/ben/development/llvm/trunk/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:403:3 in __asan_memcpy 5 SUMMARY: AddressSanitizer: 936 byte(s) leaked in 6 allocation(s). 5 SUMMARY: AddressSanitizer: 768 byte(s) leaked in 4 allocation(s). 5 SUMMARY: AddressSanitizer: 64 byte(s) leaked in 2 allocation(s). 5 SUMMARY: AddressSanitizer: 576 byte(s) leaked in 4 allocation(s). 5 SUMMARY: AddressSanitizer: 552 byte(s) leaked in 2 allocation(s). 5 SUMMARY: AddressSanitizer: 480 byte(s) leaked in 8 allocation(s). 5 SUMMARY: AddressSanitizer: 368 byte(s) leaked in 4 allocation(s). 5 SUMMARY: AddressSanitizer: 32 byte(s) leaked in 4 allocation(s). 5 SUMMARY: AddressSanitizer: 240 byte(s) leaked in 4 allocation(s). 5 SUMMARY: AddressSanitizer: 1 byte(s) leaked in 1 allocation(s). 4 SUMMARY: ThreadSanitizer: thread leak /home/ben/development/boost/test/build/boost_root/status/../libs/thread/src/pthread/thread.cpp:250:25 in boost::thread::start_thread_noexcept() 4 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/pthread/pthread_mutex_scoped_lock.hpp:24:23 in boost::pthread::pthread_mutex_scoped_lock::pthread_mutex_scoped_lock(pthread_mutex_t*) 4 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/pthread/pthread_mutex_scoped_lock.hpp:24:17 in boost::pthread::pthread_mutex_scoped_lock::pthread_mutex_scoped_lock(pthread_mutex_t*) 4 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/pthread/once_atomic.hpp:128:25 in void boost::call_once<void (&)()>(boost::once_flag&, void (&)()) 4 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/detail/thread.hpp:116:17 in boost::detail::thread_data<void (*)()>::run() 4 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/atomic/detail/atomic_template.hpp:134:22 in boost::atomics::detail::base_atomic<unsigned int, int>::compare_exchange_strong(unsigned int&, unsigned int, boost::memory_order, boost::memory_order) volatile 4 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/serialization/test/test_shared_ptr_multi_base.cpp:185:5 in void shared_weak<boost::shared_ptr<Sub>, boost::weak_ptr<Base3> >(boost::shared_ptr<Sub>&, boost::weak_ptr<Base3>&) 4 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/type_index/stl_type_index.hpp:141:40 in boost::typeindex::stl_type_index::pretty_name() const 3 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/detail/invoke.hpp:134:14 in _ZN5boost6detail6invokeIPFvNS_7promiseIvEEEJS3_EEEDTclclsr5boostE7forwardIT_Efp_Espclsr5boostE7forwardIT0_Efp0_EEEOS6_DpOS7_ 3 SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/local/bin/../include/c++/v1/string:3767:13 in bool std::__1::operator==<std::__1::allocator<char> >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) 3 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/spirit/home/qi/numeric/detail/real_impl.hpp:295:22 in bool boost::spirit::qi::detail::real_impl<double, boost::spirit::qi::real_policies<double> >::parse<char const*, double>(char const*&, char const* const&, double&, boost::spirit::qi::real_policies<double> const&) 3 SUMMARY: MemorySanitizer: use-of-uninitialized-value /build/buildd/glibc-2.21/misc/tsearch.c:356 in tdelete 2 SUMMARY: ThreadSanitizer: data race (/home/ben/development/llvm/trunk/build/release/projects/compiler-rt/lib/tsan/libcxx_tsan/lib/libc++.so.1+0x381e2) in std::__1::__shared_weak_count::__release_shared() 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/try_join_until_pass.cpp:55:12 in G::operator()() 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/try_join_until_pass.cpp:54:5 in G::operator()() 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/detach_pass.cpp:70:5 in main 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/detach_pass.cpp:69:5 in main 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/constr/move_pass.cpp:58:55 in G::operator()(int, double) 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/asio/test/strand.cpp:91:3 in sleep_increment(boost::asio::io_service*, int*) 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/future.hpp:3377:50 in boost::packaged_task<double (int, char)>::packaged_task(boost::packaged_task<double (int, char)>&&) 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/future.hpp:3377:11 in boost::packaged_task<double (int, char)>::packaged_task(boost::packaged_task<double (int, char)>&&) 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/detail/invoke.hpp:134:14 in _ZN5boost6detail6invokeIPFvNS_13packaged_taskIFdicEEEEJS4_EEEDTclclsr5boostE7forwardIT_Efp_Espclsr5boostE7forwardIT0_Efp0_EEEOS7_DpOS8_ 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/shared_ptr.hpp:392:63 in boost::shared_ptr<boost::detail::shared_state<void> >::shared_ptr(boost::shared_ptr<boost::detail::shared_state<void> > const&) 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/shared_ptr.hpp:334:35 in boost::shared_ptr<boost::detail::task_base_shared_state<double (int, char)> >::shared_ptr() 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/detail/shared_count.hpp:114:21 in boost::detail::shared_count::shared_count() 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/log/utility/once_block.hpp:91:24 in boost::log::v2_mt_posix::aux::once_block_sentry::executed() const 2 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:159:10 in boost::multiprecision::backends::detail::gmp_float_imp<50u>::operator=(long) 2 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/geometry/strategies/cartesian/point_in_box.hpp:36:34 in bool boost::geometry::strategy::within::within_range::apply<double, double>(double const&, double const&, double const&) 2 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/container/vector.hpp:2774:7 in boost::container::container_detail::vec_iterator<boost::container::stable_vector_detail::node_base<void*>**, false> boost::container::vector<boost::container::stable_vector_detail::node_base<void*>*, boost::container::allocator<boost::container::stable_vector_detail::node_base<void*>*, 2u, 0u> >::priv_forward_range_insert<boost::container::container_detail::insert_value_initialized_n_proxy<boost::container::allocator<boost::container::stable_vector_detail::node_base<void*>*, 2u, 0u>, boost::container::stable_vector_detail::node_base<void*>**> >(boost::container::stable_vector_detail::node_base<void*>** const&, unsigned long, boost::container::container_detail::insert_value_initialized_n_proxy<boost::container::allocator<boost::container::stable_vector_detail::node_base<void*>*, 2u, 0u>, boost::container::stable_vector_detail::node_base<void*>**>) 2 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/container/vector.hpp:2604:11 in void boost::container::vector<MyInt, boost::container::allocator<MyInt, 2u, 6u> >::priv_push_back<MyInt>(MyInt&&) 2 SUMMARY: MemorySanitizer: use-of-uninitialized-value /build/buildd/glibc-2.21/misc/tsearch.c:320 in tfind 2 SUMMARY: AddressSanitizer: stack-buffer-overflow /home/ben/development/boost/test/build/boost_root/status/../libs/spirit/classic/test/traverse_tests.cpp:379:44 in void post_order_trace_test<boost::spirit::classic::sequence<boost::spirit::classic::chlit<char>, boost::spirit::classic::chlit<char> > >(boost::spirit::classic::sequence<boost::spirit::classic::chlit<char>, boost::spirit::classic::chlit<char> > const&, char const**, unsigned long) 2 SUMMARY: AddressSanitizer: stack-buffer-overflow /home/ben/development/boost/test/build/boost_root/status/../libs/local_function/test/return_derivative_seq.cpp:17:9 in derivative(boost::function<int (int)>&, int)::boost_local_function_auxXfunctorX17X::operator()(int) 2 SUMMARY: AddressSanitizer: 576 byte(s) leaked in 12 allocation(s). 2 SUMMARY: AddressSanitizer: 288 byte(s) leaked in 6 allocation(s). 2 SUMMARY: AddressSanitizer: 16 byte(s) leaked in 1 allocation(s). 2 SUMMARY: AddressSanitizer: 14496 byte(s) leaked in 404 allocation(s). 2 SUMMARY: AddressSanitizer: 120 byte(s) leaked in 5 allocation(s). 1 SUMMARY: ThreadSanitizer: data race /usr/local/bin/../include/c++/v1/ios:488:22 in std::__1::ios_base::precision(long) 1 SUMMARY: ThreadSanitizer: data race /usr/local/bin/../include/c++/v1/ios:444:20 in std::__1::ios_base::flags(unsigned int) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/./util.inl:106:16 in (anonymous namespace)::execution_monitor::wait() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/try_join_for_pass.cpp:55:12 in G::operator()() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/try_join_for_pass.cpp:54:5 in G::operator()() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/join_pass.cpp:56:12 in G::operator()() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/join_pass.cpp:39:5 in G::G() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/spirit/classic/test/owi_mt_tests.cpp:93:23 in test_task<boost::spirit::classic::impl::object_with_id<tag1, unsigned long> >::increase_test_size(unsigned long) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/log/test/run/util_once_block.cpp:64:25 in once_block_flag_thread(boost::barrier&) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/log/test/run/util_once_block.cpp:112:25 in once_block_thread(boost::barrier&) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/interprocess/test/condition_test_template.hpp:83:17 in void boost::interprocess::test::condition_test_thread<boost::interprocess::interprocess_condition_any, boost::interprocess::ipcdetail::spin_mutex>(boost::interprocess::test::condition_test_data<boost::interprocess::interprocess_condition_any, boost::interprocess::ipcdetail::spin_mutex>*) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/interprocess/test/condition_test_template.hpp:321:15 in void boost::interprocess::test::do_test_condition_queue_notify_one<boost::interprocess::interprocess_condition_any, boost::interprocess::ipcdetail::spin_mutex>() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/interprocess/test/condition_test_template.hpp:282:10 in boost::interprocess::test::condition_func<boost::interprocess::interprocess_condition_any, boost::interprocess::ipcdetail::spin_mutex>::operator()() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/interprocess/test/condition_test_template.hpp:277:10 in boost::interprocess::test::condition_func<boost::interprocess::interprocess_condition_any, boost::interprocess::ipcdetail::spin_mutex>::operator()() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/atomic/test/ordering.cpp:200:40 in total_store_order_test<(boost::memory_order)0, (boost::memory_order)0>::thread2fn() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/atomic/test/atomicity.cpp:131:28 in racy_add(unsigned int volatile&, unsigned long) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/pthread/mutex.hpp:62:17 in boost::posix::pthread_mutex_lock(pthread_mutex_t*) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/future.hpp:2481:88 in boost::promise<void>::promise(boost::promise<void>&&) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/detail/invoke.hpp:134:14 in _ZN5boost6detail6invokeIPFvvEJEEEDTclclsr5boostE7forwardIT_Efp_Espclsr5boostE7forwardIT0_Efp0_EEEOS4_DpOS5_ 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/shared_ptr.hpp:663:16 in boost::shared_ptr<boost::detail::shared_state<void> >::get() const 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/local/bin/../include/c++/v1/bitset:757:46 in std::__1::bitset<8ul>::bitset<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::size_type, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::size_type, char, char) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/local/bin/../include/c++/v1/algorithm:1193:13 in bool std::__1::equal<boost::archive::iterators::mb_from_wchar<wchar_t const*>, char const*, std::__1::__equal_to<wchar_t, char> >(boost::archive::iterators::mb_from_wchar<wchar_t const*>, boost::archive::iterators::mb_from_wchar<wchar_t const*>, char const*, std::__1::__equal_to<wchar_t, char>) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_rational_io_mpz.test/clang-linux-3.7~msan~c14_libc++/release/test_rational_io_mpz+0x76708) in boost::multiprecision::number<boost::multiprecision::backends::gmp_rational, (boost::multiprecision::expression_template_option)1> generate_random<boost::multiprecision::number<boost::multiprecision::backends::gmp_rational, (boost::multiprecision::expression_template_option)1> >() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_miller_rabin.test/clang-linux-3.7~msan~c14_libc++/release/test_miller_rabin+0x75bbf) in void test<boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> >() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_int_io_mpz.test/clang-linux-3.7~msan~c14_libc++/release/test_int_io_mpz+0x7ca20) in boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> generate_random<boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> >() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_generic_conv.test/clang-linux-3.7~msan~c14_libc++/release/test_generic_conv+0x99138) in void boost::multiprecision::detail::generic_interconvert<boost::multiprecision::backends::gmp_int, boost::multiprecision::backends::cpp_int_backend<0u, 0u, (boost::multiprecision::cpp_integer_type)1, (boost::multiprecision::cpp_int_check_type)0, std::__1::allocator<unsigned long long> > >(boost::multiprecision::backends::gmp_int&, boost::multiprecision::backends::cpp_int_backend<0u, 0u, (boost::multiprecision::cpp_integer_type)1, (boost::multiprecision::cpp_int_check_type)0, std::__1::allocator<unsigned long long> > const&, mpl_::int_<0> const&, mpl_::int_<0> const&) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_float_io_mpf.test/clang-linux-3.7~msan~c14_libc++/release/test_float_io_mpf+0x916e9) in void test<boost::multiprecision::number<boost::multiprecision::backends::gmp_float<50u>, (boost::multiprecision::expression_template_option)1> >() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_cpp_int_3.test/clang-linux-3.7~msan~c14_libc++/release/test_cpp_int_3+0x89656) in boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> generate_random<boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> >(unsigned int) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_cpp_int_2.test/clang-linux-3.7~msan~c14_libc++/release/test_cpp_int_2+0x89246) in boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> generate_random<boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> >(unsigned int) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_cpp_int_1.test/clang-linux-3.7~msan~c14_libc++/release/test_cpp_int_1+0x95d16) in boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> generate_random<boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> >(unsigned int) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/serialization/src/basic_xml_grammar.ipp:200:5 in boost::archive::basic_xml_grammar<char>::my_parse(std::__1::basic_istream<char, std::__1::char_traits<char> >&, boost::spirit::classic::rule<boost::spirit::classic::scanner<std::__1::__wrap_iter<char*>, boost::spirit::classic::scanner_policies<boost::spirit::classic::iteration_policy, boost::spirit::classic::match_policy, boost::spirit::classic::action_policy> >, boost::spirit::classic::nil_t, boost::spirit::classic::nil_t> const&, char) const 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/graph/test/typestr.hpp:33:29 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > typestr<boost::undirected_graph<VertexBundle, EdgeBundle, GraphBundle> >() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/container/test/alloc_full_test.cpp:126:10 in boost::container::test::test_allocation_shrink() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/container/test/alloc_basic_test.cpp:24:7 in basic_test() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/container/bench/bench_alloc.cpp:63:13 in void allocation_timing_test<char_holder<8u> >(unsigned int, unsigned int) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/config/test/limits_test.cpp:97:8 in void print_hex_val<long double>(long double, char const*) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/test/impl/test_tools.ipp:298:9 in boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const>, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/spirit/home/qi/numeric/detail/real_impl.hpp:295:22 in bool boost::spirit::qi::detail::real_impl<double, boost::spirit::qi::ureal_policies<double> >::parse<char const*, double>(char const*&, char const* const&, double&, boost::spirit::qi::ureal_policies<double> const&) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/spirit/home/qi/numeric/detail/real_impl.hpp:295:22 in bool boost::spirit::qi::detail::real_impl<double, boost::spirit::qi::strict_real_policies<double> >::parse<char const*, double>(char const*&, char const* const&, double&, boost::spirit::qi::strict_real_policies<double> const&) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/spirit/home/qi/numeric/detail/real_impl.hpp:295:22 in bool boost::spirit::qi::detail::real_impl<double, boost::spirit::qi::real_policies<double> >::parse<std::__1::__wrap_iter<char*>, double>(std::__1::__wrap_iter<char*>&, std::__1::__wrap_iter<char*> const&, double&, boost::spirit::qi::real_policies<double> const&) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/numeric/odeint/stepper/bulirsch_stoer.hpp:202:13 in boost::numeric::odeint::controlled_step_result boost::numeric::odeint::bulirsch_stoer<boost::array<double, 3ul>, double, boost::array<double, 3ul>, double, boost::numeric::odeint::array_algebra, boost::numeric::odeint::default_operations, boost::numeric::odeint::initially_resizer>::try_step<lorenz, boost::array<double, 3ul>, boost::array<double, 3ul>, boost::array<double, 3ul> >(lorenz, boost::array<double, 3ul> const&, boost::array<double, 3ul> const&, double&, boost::array<double, 3ul>&, double&) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/numeric/odeint/iterator/impl/adaptive_iterator_impl.hpp:105:17 in boost::numeric::odeint::adaptive_iterator_impl<boost::numeric::odeint::adaptive_iterator<boost::numeric::odeint::dummy_controlled_stepper, empty_system, boost::array<double, 1ul>, boost::numeric::odeint::controlled_stepper_tag>, boost::numeric::odeint::dummy_controlled_stepper, empty_system, boost::array<double, 1ul>, boost::numeric::odeint::detail::ode_state_iterator_tag, boost::numeric::odeint::controlled_stepper_tag>::increment() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:368:7 in boost::multiprecision::backends::detail::gmp_float_imp<0u>::data() const 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:331:10 in boost::multiprecision::backends::detail::gmp_float_imp<25u>::~gmp_float_imp() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:331:10 in boost::multiprecision::backends::detail::gmp_float_imp<100u>::~gmp_float_imp() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:234:7 in boost::multiprecision::backends::detail::gmp_float_imp<0u>::str(long, unsigned int) const 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:1932:7 in boost::multiprecision::backends::gmp_rational::str(long, unsigned int) const 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:1827:10 in boost::multiprecision::backends::gmp_rational::operator=(unsigned long) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:152:10 in boost::multiprecision::backends::detail::gmp_float_imp<50u>::operator=(unsigned long) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:152:10 in boost::multiprecision::backends::detail::gmp_float_imp<2000u>::operator=(unsigned long) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:152:10 in boost::multiprecision::backends::detail::gmp_float_imp<0u>::operator=(unsigned long) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:1226:7 in boost::multiprecision::backends::gmp_int::str(long, unsigned int) const 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:1100:10 in boost::multiprecision::backends::gmp_int::operator=(long) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:1093:10 in boost::multiprecision::backends::gmp_int::operator=(unsigned long) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/graph/boykov_kolmogorov_max_flow.hpp:471:22 in boost::detail::bk_max_flow<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, Node<boost::detail::edge_desc_impl<boost::directed_tag, unsigned long> >, Link<boost::detail::edge_desc_impl<boost::directed_tag, unsigned long> >, boost::no_property, boost::listS>, boost::adj_list_edge_property_map<boost::directed_tag, long, long&, unsigned long, Link<boost::detail::edge_desc_impl<boost::directed_tag, unsigned long> >, long Link<boost::detail::edge_desc_impl<boost::directed_tag, unsigned long> >::*>, boost::adj_list_edge_property_map<boost::directed_tag, long, long&, unsigned long, Link<boost::detail::edge_desc_impl<boost::directed_tag, unsigned long> >, long Link<boost::detail::edge_desc_impl<boost::directed_tag, unsigned long> >::*>, boost::adj_list_edge_property_map<boost::directed_tag, boost::detail::edge_desc_impl<boost::directed_ 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/gil/color_base_algorithm.hpp:237:60 in bool boost::gil::detail::element_recursion<2>::static_equal<boost::gil::bit_aligned_pixel_reference<unsigned char, boost::mpl::vector3_c<int, 1, 2, 1>, boost::gil::layout<boost::mpl::vector3<boost::gil::red_t, boost::gil::green_t, boost::gil::blue_t>, boost::mpl::vector3_c<int, 2, 1, 0> >, true>, boost::gil::bit_aligned_pixel_reference<unsigned char, boost::mpl::vector3_c<int, 1, 2, 1>, boost::gil::layout<boost::mpl::vector3<boost::gil::red_t, boost::gil::green_t, boost::gil::blue_t>, boost::mpl::range_c<int, 0, 3> >, true> >(boost::gil::bit_aligned_pixel_reference<unsigned char, boost::mpl::vector3_c<int, 1, 2, 1>, boost::gil::layout<boost::mpl::vector3<boost::gil::red_t, boost::gil::green_t, boost::gil::blue_t>, boost::mpl::vector3_c<int, 2, 1, 0> >, true> const&, boost::gil::bit_aligned_pixel_reference<unsigned char, boost::mpl::vector3_c<int, 1, 2, 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/context/execution_context.hpp:115:17 in boost::context::execution_context::activation_record::resume(bool) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/container/vector.hpp:457:10 in boost::container::container_detail::vector_alloc_holder<boost::container::allocator<int, 2u, 0u>, boost::move_detail::integral_constant<unsigned int, 2u> >::~vector_alloc_holder() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/container/vector.hpp:2774:7 in boost::container::container_detail::vec_iterator<int*, false> boost::container::vector<int, boost::container::allocator<int, 2u, 0u> >::priv_forward_range_insert<boost::container::container_detail::insert_move_proxy<boost::container::allocator<int, 2u, 0u>, int*> >(int* const&, unsigned long, boost::container::container_detail::insert_move_proxy<boost::container::allocator<int, 2u, 0u>, int*>) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/container/vector.hpp:2774:7 in boost::container::container_detail::vec_iterator<boost::container::container_detail::pair<int, int>*, false> boost::container::vector<boost::container::container_detail::pair<int, int>, boost::container::allocator<boost::container::container_detail::pair<int, int>, 2u, 0u> >::priv_forward_range_insert<boost::container::container_detail::insert_move_proxy<boost::container::allocator<boost::container::container_detail::pair<int, int>, 2u, 0u>, boost::container::container_detail::pair<int, int>*> >(boost::container::container_detail::pair<int, int>* const&, unsigned long, boost::container::container_detail::insert_move_proxy<boost::container::allocator<boost::container::container_detail::pair<int, int>, 2u, 0u>, boost::container::container_detail::pair<int, int>*>) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/container/vector.hpp:2675:10 in boost::container::vector<MyInt, boost::container::allocator<MyInt, 2u, 0u> >::priv_shrink_to_fit(boost::move_detail::integral_constant<unsigned int, 2u>) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/container/vector.hpp:2604:11 in void boost::container::vector<int, boost::container::allocator<int, 2u, 0u> >::priv_push_back<int>(int&&) 1 SUMMARY: AddressSanitizer: stack-buffer-overflow /home/ben/development/boost/test/build/boost_root/status/../libs/local_function/test/return_derivative.cpp:22:9 in derivative(boost::function<int (int)>&, int)::boost_local_function_auxXfunctorX22X::operator()(int) 1 SUMMARY: AddressSanitizer: stack-buffer-overflow /home/ben/development/boost/test/build/boost_root/status/../boost/intrusive/detail/size_holder.hpp:35:14 in boost::intrusive::detail::size_holder<true, unsigned long, void>::get_size() const 1 SUMMARY: AddressSanitizer: global-buffer-overflow /home/ben/development/boost/test/build/boost_root/status/../boost/numeric/odeint/iterator/impl/times_iterator_impl.hpp:86:42 in boost::numeric::odeint::times_iterator_impl<boost::numeric::odeint::times_time_iterator<boost::numeric::odeint::dummy_stepper, empty_system, boost::array<double, 1ul>, double*, boost::numeric::odeint::stepper_tag>, boost::numeric::odeint::dummy_stepper, empty_system, boost::array<double, 1ul>, double*, boost::numeric::odeint::detail::ode_state_time_iterator_tag, boost::numeric::odeint::stepper_tag>::times_iterator_impl(boost::numeric::odeint::dummy_stepper, empty_system, boost::array<double, 1ul>&, double*, double*, double) 1 SUMMARY: AddressSanitizer: global-buffer-overflow /home/ben/development/boost/test/build/boost_root/status/../boost/numeric/odeint/iterator/impl/times_iterator_impl.hpp:86:42 in boost::numeric::odeint::times_iterator_impl<boost::numeric::odeint::times_iterator<boost::numeric::odeint::dummy_stepper, empty_system, boost::array<double, 1ul>, double*, boost::numeric::odeint::stepper_tag>, boost::numeric::odeint::dummy_stepper, empty_system, boost::array<double, 1ul>, double*, boost::numeric::odeint::detail::ode_state_iterator_tag, boost::numeric::odeint::stepper_tag>::times_iterator_impl(boost::numeric::odeint::dummy_stepper, empty_system, boost::array<double, 1ul>&, double*, double*, double) 1 SUMMARY: AddressSanitizer: container-overflow /usr/local/bin/../include/c++/v1/string:1664:39 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__is_long() const 1 SUMMARY: AddressSanitizer: container-overflow /home/ben/development/llvm/trunk/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:188:3 in __interceptor_strcmp 1 SUMMARY: AddressSanitizer: 96 byte(s) leaked in 6 allocation(s). 1 SUMMARY: AddressSanitizer: 8 byte(s) leaked in 1 allocation(s). 1 SUMMARY: AddressSanitizer: 816 byte(s) leaked in 1 allocation(s). 1 SUMMARY: AddressSanitizer: 797943 byte(s) leaked in 357 allocation(s). 1 SUMMARY: AddressSanitizer: 796079 byte(s) leaked in 351 allocation(s). 1 SUMMARY: AddressSanitizer: 72000000 byte(s) leaked in 3000000 allocation(s). 1 SUMMARY: AddressSanitizer: 65536 byte(s) leaked in 1 allocation(s). 1 SUMMARY: AddressSanitizer: 56 byte(s) leaked in 4 allocation(s). 1 SUMMARY: AddressSanitizer: 324 byte(s) leaked in 3 allocation(s). 1 SUMMARY: AddressSanitizer: 24 byte(s) leaked in 2 allocation(s). 1 SUMMARY: AddressSanitizer: 20 byte(s) leaked in 2 allocation(s). 1 SUMMARY: AddressSanitizer: 1984 byte(s) leaked in 11 allocation(s). 1 SUMMARY: AddressSanitizer: 171 byte(s) leaked in 9 allocation(s). 1 SUMMARY: AddressSanitizer: 14256 byte(s) leaked in 99 allocation(s). 1 SUMMARY: AddressSanitizer: 12345 byte(s) leaked in 1 allocation(s). 1 SUMMARY: AddressSanitizer: 114688 byte(s) leaked in 7 allocation(s). 1 SUMMARY: AddressSanitizer: 104 byte(s) leaked in 2 allocation(s). I'm happy to expand on any line that is less than useful. For the sake of sanity, I think I will also add this to the command line -Wno-unused-local-typedef, as the log contains 462603 matches, often times the warnings push more interesting things off beyond the 64Kb limit. Ben

6 12

Re: [boost] Multiple-pattern string search algorithms
by meghana madhyastha 12 May '15

12 May '15

Hi, The Rabin Karp algorithm performs better than KMP and Boyer Moore during multiple pattern searching. The interface that I have suggested is given below. Please let me know your opinions and if there is a better approach than the one I am suggesting. Any feedback/criticism/guidance will be appreciated and helpful. An overview of the Rabin Karp Algorithm: The Rabin Karp algorithm assigns hash values to the text. The pattern is made to 'slide' along the text to be searched. The hash value of the text is computed and is compared to the hash value of the pattern. A brute force search of each element in the pattern with the current window of text is performed if and only if the hash value of the text matches the hash value of the pattern (and this hash value can be calculated in O(1) time). There can be two interfaces that can be implemented for this a procedural and an object oriented interface (similar to the interfaces for the Boyer Moore Algorithm). There should be two iterator types. One to iterate through the text called 'textIter' and another to iterate through the set of patterns (multiple patterns can be stored as part of a set) called 'setIter'. In the object oriented interface, the hash value of the pattern can be precomputed in the constructor. The text can be searched to match the pattern using the () operator (similar to the implementation of Boyer Moore). In the procedural interface, the search as well as hash computation of the pattern string all happens in the single function 'rabin_karp_search'. template <typename patIter> class rabin_karp { public: rabin_karp ( patIter first, patIter last ); ~rabin_karp (); template <typename textIter> template <typename setIter> textIter operator () ( textIter text_first, textIter text_last, setIter set_first, setIter set_last); }; template <typename patIter, typename textIter> textIter rabin_karp_search ( textIter text_first, textIter text_last, setIter set_first, setIter set_last ); Thanks and Regards, Meghana

1 0

[website] online docs not available?
by Andrzej Krzemienski 12 May '15

12 May '15

Hi Everyone, It looks that the online documentation is not available. the link http://www.boost.org/doc/libs/1_58_0/ displays a blank page. Can you see the docs? Regards, &rzej

3 2

[regression][testing][config] Regression results not displayed.
by Adam Wulkiewicz 11 May '15

11 May '15

Hi, Since 2015/04/26 the tests started to dissapear from Geometry summary pages for develop branch. And now the pages aren't even displayed properly, I see only: Error extracting file: No matching files were found. for: http://www.boost.org/development/tests/develop/developer/geometry.html http://www.boost.org/development/tests/develop/developer/geometry-extension… and on: http://www.boost.org/development/tests/develop/developer/geometry-index.html there are only 2 tests. Furthermore "geometry" and "geometry-extensions" can't be found in the menu. I can see the results for Geometry in the paskages sent to the server. I can also see them in the sanitizer reports sent by Ben. So I'm guessing that the error must be on a later stage of processing, probably in the Regression. Just before the time I saw the issue the first time I added new tests to "geometry-extensions", though it seems wierd that it could affect "geometry" and "geometry-index": https://github.com/boostorg/geometry/commit/9bc8baaa3b3fffc96fbb0abd10a8cb0… https://github.com/boostorg/geometry/commit/07c8b24b89e9fec75c6b7efc7e94032… Geometry is probably the library with the most complex tests structure. We use nested directories and build-project directive in Jamfiles. May this be a part of the problem? AFAIR at that time there were also some changes in the Regression, and the last time something like this happened Config was changed. Could some changes in those modules cause the issue I'm writing about? What may be the reason of such behavior and most importantly do you know how to fix it? Regards, Adam

2 6

What variants should be build on Windows by default?
by Olaf van der Spek 11 May '15

11 May '15

Hi, What library variants should be build on Windows by default? Currently it builds: --build-type=<type> Build the specified pre-defined set of variations of the libraries. Note, that which variants get built depends on what each library supports. -- minimal -- (default) Builds a minimal set of variants. On Windows, these are static multithreaded libraries in debug and release modes, using shared runtime. On Linux, these are static and shared multithreaded libraries in release mode. Personally I use a static-release runtime often (for simple deployments). What variants do others use and what should be build by default? Greetings, -- Olaf

4 3

[array] Support for multidimensional arrays?
by Peter Dimov 10 May '15

10 May '15

Currently, creating a multidimensional boost/std::array is a bit unwieldy: array<array<array<int, 5>, 4>, 3> a; // int a[3][4][5] a[2][3][4] = 5; As a first step, we should consider enabling the element type T of array<T, N> to be an array type. array<int[4][5], 3> a; // int a[3][4][5] a[2][3][4] = 5; This almost works already, except for the array interface functions specified and implemented in terms of, say, std::equal or std::fill. It is an open question whether these standard algorithms should not be fixed themselves to work on array types, as swap_ranges has been, but for now, we can implement the array functions in a way that works. Opinions on that part? If we agree that this is a good idea, the next logical step would be to eliminate the special handling of the first extent and simply allow array<int[3][4][5]> a; // int a[3][4][5] a[2][3][4] = 5;

4 4

[boost.org website] Incorrect links on Boost website
by Michael Levine 10 May '15

10 May '15

I was browsing through the Boost website this morning and the links on the right sidebar caught my attention. It appears that there is a duplicate entry for "coding guidelines for constant integral expressions", under Development / Requirements and Guidelines. The first of these links points to the correct page. The second links to a page regarding library metadata. I'm not sure who, exactly, to contact for this, so I figured this list would be the most appropriate means to have this addressed. Best regards, Shmuel

2 1

[algorithm] Removal of preference to std implementation
by Rob Conde 10 May '15

10 May '15

Marshall/Others-in-the-know, In boost algorithm change set 4dac507b773cf4a82727703ddffa2b36c42ab814, the code which uses std version of algorithms when available was removed. I'm curious about the motivation for this change. I can guess at a few potential reasons, but I figure you can just share the real reason. This change potentially explains a performance regression in my code so I'm just trying to understand the motivation before I make any code changes. Thanks! Rob Conde

1 0

[testing] Add a tester with hidden visibility
by Andrey Semashev 09 May '15

09 May '15

Hi, Is it possible to add a tester that enables hidden visibility (- fvisibility=hidden -fvisibility-inlines-hidden) when building and testing Boost? I believe, a single tester on Linux+GCC would be enough to discover most issues related to symbol visibility. The reason I'm asking is that I believe Boost should support building with hidden visibility by default. This mode allows more optimizations and does not export unintended symbols from libraries. I've set hidden visibility for Boost.Log (in develop) and, as I understand, Robert is doing a similar change in Boost.Serialization. However, when building 1.58 with hidden visibility for my project I found out that not all libraries work well with that setting. What do you think about it?

4 20

Re: [boost] Windows XP support survey
by Thomas Trummer 07 May '15

07 May '15

The sad reality in a lot of industries is that we still have to support Windows XP for the foreseeable future. Though, I understand the desire to drop support for it. Believe me, everyone would be more than happy to just require Windows 7 as default and be done with it. However, it is hard to convince costumers to make the switch when there is only risk and no tangible benefit attached to it. In addition to this we do have the problem that we control complex (and expensive) hardware that consists of components that don’t have drivers for Windows 7 because the manufacturer discontinued them. For these people the end of support from Microsoft isn’t really an argument since the computers are not connected to the Internet and continue to work fine, not to mention that you can still buy extended support from Microsoft. The huge outcry from the C++ community when Microsoft wanted to drop support for XP in Visual Studio should be a clear indicator that a lot of people livelihoods still depend on it. Unfortunately since then the install base hasn’t really shrunken too much. So even Visual C++ 2015 will continue to support it. So, as long as a Visual C++ version supported by Boost can build for Windows XP and there isn’t a significant cost attached to it, Boost should also continue to support Windows XP.

3 2

Re: [boost] Windows XP support survey
by Andrzej Horoszczak - Billon 07 May '15

07 May '15

1 0

Re: [boost] Interest in a container which can hold multiple data types?
by James Armstrong 07 May '15

07 May '15

Sorry about the README file, I pretty much just uploaded what I had to github so people can grab the source. Admittedly, things there are lacking. I'll work on filling out the readme with some instructions hopefully today. The main difference between this and a container of boost:any is that the container of boost::any still is a container of one data type, just being that one data type is a very flexible one. This container natively supports insertion of different data types. So, you could do, int my_int = 5; double my_double0 = 9342.132; double my_double1 = 987.654; std::string my_string("This is a string."); std::vector<double> my_vec; my_vector.push_back(123.456); omni my_container; my_container.push_back(my_int); my_container.push_back(my_double); my_container.push_back(my_string); my_container.push_back(my_vector); and the container happily stores the data. You can then access the data through iterators //access all doubles for (auto itr = my_container.begin<double>(); itr != my_containert.end<double>(); ++itr) { std::cout << *itr << std::endl; } or through specifying the data type and index //get the 0th element string std::cout << my_container.at<string>(0) << std::endl; -- James Armstrong

9 27

[lambda] Addressing pull requests
by Edward Diener 07 May '15

07 May '15

The maintainer for lambda in the libs/maintainer.txt list is Jaako Jarvi, who is the original author. But I see others who have made changes to the library. So I am wondering if anyone is still actively maintaining the library. There are a number of pull requests for lambda, related to updating the code for type_traits Version2, by John Maddock and myself. Is someone handling these ?

5 6

Arguing about names in Boost libraries
by Edward Diener 06 May '15

06 May '15

What is wrong with the people commenting on libraries for Boost who are so concerned about the names being used ? We are talking only about C++ identifiers and yet there are now endless discussions where people disagree on names or argue that some name is not what they want or that they like some other name, with a list of names that they find adequate. This is irrelevant. There is something mentally wrong about all those peoples spending endless amounts of time around this issue. I notice this does not happen nowadays for just one library but for ever single library, or proposed library, which is mentioned on this mailing list. Is this the way all of you people actually work in your daily jobs, or on your own projects, spending hours and days arguing with others about C++ identifiers for every little thing ? Are you not aware of the absurdity of your endless remarks ? Grow up ! Surely there are better things to do than carry on endlessly about some name, that is should be x or y or z or some other inane preferable list. It's time for somebody to say this, so I will do it. A C++ identifier name, as long as it is vaguely about what the functionality entails, is perfectly adequate. It does not have to satisfy everyone in the universe. Period !

9 10

C++11 compilers and fenv
by Damian Vicino 06 May '15

06 May '15

Hi, I’m implementing the safe_float library (on c++11) proposed for the GSOC . I was planning to access FENV for detecting unsafe operations on the native floating point types and include some custom pre-post conditions for testing other floating types safety conditions. Conditions come from policies passed as template parameter to give users the possibility of chose their own set of safety conditions to be enforced. An example of the conditions that can be asked is enforcing overflows to infinite does not happen. An overflow to infinite can be detected by the FE overflow flag or because the addition of two finites numbers result in an infinite one. I just found today that clang++ does not support the pragma to use FENV yet. warning: pragma STDC FENV_ACCESS ON is not supported Googling a little I found out that neither does gcc. How are c++11 boost libraries dealing with these compiler issues? I got some options in mind: — Implement everything using custom detections, this will work in every compiler, but it will run slower for everyone too. — Finding a compiler with the support, implementing the library using the FENV, and assuming compilers will support it when the library is finished and reviewed. — Detect somehow the FENV pragma was not processed and have 2 implementations. No idea how to detect something like this. Had someone dealt with similar problem already? Is there a common approach? Best regards, Damian Vicino

4 5

[ boost ] [ Trie ]
by Cosmin Boaca 06 May '15

06 May '15

Hello, I am interested in working at the Boost.Trie project which was started during GSoC 2013 and I am searching for someone who can give me some advice about what should I change / add to the current implementation, because I'm not too experienced in developing library code. However, I do not want do this during GSoC because I won't be available during the summer. I want to contribute during my spare time. If anyone thinks that can help me with this, please reply to this email. Thank you, Cosmin

8 90

BenPope x86_64 Ubuntu issue at link time
by Vicente J. Botet Escriba 06 May '15

06 May '15

Hi, I'm getting this link error /usr/bin/ld: error: /home/ben/development/boost/test/build/results/boost/bin.v2/libs/thread/test/thread__constr__FArgs_p_lib.test/clang-linux-3.7~asan~c14_libc++/debug/threading-multi/threads/thread/constr/FArgs_pass.o: multiple definition of 'operator delete(void*)' /usr/bin/ld: /home/ben/development/llvm/trunk/install/release/bin/../lib/clang/3.7.0/lib/linux/libclang_rt.asan_cxx-x86_64.a(asan_new_delete.cc.o): previous definition here at http://www.boost.org/development/tests/develop/developer/output/BenPope%20x… I define it as follows #if defined _GLIBCXX_THROW void* operator new(std::size_t s) _GLIBCXX_THROW (std::bad_alloc) #elif defined BOOST_MSVC void* operator new(std::size_t s) #else void* operator new(std::size_t s) throw (std::bad_alloc) #endif { std::cout << __FILE__ << ":" << __LINE__ << std::endl; if (throw_one == 0) throw std::bad_alloc(); --throw_one; return std::malloc(s); } Is this a compiler issue, or is my definition of the operator new incorrect? Vicente

2 2

[move] unique_ptr converting constructor
by Peter Dimov 06 May '15

06 May '15

While looking at https://svn.boost.org/trac/boost/ticket/11259 I found that after implementing a converting shared_ptr constructor that takes a boost::movelib::unique_ptr, the straightforward code in the ticket still fails (with g++ in C++03 mode): namespace mystd { using boost::shared_ptr; using boost::make_shared; using boost::movelib::unique_ptr; using boost::movelib::make_unique; } mystd::unique_ptr<int> load_thing() { return mystd::make_unique<int>(1); } mystd::shared_ptr<int> get_thing() { return load_thing(); } So, out of curiosity, I looked at how unique_ptr itself implements its converting constructor. It turns out that it, too, doesn't work. mystd::unique_ptr<int const> get_thing_2() { return load_thing(); } Furthermore, the two possible ways to make the shared_ptr code work: mystd::shared_ptr<int> get_thing() { mystd::shared_ptr<int> r( load_thing() ); return r; } mystd::shared_ptr<int> get_thing() { mystd::unique_ptr<int> r( load_thing() ); return boost::move( r ); } fail for the unique_ptr<int const> case.

4 8

Re: [boost] Interest in a container which can hold multiple data types?
by Brian Wood 06 May '15

06 May '15

Joaquin M Lopez Munoz writes: > I wrote something on this some time ago, maybe worth having a look at: > > http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html <http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html> > http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.html <http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.html> I look forward to someone implementing these things. Any progress? -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

2 1

Fwd: Boost.Python build error in 1.58 RC1, 2 and 3 (OK in Beta 1)
by Marshall Clow 06 May '15

06 May '15

---------- Forwarded message ---------- From: <mark.incley(a)synx.com> Date: Wed, Apr 8, 2015 at 1:29 AM Subject: Boost.Python build error in 1.58 RC1, 2 and 3 (OK in Beta 1) To: mclow.lists(a)gmail.com Hi Marshall, Please excuse the direct mail, but my mailing list posting wasn't picked up on by anyone. I believe I've found a problem in Boost.Python that causes build errors if the user has Python 3.0 or later on their system. This change appears to have been introduced after 1.58 Beta 1. Using: bjam address-model=32 runtime-link=shared toolset=msvc-12.0 --stagedir=./stage/x86 C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\xtgmath.h(206) : warning C4273: 'round' : inconsistent dll linkage C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\math.h(516) : see previous definition of 'round' libs\python\src\exec.cpp(91) : error C2664: 'FILE *_Py_fopen(PyObject *,const char *)' : cannot convert argument 1 from 'char *' to 'PyObject *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast call "C:\Users\MARK~1.INC\AppData\Local\Temp\b2_msvc_12.0_vcvarsall_x86.cmd" >nul cl /Zm800 -nologo @"bin.v2\libs\python\build\msvc-12.0\debug\link-static\threading-multi\exec.obj.rsp" ...failed compile-c-c++ bin.v2\libs\python\build\msvc-12.0\debug\link-static\threading-multi\exec.obj… The problem appears to be this Boost.Python code that was changed some time after 1.58 Beta 1 and appears in 1.58 RC1 within boost\libs\python\src\exec.cpp at around line 91: 1.58 beta 1: FILE *fs = fopen(f, "r"); 1.58 RCs: FILE *fs = _Py_fopen(f, "r"); ← f is a char *, hence the error shown above. It expects a PyObject * as the first parameter. This code occurs within a test for #if PY_VERSION_HEX >= 0x03000000 which may explain why no-one else has reported it – I have Python 3.3.0 on my HDD. Cheers, Mark. _____________________________________ Sent from http://boost.2283326.n4.nabble.com

13 31

Interest in a container which can hold multiple data types?
by James Armstrong 06 May '15

06 May '15

Hello forum, I was wanting to gauge interest in a container I developed which can natively handle multiple data types (as opposed to using a container of boost::any). I have the templated source hosted on my github account at https://github.com/armstrhu/omni There is some documentation on the current functions under omni/doc/html/index.html. main.cpp has some example codes on inserting, retrieving, and manipulating the data within the container. The one caveat to using the container is that the function destroy<T>() must be called for all data types inserted into the container, I currently have an assert in the destructor which will hit if destroy<T>() is not called for a data type. Also, this requires using a modified version of boost/core/typeinfo.hpp, so you will need to replace the original with the one I provide. The changes simply keep the boost functionality even when C++ typeinfo is available. I am trying to guage interest in this, and if there is interest, get some feedback on additional functionality to include. The iterators I have now work, but they are inefficient and that will be fixed eventually. Currently, I'm calling the container an omni, but don't really like that name and am looking for suggestions for something better :) Thanks -- James Armstrong

5 5

[Voronoi] Weighted Voronoi diagram
by Sybren A. Stüvel 06 May '15

06 May '15

Dear Boost mailing list, Currently I'm working on a Voronoi-based crowd simulation system. We model crowd agents as line segments, and feed them to the Boost Voronoi library. It would be very nice if we could give different line segments different weights. Does the Boost Voronoi library support different weights for its inputs? If not (which I'm afraid is the case, as it isn't mentioned in the documentation), how difficult would it be to add support for this? Kind regards, -- Sybren A. Stüvel http://stuvelfoto.nl/ http://stuvel.eu/

1 0

[threads] Unexpected behaviour of Thread loal storage
by Fu ji 06 May '15

06 May '15

Hello, I would like to ask if there is everything ok with my way of thinking. I have 3 solutions (projects) in MS Visual Studio. Let say: SolutionA (static lib) SolutionB (linked with Solution A) SolutionC (linked with Solution A) In Header file of solutionA I have delaration of TLS from boost static boost::thread_specific_ptr<int> TLS; And now in SolutionB I set tls (TLS.reset(uVariable)) - uVariable is integer 2 Call function from SolutionC and call TLS.get() but there is different value than 2. But when i return from function to SolutionB and call TLS.get there is everything ok (return 2). It's ok ? Why in solutionC there is no visibilty of value set in solutionB ? It's the same thread (with the same threadId). Best regards

2 18

[tuple] Changes living in develop
by Marcel Raad 06 May '15

06 May '15

Hi, there are three commits from last year in develop that haven't been merged to master yet. Could someone merge them please? 8bdf2a9 Make tuple constructor explicit 4fb2618 Add metadata file. b4f0590 Ported documentation to boostbook I always have to apply 8bdf2a9 manually to new Boost releases.

1 0

Re: [boost] [Boost-testing] Attempt to redeclare already registered project id '/check/predef'
by Tom Kent 06 May '15

06 May '15

On Tue, May 5, 2015 at 2:43 AM, Dmitry Moskalchuk <dm(a)crystax.net> wrote: > > Hello, > > Running tests of 'develop' branch, I've bumped with error today: > > error: at /home/cislave/.crystax/ci-boost/regression/android-19-x86-develop/test/develop/regression/x86/test/boost_bb/src/build/project.jam:1069 > error: Attempt to redeclare already registered project id '/check/predef'. > error: Original project: > error: Name: ../check/predef > error: Module: ../check/predef > error: Main id: /check/predef > error: File: ../check/predef.jam > error: Location: ../check/predef > error: New project: > error: Module: ../../predef/check/predef > error: File: ../../predef/check/predef.jam > error: Location: ../check/predef > > > It happens only when run regression tests for 'develop' branch ('master' > is OK). Is this known problem? > I'm getting the same error (which is stopping the regression run) on all my develop testers (windows and linux). Tom

2 1

[Master project] GitHub issues disabled
by Louis Dionne 06 May '15

06 May '15

Hi, The title pretty much says it all. Is there a reason for disabling GitHub issues on the master project? Also, I'd like to know when will the master project be tagged with the 1.58.0 release. Thanks, Louis

18 35

Re: [boost] Interest in a container which can hold multiple data types?
by James Armstrong 05 May '15

05 May '15

On 5/5/2015 7:49 PM, Joaquin M Lopez Munoz wrote: > TONGARI J <tongari95 <at> gmail.com> writes: > >> If the data sequence shows some affinity, I guess an ordered >> tuple_vector-based sequence can provide some performance benefit in >> traversal (with some crafted for_each method). >> >> That is, a sequence of [AAABBB] may be traversed faster than [ABABAB] for >> such a container, and I believe in the later case such that the types are >> uniformly distributed, vector<variant> will perform better. > I wrote something on this some time ago, maybe worth having a look at: > > http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html > http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.html > Nice analysis. If we can identify different use cases, we may be able to come up with several implementations of heterogeneous containers which balance efficiency and flexibility. I think it would be an interesting project to work on and surely useful if the containers all the a similar 'feel' -- James Armstrong

1 0

[filesystem] copy_file compilation error
by Rob Conde 05 May '15

05 May '15

In boost 1.55 the following code compiled file on visual studio 2013 and g++ 4.4.7: #include "boost/filesystem/operations.hpp" void myFunc() { using namespace boost::filesystem; copy_option opt(copy_option::overwrite_if_exists); copy_file(path("p1"),path("p2"),opt); } in boost 1.58 I get the following error on g++ 4.4.7 (Visual Studio 2013 continues to work): test.cpp: In function 'void myFunc()': test.cpp:9: error: no matching function for call to 'copy_file(boost::filesystem::path, boost::filesystem::path, boost::filesystem::copy_option&)' boost/filesystem/operations.hpp:494: note: candidates are: void boost::filesystem::copy_file(const boost::filesystem::path&, const boost::filesystem::path&, boost::filesystem::copy_option::enum_type) boost/filesystem/operations.hpp:500: note: void boost::filesystem::copy_file(const boost::filesystem::path&, const boost::filesystem::path&) boost/filesystem/operations.hpp:505: note: void boost::filesystem::copy_file(const boost::filesystem::path&, const boost::filesystem::path&, boost::filesystem::copy_option::enum_type, boost::system::error_code&) boost/filesystem/operations.hpp:511: note: void boost::filesystem::copy_file(const boost::filesystem::path&, const boost::filesystem::path&, boost::system::error_code&) is this a bug in filesystem on gcc, a bug in gcc, a non-standard behavior in visual studio 2013, or an intended change? Rob Conde

2 2

Re: [boost] Description of pre-requisites for building Boost 1.58.0?
by Marko Asplund 05 May '15

05 May '15

On 2015-04-24 22:17:55 Ben Pope wrote: > This doesn't really answer the question, but as a practical note, you > can do: > sudo apt-get build-dep libboost* > Which will install the build dependencies for the version of Boost in > your repository, rather than the version you're trying to build, but it > should get you where you want to be most of the time. FYI, I submitted a documentation pull request for adding a short section about pre-requisite software installation: https://github.com/boostorg/boost/pull/78 marko

1 0

Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements)
by Nevin Liber 05 May '15

05 May '15

On 2 April 2015 at 08:13, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: > I > was recently working with eggs.variant for example, and that is Boost > quality written to Boost guidelines and yet I understand there is > zero interest in it entering Boost, despite it being superior to > Boost.Variant in almost every way. I don't remember anyone asking if they'd like to see this in Boost. Could you point to a thread? Even though you claim it is superior in almost every way, if I'm reading it correctly it has one fundamental difference in that it models "at-most-one-of" vs. Boost.Variant which models "exactly-one-of". And yes, I would like to see it in Boost, because as variant gets proposed for the standard, it would be better to have a lot more user experience to help us decide that fundamental question. That certainly fits the current mission in that "We aim to establish 'existing practice' and provide reference implementations so that Boost libraries are suitable for eventual standardization." -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

14 43

Interested in contributing
by suryansh tiwari 05 May '15

05 May '15

Hey I'm new, but I'd like to contribute to your organisation, can someone please guide me along? I have done some good amount of competetive programming in c++ and I am completely new to open source.

3 4

Re: [boost] Interest in a container which can hold multiple data types?
by James Armstrong 05 May '15

05 May '15

So, as it is currently implemented, it doesn't actually make use of boost::any or boost::variants. I used a deque<void*> to store addresses of the data, and deque<boost::core::typeinfo> to store the data types. Therefore, iterating through the container to get the data for datatype T simply involves iterating through the deque<boost::core::typeinfo> until a type match is found, then casting the void* to a T* for the corresponding index. There are definitely different ways to take the idea, and maybe there is use for multiple types of heterogeneous containers. The way this container is setup has the advantage (depending on your viewpoint) that you do not have to explicit declare what data types the container will store up front. This could be useful in some context where, for instance, you are pulling information from a database where you don't quite know up front whether certain fields will be numeric or character data until you've queried the db. This container can allow you to pop in whatever data-type the result is, without having to explicitly list out every possibility up front. -- James Armstrong

3 2

[predef] Boost build errors using predef-check
by Edward Diener 04 May '15

04 May '15

In my jam file I have: import ../../predef/check/predef : check require : predef-check predef-require ; and in the requirments section of various Boost Build built-in rules I have: [ predef-check "BOOST_COMP_GNUC >= 4.3" : <cxxflags>-std=c++0x ] When I try to process my jamfile I get numerous warnings along the line of: > C:/Programming/VersionControl/modular-boost/libs/vmd/test\../../predef/check/pre > def.jam:61: in predef-check > warning: object is empty > Jamfile.v2:51: in modules.load > C:/Programming/VersionControl/modular-boost/tools/build/src/build\project.jam:32 > 5: in load-jamfile > C:/Programming/VersionControl/modular-boost/tools/build/src/build\project.jam:64 > : in load > C:/Programming/VersionControl/modular-boost/tools/build/src/build\project.jam:14 > 5: in project.find > C:/Programming/VersionControl/modular-boost/tools/build/src\build-system.jam:535 > : in load > C:\Programming\VersionControl\modular-boost\tools\build\src/kernel\modules.jam:2 > 89: in import > C:\Programming\VersionControl\modular-boost\tools\build\src/kernel/bootstrap.jam > :139: in boost-build > C:\Programming\VersionControl\modular-boost\boost-build.jam:17: in module scope > C:/Programming/VersionControl/modular-boost/libs/vmd/test\../../predef/check/pre > def.jam:61: in predef-check > warning: object is empty > Jamfile.v2:52: in modules.load followed eventually by: > C:\Programming\VersionControl\modular-boost\boost-build.jam:17: in module scope > Performing configuration checks > > - 32-bit : yes (cached) > - arm : no (cached) > - mips1 : no (cached) > - power : no (cached) > - sparc : no (cached) > - x86 : yes (cached) > - symlinks supported : yes > C:/Programming/VersionControl/modular-boost/tools/build/src/kernel\modules.jam:1 > 07: in modules.call-in > *** argument error > * rule ../../predef/check/predef.predef_check_action ( targets + : sources + : p > rops * ) > * called with: ( <p..\..\..\bin.v2\check\predef\gcc-mingw-4.9.2\debug\address-mo > del-32\architecture-x86>8bab483dffdbedc6438ba8af0f25a37e.txt : : <abi>ms <actio > n>@../../predef/check/predef%../../predef/check/predef.predef_check_action <addr > ess-model>32 <architecture>x86 <asynch-exceptions>off <auto-index-internal>off < > auto-index-no-duplicates>off <auto-index-section-names>on <auto-index-verbose>of > f <auto-index>off <binary-format>pe <debug-store>object <debug-symbols>on <doxyg > en.doxproc.index>no <doxygen.processor>xsltproc <embed-manifest>on <exception-ha > ndling>on <extern-c-nothrow>off <format>html <hardcode-dll-paths>true <host-os>w > indows <inlining>off <install-dependencies>off <link>shared <log-api>generic <mi > dl-robust>yes <midl-stubless-proxy>yes <optimization>off <os>NT <pch>on <predef- > expression>BOOST_COMP_GNUC >= 4.3 <preserve-test-targets>on <profiling>off <pyth > on-debugging>off <python.interpreter>C:/Utilities/Python278_32\python <python>2. > 7 <rtti>on <runtime-debugging>on <runtime-link>shared <stdlib>native <strip>off > <suppress-import-lib>false <symlink-location>project-relative <target-os>windows > <testing.execute>on <threadapi>win32 <threading>single <toolset-gcc:flavor>ming > w <toolset-gcc:version>4.9.2 <toolset>gcc <user-interface>console <variant>debug > <warnings-as-errors>off <warnings>on <windows-api>desktop : : : : : : : > : : : : : : : : ) > * missing argument sources > C:/Programming/VersionControl/modular-boost/libs/vmd/test\../../predef/check/pre > def.jam:99:see definition of rule '../../predef/check/predef.predef_check_action > ' being called > C:/Programming/VersionControl/modular-boost/tools/build/src/util\indirect.jam:98 > : in indirect.call > C:/Programming/VersionControl/modular-boost/tools/build/src/build\virtual-target > .jam:798: in class(a)action.actualize > C:/Programming/VersionControl/modular-boost/tools/build/src/build\virtual-target > .jam:311: in actualize-action etc. Any ideas of what is wrong ? Without the use of predef-check everything is OK. I have the latest 'develop' for predef and Boost build. I am trying to set gcc in c++11 mode for gcc 4.3 on up in my VMD tests.

3 5

[predef] Using predef-require with OR conditions
by Edward Diener 04 May '15

04 May '15

In a jamfile I would like to use predef-require in OR situatuations so that if any particular predef-definition is true my unit testing rule occurs, else it does not occur: import ../libs/predef/check/predef : require : predef-require ; run some_test.cpp : : : BOOST_COMP_SOME_COMPILER >= n.n.n || other_predef_definiion ; The typical use case for this is to have a unit test for particular version(s) of a compiler or for all other versions of other compilers. Is this possible ?

2 4

[afio] Trouble with examples
by Brian Ravnsgaard Riis 03 May '15

03 May '15

Hi, The first two examples for the AFIO library do not work as written. The "Hello World" example is missing a file_flag::Create[OnlyIfNotExist] flag on the "example_file.txt" op. Otherwise it never creates the file and the rest of the example becomes garbage. The "less toy" example has a bug in the parsing of the input files. It loops, incrementing argc instead of n, as it should. Even after that I cannot get the program to work, and I am unsure exactly what is wrong. The output file for the concatenated inputs is created and "truncated" to the correct size, but no data ever gets written to this file. If I use large files I have seen std::invalid_argument exceptions and even segfaults. I *think* the problem may be related to the buffers; I have tried using a simple std::vector<char> for the file_buffer_type, but this makes no difference. I have not looked at any other examples yet; I think I should get these two working correctly first... Regards, Brian

2 2

Guidance on contributing to BOOST
by Rohith R 03 May '15

03 May '15

Hey All I am Rohith R, a budding developer from BITS Pilani University in India. Having used a lot of libraries from the STL and BOOST of C++ for my work as an application programmer and some data science projects, i wanted to contribute to BOOST by writing some code for it. I also have experience in writing low-level code for Operating Systems and I have written some basic drivers for raspberry pi as well. I want some guidance on this as to where should i start from and on what area should I focus my library on. This is a small implementation of vector i made just for fun. https://github.com/MadaraUchiha-314/Data-Structures-Library/blob/master/Vec… Any kind of help would be appreciated. Thanks A Lot Rohith R

2 1

[function_types] Pull request for library in 'develop'
by Edward Diener 02 May '15

02 May '15

Is there a maintainer for the function_types library ? Tobias Schwinger is listed as the maintainer but I do not believe he has been active in Boost for a long time. I have a pull request for the library. Can someone who has administrative rights for the library please look at it ?

1 0

Re: [boost] Official JSON Package
by Michael Ainsworth 01 May '15

01 May '15

> Is there an official Boost package for reading and writing JSON data? >> >> Not on Boost, I would suggest you the RapidJSON. >> Do not use boost PropertyTree since you will face incompatibilities mainly >> with arrays. Given that JSON is a de-facto standard (along the lines of INI files and the like) would an official addition as a boost library be considered?

8 8

Official JSON Package
by Michael Ainsworth 01 May '15

01 May '15

Is there an official Boost package for reading and writing JSON data? I know of JSON Spirit, but this is not (to my knowledge) official. I also know the Boost.PropertyTree works, but doesnot have full support. Michael

3 2

[date_time] default constructor for period?
by Scott Bailey 01 May '15

01 May '15

I would like to use this: std::deque<boost::posix_time::time_period> But std::deque depends on (as does some of my other code) it's type having a default constructor. I'm surprised it does not already exists. An implementation that seems to work for me is trivial, although I'm not sure it will work for everyone? My changes to 'boost/date_time_time_period.hpp' follow. I have guarded them with DATE_TIME_NO_DEFAULT_CONSTRUCTOR and simply set begin to point_type() and end to begin_ -1; Is this a change worth an eventual release? Thanks, SB --- a/period.hpp 2015-04-29 15:13:28.040930833 -0700 +++ b/period.hpp 2015-04-29 15:15:01.201392793 -0700 @@ -57,6 +57,9 @@ typedef point_rep point_type; typedef duration_rep duration_type; +#if !defined(DATE_TIME_NO_DEFAULT_CONSTRUCTOR) + period(); +#endif // DATE_TIME_NO_DEFAULT_CONSTRUCTOR period(point_rep first_point, point_rep end_point); period(point_rep first_point, duration_rep len); point_rep begin() const; @@ -82,6 +85,16 @@ point_rep last_; }; +#if !defined(DATE_TIME_NO_DEFAULT_CONSTRUCTOR) + //! default constructor + template<class point_rep, class duration_rep> + inline + period<point_rep,duration_rep>::period() : + begin_(point_type()), + last_(begin_ - duration_rep::unit()) + {} +#endif // DATE_TIME_NO_DEFAULT_CONSTRUCTOR + //! create a period from begin to last eg: [begin,end) /*! If end <= begin then the period will be invalid */ -- Scott Bailey

3 5

[property_tree] Co-Maintainer Needed
by Sebastian Redl 01 May '15

01 May '15

H List, It pains me to say that I can't find sufficient time to maintain PropertyTree the way I should. Bugfixes are delayed, regressions appear, and the long-needed documentation improvement is going nowhere. I made a commitment last C++Now to add C++11 support and document the way I did it in order to help other Boost developers, and failed to do so. New features, like proper encoding support or type-preserving JSON parsing simply aren't happening. It's clear that I can't do it alone. So I am looking for help, someone else who cares about the library and can help me with bugfixes and future development. This could be an individual, a group of people, or the community maintenance team, but I definitely need someone if PropertyTree is supposed to continue as a useful part of Boost. Anyone interested or know somebody who would be interested, please let me know. Sebastian

2 1

Re: [boost] Official JSON Package
by John Venarchick 01 May '15

01 May '15

> > ---------- Forwarded message ---------- > From: Michael Ainsworth <michael(a)michaelainsworth.id.au> > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Cc: > Date: Fri, 1 May 2015 08:53:02 +1000 > Subject: [boost] Official JSON Package > Is there an official Boost package for reading and writing JSON data? > > I know of JSON Spirit, but this is not (to my knowledge) official. I also > know the Boost.PropertyTree works, but doesnot have full support. > > Michael About two years ago when there was talk of a GSOC 2013 project for JSON, I posted that I had been working on changes to ptree so that you could have a ptree<string, boost::any> and be able to round trip successfully. At the time no one seemed interested. I think I should be able to recreate what I had done to make it work for you if your use case is DOM centric like Bjorn Reese's post indicates is one of the draw backs of using ptree. -John Venarchick

1 0

[ANN] "Die Boost C++ Bibliotheken", 2nd edition available (German edition)
by Boris Schäling 01 May '15

01 May '15

Just a quick announcement: The 2nd edition of my book "Die Boost C++ Bibliotheken" (German edition) is available. - It introduces 72 Boost libraries. - It contains more than 430 examples. - The print version has 600 pages. - There is also a Kindle, Epub and PDF version. - It's also online: <http://dieboostcppbibliotheken.de/> There is hardly any difference between the German and the English language edition. The German language edition is a bit more up-to-date after the English language edition has been published in September last year. But there is no need to read the book again in case you read the English language edition already. For those who don't know German: The English language edition remains available online at <http://theboostcpplibraries.com/>. Boris

1 0

[CrystaX.NET][multi_index][release] Segfaults with Clang 3.5 on Android
by Joaquin M Lopez Munoz 01 May '15

01 May '15

Hi, Android CrystaX.NET-* testers are segfaulting on some (~65%) of the Boost.MultiIndex tests after successful build. For instance: http://tinyurl.com/jwnfryy The curious thing is that this is Clang 3.5 only, only for some tests and the same tests across the different Android variants. I'd like to help fixing whatever it's required (if anything) in the lib so as to make this work, but the existing info does not provide any clue. Maybe the regression tester maintainer can shed some more light here? Thank you, Joaquín M López Muñoz Telefónica

2 4

[1.58.0] Release candidates available
by Marshall Clow 01 May '15

01 May '15

Release candidate files for 1.58.0 are available at: http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (boost_1_58_0_rc1.7z) = 609ea035fd3b9f1da110f640c9b8d1e6 MD5 (boost_1_58_0_rc1.tar.bz2) = 7edf680e2532a0370bce64e8e847d661 MD5 (boost_1_58_0_rc1.tar.gz) = 0e435db6a5963e58ffa8d7df49ab5846 MD5 (boost_1_58_0_rc1.zip) = a8d1761306a2ea020e92de53a5cae82d Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_58_0.html

21 53

[1.58.0] Adding Oracle Solaris Studio 12.4 to the list of tested compilers
by Aparna Kumta 01 May '15

01 May '15

One of our primary goals has been to get Oracle Solaris Studio C++ compiler listed on the boost website. With this mind, we have been testing the Boost Nightly regression tests for few months now. For the past month have been submitting the results on http://www.boost.org/development/tests/develop/developer/summary.html (look for the SunOS tab). Could the Oracle Solaris Studio C++ compiler be added to the boost website under 'COMPILERS TESTED' section at http://www.boost.org/users/history/version_1_58_0.html ? Thanks, Aparna

4 6

[githelp] Moving from push to pull requests
by Fletcher, John P 30 Apr '15

30 Apr '15

I have been working for some time on boost phoenix using git push origin develop to push my changes. I have now been asked to change to use pull requests and I am not clear about how to get into the new setup. My current setup on my local computer has phoenix as a subproject in a complete boost clone with branches develop, master and several other branches. I have not created any branches on the remote repository. What I want is to have a repository where I can work and then send pull requests for things to go to the main develop. I have two ideas about how this could be done. (1) create a separate repository outside the modular structure and put a copy of phoenix there. I have created an empty structure called phoenix_changes both on my local computer and under my user name on github. I am puzzled as to how to get the correct content into it. This could come from my local copy or from the main repository. (2) Should I instead create a new branch in both my local and the remote copies of boost/phoenix? If so how do I do that? Can I branch from the current develop as the starting point? In either case I want to be able to send pull requests to the other developers. It would be helpful to have an example of the commands needed. Please ask me for more information if this is not clear. Thank you for the [githelp] resource. John

6 7

[Boost] Windows 10 Building/Testing
by Kyle Ketterer 30 Apr '15

30 Apr '15

Hey all, I was just curious if any devs/users have tried to compile/build on any of the Windows 10 preview releases and if there is a plan to support moving forward. I have been using Boost in various projects for 4-5 years and I am actually interested in getting involved in this project somehow. What is the most appropriate way to become involved? I really appreciate the skill level here and if anything would love the learning experience (learning from the best). Thanks

1 0

[gsoc15] This year's GSoC students
by Niall Douglas 29 Apr '15

29 Apr '15

Dear Boost, It is our pleasure to announce this year's winning GSoC students and projects: 1. Damian Vicino Topic: Safe Float (boost::safe_numerics<float>) Mentor: Robert Ramey 2. Rajaditya Mukherjee Topic: Boost uBLAS EigenSolver Mentor: David Bellot 3. Anurag Ghosh Topic: Boost Document Library Mentor: Antony Polukhin 4. Nikhar Agrawal Topic: Boost.Fixed-Point Mentor: Paul A. Bristow 5. Benedek Thaler Topic: Enhanced vector and deque containers Mentor: Thorsten Ottosen 6. Louis Dionne Topic: Improved compile-time associative data structures for Hana Mentor: Joel Falcou 7. Jakub Szuppe Topic: Improving Boost.Compute Mentor: Kyle Lutz Congratulations to these students for passing an exceptionally tough contest this year, and our thanks to the above mentors for making themselves available. Finally, thank you Google for another year of funding and to those open source orgs who released duplicate students to us, we appreciate it! Niall and Boris --- Boost C++ Libraries Google Summer of Code 2015 admin https://svn.boost.org/trac/boost/wiki/SoC2015

5 4

Updated library_status for easier use..
by Rene Rivera 29 Apr '15

29 Apr '15

Following up on the reorganization of the regression tools.. I'm happy to say that part of the changes I pushed last night include a cleaned up and easier to use library_status tool. Key changes, from the older version and the one Robert forked, are: * Processing the jam log (i.e. process_jam_log) is integrated into it. * Running b2 to build/run tests is also integrated into it (optionally). Which means that there's no external support script(s) needed and that it's fully cross-platform single executable. Documentation is updated at < https://rawgit.com/boostorg/regression/develop/index.html> on how to build it and on using it at < https://rawgit.com/boostorg/regression/develop/library_status/doc/library_s… >. Obviously improvements from others welcome (as PRs). HTH -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

[trac] Internal error
by Edward Diener 28 Apr '15

28 Apr '15

I logged into Boost trac and received: " Trac detected an internal error: OperationalError: database is locked There was an internal error in Trac. It is recommended that you notify your local Trac administrator with the information needed to reproduce the issue. To that end, you could a ticket. The action that triggered the error was: GET: /login"

1 0

[regex] Change format of data in file
by Fu ji 28 Apr '15

28 Apr '15

Hello all, I have file output.txt, in file we can find something like: 01/01/2015 15:00:00 2222.2222 2222.2222 2222.2222 2222.2222 04/04/2015 15:00:00 2222.2222 and i would like to change format from DD/MM/RRRR HH:MM:SS to RRRR-MM-DD HH:MM:SS.000 using boost regex. But I have no clue how should I type pattern and replace them with another. Anyone have knowledge about boost regex and could help me ? Best regards

2 2

[date_time] Ordering non-overlapping time period
by Arindam Mukherjee 28 Apr '15

28 Apr '15

The documentation for time_period suggests that for two periods tp1 and tp2, tp1 < tp2 if tp1.end() < tp2.begin() i.e. !tp1.intersects(tp2). http://www.boost.org/doc/libs/1_58_0/doc/html/date_time/posix_time.html#dat… But I can see that the following works: time_period tp1(second_clock:local_time(), hours(2)); time_period tp2(second_clock:local_time() + hours(1), hours(2)); assert(tp1.intersects(tp2)); assert(tp1 < tp2); The behavior seems legit - tp1.begin() < tp2.begin()/ The documentation says nothing about overlapping periods. Arindam

1 1

[test] floating point comparison
by Emil Dotchevski 28 Apr '15

28 Apr '15

Hello, Can someone please tell me exactly what do I need to include and which namespace to use to get exact same behavior as: #include <boost/test/floating_point_comparison.hpp> bool check( float a, float b, float tolerance ) { using namespace boost::test_tools; return check_is_close(a,b,fraction_tolerance(tolerance)); } (The above used to work with older Boost versions but no longer.) Thanks, Emil

5 8

[boost, config, context, log, 1.58] address-model and architecture detection
by Vladimir Prus 28 Apr '15

28 Apr '15

Hi, for some time on develop, top-level Jamroot used to deduce address-model and architecture from compiler. The only issue was that both properties would be added to targets paths when not necessary. Fix for that has been just committed, for develop: https://github.com/boostorg/boost/commit/945e3c0bbdd31ce8c297e0aff5340f0adb… and I performed these operations on master: - Merged all of Boost.Build changes: https://github.com/boostorg/build/commit/2e764707e03d25b6928501c25a717e195c… - Cherry-picked one Boost.Context change: https://github.com/boostorg/context/commit/9b392c68b59021aa4801dcb245bc64ad… - Cherry-picked one Boost.Log change: https://github.com/boostorg/log/commit/27a822a6b82f8bf34cbc681ac6583412bdf2… - Cherry-picked two root project changes and updated pointers to Context and Log: https://github.com/boostorg/boost/commit/e3bc35f7891e72ad74e57dc216db899d16… https://github.com/boostorg/boost/commit/beb53b6b9574f95309384bfc5afffb40d4… https://github.com/boostorg/boost/commit/b69a072401695c9978085158af4c1ea84c… With that, "./b2 -n" in up-to-date checkout of superproject works fine on Linux. Also, "./b2 -n --with-context --with-system" works fine, no address-model elements in path. Putting explicit address-model=64 does not change path. Putting explicit address-model=32 does add this element to path, as expected. Note that: - I did not merge any other Boost.Context or Boost.Log changes. - Nothing was required for Boost.Config, since it was merged earlier. I'd appreciate if people test current state of master branch, and report any concerns. Thanks, -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

16 44

[afio] Compilation error in applications, including tests
by Brian Ravnsgaard Riis 27 Apr '15

27 Apr '15

Hi, I wanted to try out the proposed AFIO library, but I'm having trouble with compilation. I followed the instructions for inserting it into the boost checkout, by symlinking libs/afio to the AFIO checkout. Boost compilation happens correctly, including the AFIO library, however I get include failures on BindLib when I try to compile a test program. I then tried running the test suite, as per instructions: $ ./b2 libs/afio/test [snip] gcc.compile.c++.pch bin.v2/libs/afio/test/gcc-4.9.1/debug/threading-multi/test_functions.hpp.gch In file included from ./boost/afio/spinlock/include/boost/spinlock/concurrent_unordered_map.hpp:35:0, from ./boost/afio/config.hpp:341, from ./boost/afio/afio.hpp:41, from libs/afio/test/test_functions.hpp:17: ./boost/afio/spinlock/include/boost/spinlock/spinlock.hpp:81:36: fatal error: bindlib/include/import.h: No such file or directory #include "bindlib/include/import.h" ^ compilation terminated. ... And more of the same ilk. Am I missing some obvious configuration or something? The boost version is at tag boost-1.58.0 and AFIO is at tag v1.31_Boost_v1.58. The BindLib submodule does contain include/import.h. Regards, Brian

2 2

[Property Tree] No documentation for <boost/property_tree/ptree.hpp>
by Nevin Liber 27 Apr '15

27 Apr '15

At < http://www.boost.org/doc/libs/1_58_0/doc/html/property_tree/reference.html#…> The entry for "Header <boost/property_tree/ptree.hpp>" is blank. It looks like a 1.58 bug. Kind regards, Nevin :-) -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

1 0

1.58.1 bugfix release necessary?
by Oliver Kowalke 27 Apr '15

27 Apr '15

Unfortunately boost.context fails to compile for gcc-4.8.x and option -std=c++11. Because of a dependency to boost.context, boost.asio and boost.coroutine do not compile too. I've pushed a pull-request to boost.config - the patch adds C++14 test macro BOOST_NO_CXX14_INTEGER_SEQUENCE ( https://github.com/boostorg/config/pull/57) Oliver

14 20

Review request for DLL
by Antony Polukhin 27 Apr '15

27 Apr '15

Hi, Me and Vladimir Prus (review manager) have agreed to start the review of the the DLL library on the June 29. We also agreed that a two weeks review period is required. So the review must go till July 12. Ronald, please adjust the review schedule if there's no objections. -- Best regards, Antony Polukhin

1 0

[vmd] Getting regression tests
by Edward Diener 27 Apr '15

27 Apr '15

I created a pull request for boostorg/boost so that VMD is added to the regression tests. It has been sitting there for a long time now. Can someone at the Boost superproject level please address this pull request ? I want to have VMD added as a library in the next Boost release.

1 0

Boost 1.58.0 has been released
by Marshall Clow 26 Apr '15

26 Apr '15

Release 1.58.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 two new libraries and numerous enhancements and bug fixes for existing libraries. New Libraries * Endian: Types and conversion functions for correct byte ordering and more regardless of processor endianness. * Sort: Includes spreadsort, a general-case hybrid radix sort that is faster than O(n*log(n)) For details, including download links, see http://www.boost.org/users/news/version_1.58.0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.58.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Vladimir Prus Rene Rivera Marshall Clow Eric Niebler Daniel James Beman Dawes

13 17

[interprocess] condition variables and spurious wakeups
by eg 26 Apr '15

26 Apr '15

Hi, I was hoping to get some clarification on whether the boost::interprocess library implementation of condition variables is susceptible to spurious wake ups. Most other library implementations (pthreads, boost::thread, std::thread) seem to be and are documented as such. I couldn't find any mention in the interprocess documentation nor find anything definitive in my google searching. Thanks in advance, Ed

2 1

Latest dependency report
by Peter Dimov 25 Apr '15

25 Apr '15

... generated from the develop branch: http://www.pdimov.com/tmp/report-develop-c3bb6eb/module-overview.html http://www.pdimov.com/tmp/report-develop-c3bb6eb/module-levels.html http://www.pdimov.com/tmp/report-develop-c3bb6eb/module-weights.html

2 2

[boost_document_library] [GSoC'15] How to Start? Any standards to follow?
by Abhinav Tripathi 25 Apr '15

25 Apr '15

Hello, I have finally set up my development environment on Ubuntu 14.10 x64... I am now able to compile any program consisting of Both OpenOffice and Boost code. I have made succesfully small examples with multiple files with both boost and OpenOffice sdk code and compiled them. . I am now ready to start writing code for the document library. What i could think of till now is : 1. Make the project on github and keep it synced 2. Separate classes in different headers with proper namespaces . What i am looking for : 1. Any suggestions on how to start! (More specifically) 2. Are there and standards that need to be followed for developing any library for boost (like using or not using some syntaxes &/or libraires) 3. Any suggestions as to what practices i should use, like which syntaxes/libraries to prefer. . Also, i see that all the boost libraries are independent (i.e., only dependence is within boost itself) [as far as i know]. While what i will be writing will depend on OpenOffice sdk. So, what are its chances to be accepted as an "actual boost library"? . Regards, Abhinav

4 5

tokenizer for overlapping delimiters?
by Jorge Cardoso Leitão 25 Apr '15

25 Apr '15

Dear boost devs, I'm writing here because I've been coding a tokenizer that I believe, given its generality, could be an addition to Boost. I'm asking for a judgement on whether the idea has room in boost or not. The interface I'm proposing is a function of two arguments, a string (call it text) and a set of strings (call it key-terms), that returns a vector<string> (call it result) which fulfils 4 constraints: 1. a string in the result can only be either a key-term or a string between two key-terms; 2. the concatenation of the result is always the original text; 3. a key-term containing other key-terms has priority over the latter; 4. a key-term overlapping other has priority based on its position in the text A tokenizer that divides a string by delimiters is a subset of this interface whose key-terms are the delimiters. This is considered in Boost.Tokenizer, where the key-terms are *non-overlapping. *The critical addition here is the ability to deal with *overlapping key-terms*. A common use case of overlapping key-terms is when you have key-terms that you want to consider as single tokens but they overlap with common delimiters. A practical example: tokenize a string (with words separated by spaces) and guarantee that both `"United States of America"` and `"United States of Brazil"` are interpreted as single tokens. The non-triviality appears because such feat requires storing which key-terms are using a previous sub-string, and how to reverse in case the match fails. (e.g. "United States of " is common to both terms above, but once the first letter appears, either one or both can be discarded as potential matches). Some examples in pseudo-code (see how they fulfil constraints 1-4) tokenize("the end", {}) --> {"the end"} tokenize("the end", {" "}) --> {"the", " ", "end"} tokenize("foo-bar", {"foo", "foo-bar"}) --> {"foo-bar"} tokenize("the end", {"the e", " ", "end"}) --> {"the e", "nd"} tokenize("foo-tars ds", {"foo", "foo-bar", "-tar"}) --> {"foo", "-tar", "s ds"} As a proof of concept, I've implemented such interface and respective test cases, which you can find in https://github.com/jorgecarleitao/tokenize. Any change is possible to accommodate to boost standards: this can be generalized to arbitrary sequences, to arbitrary types, and to use iterators, documented, better tested etc. But before anything else, I would like to ask for an opinion on whether this is sufficiently general and useful to be considered to boost. Thank you for your time, Best regards, Jorge

2 2

Description of pre-requisites for building Boost 1.58.0?
by Marko Asplund 25 Apr '15

25 Apr '15

Hi, While trying to build Boost on Ubuntu 14.04.2 LTS I noticed that the build failed because some library dependencies were missing on my system. I was unable to find documentation about library dependencies and other pre-requisites for building Boost. Are these documented somewhere? Some build related info can be found here, but I couldn't find info about required libraries: http://www.boost.org/doc/libs/1_58_0/more/getting_started/unix-variants.html I was able to build Boost after installing libpython-dev, libbz2-dev packages. This was with default Boost configuration, so other libraries may be required for custom configurations. marko

2 1

[CMT] List of libraries being maintained
by Edward Diener 24 Apr '15

24 Apr '15

Is there a list of libraries being maintained by the community maintenance team ?

3 2

[config] Configuring for C++14 and later library features.
by John Maddock 24 Apr '15

24 Apr '15

Folks, I have an open PR for adding BOOST_NO_CXX14_INTEGER_SEQUENCE (https://github.com/boostorg/config/pull/58) Unfortunately, the correct way to check for std::integer_sequence is to include <utility> and then check for __cpp_lib_integer_sequence. The problem is that we went to some lengths to remove dependencies on <utility> in https://github.com/boostorg/config/pull/40. Further, if we get requests for more such feature-detection macros, we would end up including the whole std lib (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745#recs.cpp14) This doesn't look acceptable to me, but what to do? The only solution I can see is to simply not support these features in Boost.Config, but rather rely on users needing these features checking the std detection macros directly. Which will work up until someone implements a feature without defining the appropriate macro :( Thoughts? Thanks, John.

7 10

Re: [boost] [thread] Windows compilation broke with 8853a4c
by Jürgen Hunold 24 Apr '15

24 Apr '15

Hi Vicente, On Mittwoch, 22. April 2015 22:50:05 Vicente J. Botet Escriba wrote: > I have rolled back the changes. Please let me know if it works now on > develop. Yes, everything is working again. 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

Git tag for 1.58
by Brian Ravnsgaard Riis 24 Apr '15

24 Apr '15

Hi, 1.58 is still not tagged in the git repo. Does anyone know the sha1 of the relevant commit...? Regards, Brian

1 0

[config] gcc,msvc,mingw visibility
by Robert Ramey 24 Apr '15

24 Apr '15

I've been enabling limited gcc visibility so that it works similarly to msvc *_DECL attributes and will export from the DLL/DSO only those symbols which need to be exported. I've had a lot of difficulty with this. I followed the instructions http://www.boost.org/doc/libs/1_58_0/libs/config/doc/html/boost_config/boos… which more or less boil down to using BOOST_SYMBOL_EXPORT when functions are exported, BOOST_SYMBOL_IMPORT when functions are imported, and BOOST_SYMBOL_VISIBLE on class declarations. I set my Jamfile.v2 in the library build to enable gcc visibility=hidden and let her rip. After the more or less normal back and forth it seemed that the library built and work on all platforms/compilers. .... EXCEPT Mingw. Hmmmm - this shouldn't be too tough, just look at how the other libraries did it. Turns out that it seems that no boost libraries actually enable gcc visibility in their builds - at least as far as I can tell. (I didn't dig into the depths of jam tools files). After a fair amount of research I concluded that for windows platforms - regardless of whether they are built with minnow (gcc) or mdvc, one needs to define BOOST_SYMBOL_VISIBLE as BOOST_SYMBOL_IMPORT or BOOST_SYMBOL_IMPORT which of course makes things more complicated. So here is what I came up with. My questions are: a) did I do this right? b) is there a simpler way c) if the answer to the above is no - can the documentation be updated? Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/config-gcc-msvc-mingw-visibility-tp46747… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 3

[boost.serialization] Problem when serializing a wide char on version 1.58.0
by Marco Oman 23 Apr '15

23 Apr '15

Hi to all, I am having a problem with boost serialization on version 1.58.0 The code at the end of the post is nearly the same found at the beginning of the page libs/serialization/doc/index.html (the 'Very simple case'). The only relevant difference is the use of the wide char version of archive (and fstream) and an additional 'name' text field in the sample structure. This text contains a cyrillic character (the capitol 'D') The problem I am having with this code is that it throws an exception when using version 1.58.0, while everything is OK if I compile/link against version 1.57.0 The problem seems to be related with character conversion: the library seems to convert non ascii chars to local default codepage, instead of UTF-8. So everything looks fine as long as I use characters convertable to my codepage. I gave a look at the differencies between the two versions, but they are definitely beyond my reach... Tests done on windows with MSVC2013 and MSVC2008 Marco #include <fstream> // include headers that implement a archive in simple text format #include <boost/archive/text_woarchive.hpp> #include <boost/archive/text_wiarchive.hpp> ///////////////////////////////////////////////////////////// // gps coordinate // // illustrates serialization for a simple type // class gps_position { private: friend class boost::serialization::access; // When the class Archive corresponds to an output archive, the // & operator is defined similar to <<. Likewise, when the class Archive // is a type of input archive the & operator is defined similar to >>. template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & degrees; ar & minutes; ar & name; ar & seconds; } int degrees; int minutes; std::wstring name ; float seconds; public: gps_position(){}; gps_position(int d, int m, float s, const std::wstring &n) : degrees(d), minutes(m), seconds(s), name(n) {} }; int main() { // create and open a character archive for output std::wofstream ofs("filename"); // create class instance const gps_position g(35, 59, 24.567f, L"AДbc"); // save data to archive { boost::archive::text_woarchive oa(ofs); // write class instance to archive oa << g; // archive and stream closed when destructors are called } // ... some time later restore the class instance to its orginal state gps_position newg; { // create and open an archive for input std::wifstream ifs("filename"); boost::archive::text_wiarchive ia(ifs); // read class state from archive ia >> newg; // archive and stream closed when destructors are called } return 0; }

1 0

[OpenOffice] [Boost_Document_Library] [GSoC'15] Unable to compile and run the examples in the OpenOffice SDK
by Abhinav Tripathi 23 Apr '15

23 Apr '15

I know this question should be sent to OpenOffice forum. I sent it to their dev list but did not get any response so i am mailing it here in hope to get a response. . I downloaded The OpenOffice 4.1.1 deb files and Sdk 4.1.1 deb file... I used dpkg from command line to install all the deb files.. They got installed in /opt/openoffice4 and Sdk in /opt/openoffice4/sdk . I had to use deb files from the website because i couldn't download it from the apt-get... It showed errors like could not find... I am Using Ubuntu 14.10! When i tried to compile any example in /opt/openoffice4/sdk/examples/DevelopersGuide/ProfUNO/ i got many errors.. . To overcame some of these i did : 1. copied all files from /opt/openoffice4/sdk/bin/ to my root folder /bin/ because the error said /bin/cppumaker : command not found 2. Used a conf file to load all libraries in linux linker cache... using sudo ldconfig because g++ showed error that libreg.so.3 was not found! 3. copied the types.rdb file from sdk folder to my root folder / because it said something about registries not loaded. 4. made a few variables in the makefile like OO_SDK_HOME, JAVA_HOME, JAVA_BIN to allow compilation... 5. Made folder for each example in /opt/openoffice4/sdk/LinuxExamples.out/bin folder because g++ always gave the error that the there was no file or folder of the name of the example that i was compiling. . Now, i am able to compile the examples but when i try to run them with : make office_connect.run or anything like that then again i am getting errors regarding command not found. cd ../../../../LINUXexample.out/bin && office_connect /bin/sh: 1: office_connect: not found Makefile:100: recipe for target 'office_connect.run' failed make: *** [office_connect.run] Error 127 I think it is because of this line in the makefile : %.run: $(OUT_BIN)/%$(EXE_EXT) cd $(subst /,$(PS),$(OUT_BIN)) && $(basename $@) I have no experience of Makefiles and also i am new to openoffice sdk... I am guessing that these errors are happening beacause i installed the packages manually from dpkg instead of using apt-get... Also, i did use setsdkenv_unix once but i think it didnt work as expected as the variables in Makefile are NOT set.. . . It took me nearly a week to figure out these errors and now my patience is wearing out. I know that there has to be an elegant solution to this problem. Please help! . Abhinav

2 4

[Git] Pull requests and rebasing
by John Maddock 22 Apr '15

22 Apr '15

So I have a rebase vs pull question: Lets say I have a PR, if I merge that to my local tree using "git pull --rebase remote-repro branch-name" then I get a nice clean history locally without those pesky merge commits cluttering everything up. But... Now I can't fast-forward when I push to the remote, *because I've changed the existing history of the develop branch*. Would this not be a) bad form, and b) potentially dangerous to push to the remote develop branch? Still don't understand Git yours, John.

6 7

[typeof][CMT] Could the maintenance team please review and merge a trivial pull request?
by Adam Wulkiewicz 22 Apr '15

22 Apr '15

Hi, There is one trivial PR hanging for nearly a year now: https://github.com/boostorg/typeof/pull/1 In those 2 lines of code namespace boost was explicitly added in front of enable_if and disable_if. This allows msvc8 to compile the tests when Boost.Test and Boost.TypeOf are both used. Could you please have a look at it? Regards, Adam

3 4

Re: [boost] [ValueRef] Interest in a new library for immutable values with internal sharing?
by Thomas Jordan 22 Apr '15

22 Apr '15

> Message: 2 > Date: Mon, 20 Apr 2015 15:40:37 +0100 > From: Sam Kellett<samkellett(a)gmail.com> > > To:boost@lists.boost.org > Subject: Re: [boost] [ValueRef] Interest in a new library for > immutable values with internal sharing? > Message-ID: > <CAHK+-Fsy1-sCuMuz+hpjNC2ogAbxUazNY0Qt3xL__bndzkwduw(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > I had a similar idea for a new smart pointer that would aim to obsolete the > shared_ptr-to-const idiom. The problem I found with that idiom is that it > only guarantees that you can't change it. There's no promise that somebody > else doesn't have a non-const ref to the data and so it could in the worst > case completely change from under your feet (even if you know it won't get > destroyed). ValueRef doesn't expose (shared) pointers/pointees, they are a hidden, implementation detail. Its interface just deals in values (as shown in the example usage).

3 2

Re: [boost] [ValueRef]
by THOMAS JORDAN 22 Apr '15

22 Apr '15

> Message: 7 > Date: Tue, 21 Apr 2015 15:37:56 +0000 (UTC) > From: Joaquin M Lopez Munoz <joaquin(a)tid.es> > To: boost(a)lists.boost.org > Subject: Re: [boost] [ValueRef] > Message-ID: <loom.20150421T164358-569(a)post.gmane.org> > Content-Type: text/plain; charset=utf-8 > THOMAS JORDAN <tomjordan766 <at> gmail.com> writes: > > > > > Message: 7 > > > Date: Mon, 20 Apr 2015 18:39:57 +0000 (UTC) > > > From: Joaquin M Lopez Munoz <joaquin <at> tid.es> > > > > > Boost.Flyweight uses move semantics and perfect fwd ction where > > > available, > > > I don't see how another solution can do better on this front > > > > Agreed, I'll withdraw that statement. However, as I said in the O.P., the > > ValueRef implementation I have done is currently only C++03. It uses a > > combination of N x forwarding constructor overloads taking arguments by > > const reference, and the client can use reference wrappers to forward to > > lvaluesto do the non-perfect forwarding (as boost.shared_ptr make_shared > > does) . The intention in the final library would be to support > > C++11/perfect forwarding and possibly Boost.Move for C++03 move semantics. > > So they would be equivalent in that regard. > Understood. Boost.Flyweight does in fact this something similar, > you might want to take inspiration from > http://boost.org/boost/flyweight/detail/perfect_fwd.hpp > > > Boost.Flyweight is indeed heavier on the include side than some > > > people might be comfortable with. > > > > I think this is my concern with having Boost Flyweight as the only option > > for what is a relatively simple type. ValueRef is currently about 350 > > lines of easy-to-understand code in a single header file, and has no > > dependencies on MPL or any other Boost or std libraries, with the > > exception of an atomic library. > > It is intended in particular as a lightweight, clean replacement for > > shared-ptr-to-const, which I see used a lot in code [...] > Of course I don't want to disregard the merit of a lightweight approach > to implementing this idiom. I'm curious: why are you implementing > this from scracth, using atomic etc. rather than wrapping > boost::shared_ptr? The latter, seems to me, is going to be much less > code on your side and the dependencies on the lib are not that many: > http://www.pdimov.com/tmp/report-b1adfee/smart_ptr.html I was inaccurate when I said that ValueRef did not depend on any std libraries, in fact it depends on <memory> for std::allocator<T>. I've modified it to use boost::shared_ptr and boost::allocate_shared (though still just with C++03 forwarding constructors at the moment) - it was trivial, and reduces the LOCS by ~half. > Joaqu?n M L?pez Mu?oz > Telef?nica Tom

1 0

Re: [boost] [Boost-bugs] [Boost C++ Libraries] #11225: failed to compile with msvc8, variadics used wrong
by Damien Buhl 22 Apr '15

22 Apr '15

Thanks Flast, Normally only warnings should be generated. Did you had warnings as errors active? Original Message ‎ From: Boost C++ Libraries Sent: mercredi 22 avril 2015 15:32 Reply To: boost(a)lists.boost.org Cc: boost-bugs(a)lists.boost.org Subject: Re: [Boost-bugs] [Boost C++ Libraries] #11225: failed to compile with msvc8, variadics used wrong #11225: failed to compile with msvc8, variadics used wrong -------------------------+------------------------------------------------- Reporter: | Owner: djowel ingo.loehken@… | Status: new Type: Bugs | Component: fusion Milestone: To Be | Severity: Regression Determined | Keywords: BOOST_PP_IS_EMPTY, phoenix vector, Version: Boost | variadics, vs2005, mscv8 1.58.0 | Resolution: | -------------------------+------------------------------------------------- Comment (by Kohei Takahashi <flast@…>): rels. to #11157 -- Ticket URL: <https://svn.boost.org/trac/boost/ticket/11225#comment:1> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries. _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-bugs

2 1

[thread] Windows compilation broke with 8853a4c
by Jürgen Hunold 22 Apr '15

22 Apr '15

Hi Vicente, the commit 8853a4cbdf34d2699d7997ea99adf62fe9d6d568 broke compilation on windows: compile-c-c++ E: \dev\devel\boost\bin.v2\libs\thread\test\test_barrier_void_fct.test\msvc-12.0\debug\test_barrier_void_fct.obj test_barrier_void_fct.cpp E:\dev\devel\boost\boost/thread/win32/condition_variable.hpp(344) : error C2039: 'is_pos_infinity' : is not a member of 'boost::xtime' E:\dev\devel\boost\boost/thread/xtime.hpp(35) : see declaration of 'boost::xtime' E:\dev\devel\boost\boost/thread/win32/condition_variable.hpp(349) : error C2039: 'is_special' : is not a member of 'boost::xtime' E:\dev\devel\boost\boost/thread/xtime.hpp(35) : see declaration of 'boost::xtime' It seems you are calling Boost.DateTime special functions on boost::xtime variables. I'm not sure on how to fix this. The change has not been pickup by the regression matrix yet. 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

[github] contribution activity not updated
by Joaquin M Lopez Munoz 22 Apr '15

22 Apr '15

Hello, Not that this is very important, but seems like, at least for my GitHub user account, the contribution dashboard is not being updated: if you go to the bottom of https://github.com/joaquintides you'll see the dashboard says I haven't committed anything since Feb 23, which is certainly not the case. Just reporting here in case this might be a symptom of some more serious internal problem with the tool or the repository. Joaquín M López Muñoz Telefónica

2 2

[iostreams] Bogus gzip_alloc in gzip_test.cpp
by Stephan T. Lavavej 21 Apr '15

21 Apr '15

Hi, While testing VC 2015 with Boost, we've discovered a bug in Boost.Iostreams' tests. boost_1_58_0\libs\iostreams\test\gzip_test.cpp contains: struct gzip_alloc : std::allocator<char> { }; This doesn't conform to C++98-17's allocator requirements, because it isn't properly rebindable. (The Standard has always required that rebinding MyAlloc<T> to U and back to T produces MyAlloc<T>.) Thanks, STL

1 0

[polygon] polygon_traits.hpp is incompatible with C++17 std::size()
by Stephan T. Lavavej 21 Apr '15

21 Apr '15

Hi, While testing VC 2015 with Boost, we found that Boost.Polygon contains unqualified calls to non-member size() which are incompatible with C++17's std::size(). Specifically, lines 617 and 703 of boost\polygon\polygon_traits.hpp say: points.reserve(size(polygon)); The argument appears to be "typedef std::list<CPoint> CPolygon;" which is why ADL is considering std::size(). (Note that VC's current lack of Expression SFINAE is not relevant here, as std::size() is viable for std::list.) Here's the full error output (including a new shadow warning): C:\Temp>cl /EHsc /nologo /W4 /wd4100 /MTd /I C:\Temp\boost-1.58.0\include boost_1_58_0\libs\polygon\example\gtl_custom_polygon.cpp gtl_custom_polygon.cpp Unknown compiler version - please run the configure tests and report the results c:\temp\boost-1.58.0\include\boost\polygon\detail/property_merge.hpp(286): warning C4458: declaration of 'output' hides class member c:\temp\boost-1.58.0\include\boost\polygon\detail/property_merge.hpp(223): note: see declaration of 'boost::polygon::merge_scanline<coordinate_type,property_type,polygon_set_type,keytype>::output' c:\temp\boost-1.58.0\include\boost\polygon\detail/property_merge.hpp(584): note: see reference to class template instantiation 'boost::polygon::merge_scanline<coordinate_type,property_type,polygon_set_type,keytype>' being compiled c:\temp\boost-1.58.0\include\boost\polygon\polygon_traits.hpp(617): error C2668: 'boost::polygon::size': ambiguous call to overloaded function c:\temp\boost-1.58.0\include\boost\polygon\polygon_traits.hpp(478): note: could be 'unsigned int boost::polygon::size<polygon_type>(const T &)' with [ polygon_type=CPolygon, T=CPolygon ] \\vcfs\builds\VS\feature_WCFB01\1457423\binaries.x86ret\inc\xutility(1347): note: or 'unsigned int std::size<polygon_type>(const _Container &)' [found using argument-dependent lookup] with [ polygon_type=CPolygon, _Container=CPolygon ] c:\temp\boost-1.58.0\include\boost\polygon\polygon_traits.hpp(617): note: while trying to match the argument list '(CPolygon)' boost_1_58_0\libs\polygon\example\gtl_custom_polygon.cpp(38): note: see reference to function template instantiation 'std::list<CPoint,std::allocator<_Ty>> &boost::polygon::convolve<Polygon,CPoint>(polygon_type &,const point_type &)' being compiled with [ _Ty=CPoint, Polygon=CPolygon, polygon_type=CPolygon, point_type=CPoint ] boost_1_58_0\libs\polygon\example\gtl_custom_polygon.cpp(144): note: see reference to function template instantiation 'void test_polygon<CPolygon>(void)' being compiled c:\temp\boost-1.58.0\include\boost\polygon\polygon_traits.hpp(703): error C2668: 'boost::polygon::size': ambiguous call to overloaded function c:\temp\boost-1.58.0\include\boost\polygon\polygon_traits.hpp(478): note: could be 'unsigned int boost::polygon::size<polygon_type>(const T &)' with [ polygon_type=CPolygon, T=CPolygon ] \\vcfs\builds\VS\feature_WCFB01\1457423\binaries.x86ret\inc\xutility(1347): note: or 'unsigned int std::size<polygon_type>(const _Container &)' [found using argument-dependent lookup] with [ polygon_type=CPolygon, _Container=CPolygon ] c:\temp\boost-1.58.0\include\boost\polygon\polygon_traits.hpp(703): note: while trying to match the argument list '(CPolygon)' boost_1_58_0\libs\polygon\example\gtl_custom_polygon.cpp(40): note: see reference to function template instantiation 'std::list<CPoint,std::allocator<_Ty>> &boost::polygon::scale_up<Polygon>(polygon_type &,boost::polygon::coordinate_traits<int>::unsigned_area_type)' being compiled with [ _Ty=CPoint, Polygon=CPolygon, polygon_type=CPolygon ] Thanks, STL

1 0

Re: [boost] Feedback on Boost.Http
by Brian Wood 21 Apr '15

21 Apr '15

Bjorn Reese writes: > I am using Boost.Http in an embedded application, albeit work on the > integration has been slow due to company priorities. I see. Perhaps the author of the library would be willing to support you in that rather than creating his own applications. That's how I hope to do things also - http://webEbenezer.net/about.html . -- Brian Ebenezer Enterprises - So far G-d has helped us. http://webEbenezer.net

1 0

Re: [boost] [ValueRef]
by THOMAS JORDAN 21 Apr '15

21 Apr '15

> Message: 7 > Date: Tue, 21 Apr 2015 15:37:56 +0000 (UTC) > From: Joaquin M Lopez Munoz <joaquin(a)tid.es> > To: boost(a)lists.boost.org > Subject: Re: [boost] [ValueRef] > Message-ID: <loom.20150421T164358-569(a)post.gmane.org> > Content-Type: text/plain; charset=utf-8 > THOMAS JORDAN <tomjordan766 <at> gmail.com> writes: > > > > > Message: 7 > > > Date: Mon, 20 Apr 2015 18:39:57 +0000 (UTC) > > > From: Joaquin M Lopez Munoz <joaquin <at> tid.es> > > > > > Boost.Flyweight uses move semantics and perfect fwd ction where > > > available, > > > I don't see how another solution can do better on this front > > > > Agreed, I'll withdraw that statement. However, as I said in the O.P., the > > ValueRef implementation I have done is currently only C++03. It uses a > > combination of N x forwarding constructor overloads taking arguments by > > const reference, and the client can use reference wrappers to forward to > > lvaluesto do the non-perfect forwarding (as boost.shared_ptr make_shared > > does) . The intention in the final library would be to support > > C++11/perfect forwarding and possibly Boost.Move for C++03 move semantics. > > So they would be equivalent in that regard. > Understood. Boost.Flyweight does in fact this something similar, > you might want to take inspiration from > http://boost.org/boost/flyweight/detail/perfect_fwd.hpp Ok > > > Boost.Flyweight is indeed heavier on the include side than some > > > people might be comfortable with. > > > > I think this is my concern with having Boost Flyweight as the only option > > for what is a relatively simple type. ValueRef is currently about 350 > > lines of easy-to-understand code in a single header file, and has no > > dependencies on MPL or any other Boost or std libraries, with the > > exception of an atomic library. > > It is intended in particular as a lightweight, clean replacement for > > shared-ptr-to-const, which I see used a lot in code [...] > Of course I don't want to disregard the merit of a lightweight approach > to implementing this idiom. I'm curious: why are you implementing > this from scracth, using atomic etc. rather than wrapping > boost::shared_ptr? The latter, seems to me, is going to be much less > code on your side and the dependencies on the lib are not that many: > http://www.pdimov.com/tmp/report-b1adfee/smart_ptr.html There is no compelling reason why I shouldn't use shared_ptr. The first implementation I did of ValueRef was just a small modification to Adobe's C++03 copy_on_write library, because I had already been playing with that class, it was fairly quite simple and just involved: adding the forwarding constructors; removing the dependencies on the other (Adobe and Boost) libraries; changing the wrapped type to const T; removing the non-const write() function. I operate in a fairly constrained environment, and I generally like the idea of minimising dependencies, however, as you imply, there is no point reinventing the wheel (for example shared_ptr/make_shared would already provide most of the solution for the dual C++03/11 support for forwarding constructors, etc.). Furthermore, I'd guess using shared_ptr might help facilitate submission generally. > Joaqu?n M L?pez Mu?oz > Telef?nica Tom

1 0

Re: [boost] [ValueRef]
by THOMAS JORDAN 21 Apr '15

21 Apr '15

> Message: 7 > Date: Mon, 20 Apr 2015 18:39:57 +0000 (UTC) > From: Joaquin M Lopez Munoz <joaquin(a)tid.es> > To: boost(a)lists.boost.org > Subject: Re: [boost] [ValueRef] > Message-ID: <loom.20150420T202848-660(a)post.gmane.org> > Content-Type: text/plain; charset=utf-8 > THOMAS JORDAN <tomjordan766 <at> gmail.com> writes: >> > > > From: Andrey Semashev <andrey.semashev <at> gmail.com> > > > > > Is this similar to Boost.Flyweight? > > > > It is similar in that both provide a 'smart' handle which can be used > > pretty much as a drop in for the wrapped type. > > > > However, Boost.Flyweight requires the wrapped type to be hashable. > Not necessarily; set_factory, for instance, requires values to > be less-than comparable: > http://boost.org/libs/flyweight/doc/tutorial/configuration.html#set_factory Ok > Also, see below. > > Also, there is a level of indirection with Flyweight which can mean that > > unnecessary temps may need to be created to do the initial lookup (and > > addition) to the Flyweight store, unless you use the Flyweight key-map > > interface. > Boost.Flyweight uses move semantics and perfect fwd ction where available, > I don't see how another solution can do better on this front Agreed, I'll withdraw that statement. However, as I said in the O.P., the ValueRef implementation I have done is currently only C++03. It uses a combination of N x forwarding constructor overloads taking arguments by const reference, and the client can use reference wrappers to forward to lvaluesto do the non-perfect forwarding (as boost.shared_ptr make_shared does) . The intention in the final library would be to support C++11/perfect forwarding and possibly Boost.Move for C++03 move semantics. So they would be equivalent in that regard. > > ValueRef does not use 'flyweighting.' That is, if there are two > > ValueRefs created independently with the same value, e.g., > > > > ValueRef<std::vector<int> > v1(10,10), v2(10,10); > > > > there will be two separate wrapped vector<int> objects - it is only when > > copying/assigning that sharing takes place. It is simpler than Flyweight > > and is essentially intended to be a more value-orientated option to > > shared-ptr-to-const. > The lib is extensible to the point that ValueRef can potentially be > built on top of it: > template<typename Entry,typename Key> > struct ValueRefFactory > { > using handle_type=Entry*; > template <typename E> > handle_type insert(E&& x){return new Entry{std::forward<E>(x)};} > void erase(handle_type h){delete h;} > const Entry& entry(handle_type h){return *h;} > }; > template<typename T> > using ValueRefImpl=flyweight< > T,no_locking, > factory<ValueRefFactory<boost::mpl::_1,boost::mpl::_2>>>; > template<typename T> > struct ValueRef:ValueRefImpl<T> > { > using impl_type=ValueRefImpl<T>; > const impl_type& impl()const{return *this;} > using impl_type::impl_type; > ValueRef(const ValueRef&x):impl_type(x.impl()){} > ValueRef(ValueRef&x):impl_type(x.impl()){} > ValueRef(const ValueRef&&x):impl_type(x.impl()){} > ValueRef(ValueRef&&x):impl_type(x.impl()){} > using impl_type::operator=; > const T& operator*()const{return this->get();} > const T* operator->()const{return &this->get();} > bool identity(const ValueRef& x)const{return &**this==&*x;} > }; > See complete example at: > http://coliru.stacked-crooked.com/a/c33389766fac6ecb > (except the unique_instance bit, which can be done, but admittedly > with more effort). > > Another (less significant) difference is that ValueRef > > currently has no dependency on MPL, which I believe Flyweight does, though > > that could well change if needed. > Boost.Flyweight is indeed heavier on the include side than some > people might be comfortable with. I think this is my concern with having Boost Flyweight as the only option for what is a relatively simple type. ValueRef is currently about 350 lines of easy-to-understand code in a single header file, and has no dependencies on MPL or any other Boost or std libraries, with the exception of an atomic library. It is intended in particular as a lightweight, clean replacement for shared-ptr-to-const, which I see used a lot in code. I also unfortunately y see shared-ptr-to-non-const being used a lot when people should be using shared-ptr-to-const, which is less safe and makes it much harder to reason about what is going on. ValueRef is an explict, consistent and safe alternative to such (mis)usages, and would also sit more comfortably with people who have concerns about build times, library-dependencies and cross-platform issues, etc. > Joaqu?n M L?pez Mu?oz > Telef?nica Tom.

2 1

Configuration error on BenPope x86_64 Ubuntu - clang-linux-3.6~tsan~c14_libc++?
by Vicente J. Botet Escriba 21 Apr '15

21 Apr '15

Hi, There are some reported errors that seems to be associated to the configuration of the tester E.g. http://www.boost.org/development/tests/develop/developer/output/BenPope%20x… /home/ben/development/boost/test/build/results/boost/bin.v2/libs/chrono/test/test_7868_d.test/clang-linux-3.6~tsan~c14_libc++/debug/address-model-64/architecture-x86/test_7868_d: symbol lookup error: /home/ben/development/llvm/trunk/build/release/projects/compiler-rt/lib/tsan/libcxx_tsan/lib/libc++.so.1: undefined symbol: __tsan_unaligned_read16 Please, could you check it? Best, Vicente

2 3

Generating documentation
by Alain Miniussi 21 Apr '15

21 Apr '15

Hi, Just curious, has anyone been able to get the documentation generated (on a linux platform) by following the instructions in http://www.boost.org/doc/libs/1_58_0/doc/html/boostbook/getting/started.html ?? Alternatively, is there a place where the documentation is generated for develop and/or master branch ? Thanks Not that the error messages make much sense, but FWIW, right now, I'm stuck with: [alainm@tagir doc]$ ../../../b2 html Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : yes (cached) /gpfs/scratch/alainm/view/modular-boost/tools/build/src/tools/boostbook.jam:683: in construct warning: object is empty /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:1336: in class(a)basic-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:757: in generate-really /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:729: in class(a)main-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:272: in class(a)project-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build-system.jam:707: in load /gpfs/scratch/alainm/view/modular-boost/tools/build/src/kernel/modules.jam:289: in import /gpfs/scratch/alainm/view/modular-boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build /gpfs/scratch/alainm/view/modular-boost/boost-build.jam:17: in module scope /gpfs/scratch/alainm/view/modular-boost/tools/build/src/tools/boostbook.jam:693: in construct warning: object is empty /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:1336: in class(a)basic-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:757: in generate-really /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:729: in class(a)main-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:272: in class(a)project-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build-system.jam:707: in load /gpfs/scratch/alainm/view/modular-boost/tools/build/src/kernel/modules.jam:289: in import /gpfs/scratch/alainm/view/modular-boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build /gpfs/scratch/alainm/view/modular-boost/boost-build.jam:17: in module scope /gpfs/scratch/alainm/view/modular-boost/tools/build/src/tools/boostbook.jam:707: in construct warning: object is empty /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:1336: in class(a)basic-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:757: in generate-really /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:729: in class(a)main-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build/targets.jam:272: in class(a)project-target.generate /gpfs/scratch/alainm/view/modular-boost/tools/build/src/build-system.jam:707: in load /gpfs/scratch/alainm/view/modular-boost/tools/build/src/kernel/modules.jam:289: in import /gpfs/scratch/alainm/view/modular-boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build /gpfs/scratch/alainm/view/modular-boost/boost-build.jam:17: in module scope ...found 1 target... [alainm@tagir doc]$ -- --- Alain

2 4

Re: [boost] [ValueRef] Interest in a new library for immutable values with internal sharing?
by THOMAS JORDAN 21 Apr '15

21 Apr '15

> Message: 2 > Date: Tue, 21 Apr 2015 10:33:26 +0100 > From: Sam Kellett <samkellett(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [ValueRef] Interest in a new library for > immutable values with internal sharing? > Message-ID: > <CAHK+-Fu6aYO2UwNkSvJWpn6UzmLjr+qNu+K3x8OSto8dyYGSBA(a)mail.gmail.com > > Content-Type: text/plain; charset=UTF-8 > On 20 April 2015 at 18:07, Thomas Jordan <tomjordan766(a)gmail.com> wrote: > > ValueRef doesn't expose (shared) pointers/pointees, they are a hidden, > > implementation detail. Its interface just deals in values (as shown in the > > example usage). > Absolutely! Hence the ref in the name. :) > I kept the pointer as part of the interface seeing as I saw it as a smart > pointer to replace another smart pointer, but either direction is not wrong > for sure. > The thing I like about the schrodinger_ptr is that I can carry on mutating > it while nobody else is looking, it seems with yours you would have to add > all data to it on it's construction, is that right? Yes, it is an immutable value with sharing of the underlying value object, that is pretty much the gist of it

1 0

Missing 1.58.0 tag on github.com
by Florent Guiliani 21 Apr '15

21 Apr '15

Hi, The release tag for Boost 1.58.0 is missing on github.com: https://github.com/boostorg/boost/releases Could someone please push the tag on github.com ? -- Florent

1 0

Re: [boost] [Boost-bugs] Fwd: [Boost C++ Libraries] #11211: Fusion example no longer compiles
by Joel de Guzman 21 Apr '15

21 Apr '15

Yes we should. This is a showstopper. On 4/21/15 3:06 PM, Damien Buhl wrote: > Sorry for this message, I just saw after sending that Flast already > replied about the problem : > > https://svn.boost.org/trac/boost/ticket/11211?replyto=3#comment:3 > > Shouldn't we make some bugfix release ? Because it is a seriously weird > issue. > > On 21/04/2015 09:01, Damien Buhl wrote: >> Hi Joel, >> >> Thanks for forwarding. >> >> Looks like the support for BOOST_CONSTEXPR BOOST_FUSION_GPU_ENABLED was >> added to DEFINE_STRUCT in a too strong way, which makes it impossible to >> use non-constexpr enabled types (namely std::string). >> >> I think the problem comes from the addition of BOOST_CONSTEXPR where >> BOOST_FUSION_GPU_ENABLED already was. >> >> In this commit >> https://github.com/boostorg/fusion/commit/2114bfca6c8d5e4f7fe2439346e1feddf… >> >> there is BOOST_CONSTEXPR added for the constructors and assignment >> operators. >> >> I think we have to remove the constexpr for this part, because we cannot >> add the requirements that the types the users gives to DEFINE_STRUCT are >> valid within constant expression. >> >> It also didn't come out by unit-tests runs, because our test are only >> done with int types. We have to add types which aren't constant-enabled >> to the tests for DEFINE_STRUCT and by the way for ADAPT also. >> >> I understand the idea behind adding BOOST_CONSTEXPR everywhere where >> BOOST_FUSION_GPU_ENABLED was, but actually it's not the same : on GPU >> there isn't any scenarii where one uses std::string I think, while it is >> typical in normal execution platform, and by the way BOOST_CONSTEXPR >> shouldn't be in this file. >> >> I've pushed a small commit where it then compiles for me on clang + g++ >> with C++03,11,14 : >>> https://github.com/boostorg/fusion/compare/boostorg:master...daminetreg:fea… >> >> >> Cheers, >> >> -- >> Damien Buhl >> >> On 20/04/2015 21:18, Joel de Guzman wrote: >>> Hello Kohei, Damien, >>> >>> Uh oh. Do you know what's happening here? >>> I'm getting: >>> >>> Constexpr constructor never produces a constant expression >>> >>> How did this slip? >>> >>> -------- Forwarded Message -------- >>> Subject: [Boost C++ Libraries] #11211: Fusion example no longer compiles >>> Date: Mon, 20 Apr 2015 19:01:29 -0000 >>> From: Boost C++ Libraries <noreply(a)lists.boost.org> >>> CC: boost-bugs(a)lists.boost.org >>> >>> #11211: Fusion example no longer compiles >>> -----------------------------------------------------+--------------------- >>> Reporter: Adrián Etchevarne <adrian.etchevarne@…> | Owner: djowel >>> Type: Bugs | Status: new >>> Milestone: To Be Determined | Component: fusion >>> Version: Boost 1.58.0 | Severity: Problem >>> Keywords: fusion | >>> -----------------------------------------------------+--------------------- >>> From the manual: >>> >>> {{{ >>> >>> #include <string> >>> #include "boost/fusion/adapted/struct/define_struct.hpp" >>> >>> // demo::employee is a Fusion sequence >>> BOOST_FUSION_DEFINE_STRUCT( >>> (demo), employee, >>> (std::string, name) >>> (int, age)) >>> >>> >>> int main() >>> { >>> } >>> >>> }}} >>> >>> It fails to compile with boost 1.58. With boost 1.57, compiles >>> successfully. >>> >>> g++ --std=c++11 test.cpp -I /home/saknussemm/downloads/boost_1_58_0 >>> >>> clang fails with a similar error. >>> >> _______________________________________________ >> Boost-bugs mailing list >> Boost-bugs(a)lists.boost.org >> http://lists.boost.org/mailman/listinfo.cgi/boost-bugs >> -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/

1 0

[convert] Help. Need promotion from 'develop' to 'master'.
by Vladimir Batov 20 Apr '15

20 Apr '15

On 04/21/2015 05:38 AM, Edward Diener wrote: > On 4/20/2015 1:10 PM, Vicente J. Botet Escriba wrote: >> Le 20/04/15 00:09, Vladimir Batov a écrit : >>> Daniel James created an entry point for 'convert' in the Boost >>> 'develop' branch and 'convert' has been sitting there for quite some >>> time. Now that Boost 1.58.0 has been released I would like to have >>> 'convert' promoted from 'develop' to 'master' so that 'convert' would >>> make it to 1.59. Is there anything that *I* can/need to do to have an >>> entry point created for 'convert' in the Boost 'master' branch? >> I would start a new thread and add you review manager. It is the review >> manager that should check everything is okay. > I was the review manager for 'convert' and it was accepted into Boost. > It has been on 'develop' and been regression tested. > > I myself am not sure of the process of moving a library from 'develop' > to 'master' so maybe someone dealing with the boostorg/boost project > can comment. > > My educated guess is that it would involve a fork of boostorg/boost, a > local 'pull --rebase' from that fork, changes locally that add the > library submodule to 'master' with the necessary commit, a 'push' back > to the fork, and then a pull request so that it shows up at > boostorg/boost and eventually gets merged into the superproject. I > believe part of the local changes are also that status/jamfile.v2 has > to be changed so that the library's tests are added to it. I would expect the master-branch-related "procedure" to be the same as for "develop". As I understand, I myself cannot create an entry point for the library (which is reasonable) and Daniel did that for me in the develop branch. So, I suspect, someone with super-duper permissions would need to step in. Any help in the matter would be greatly appreciated. Tnx, V.

1 0

open for merge?
by Oliver Kowalke 20 Apr '15

20 Apr '15

Hello, is boost open for merging into branch master after the release (unfortunately no entry in the calendar as it was available for previous releases)? thx, Oliver

1 0

DLL library: In search for Review Manager
by Antony Polukhin 20 Apr '15

20 Apr '15

Hi, Boost.DLL library seems ready, users use it and do not complain. Is there anyone wishing to help with review and become a Review Manager? Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library provides a portable across platforms way to: - load libraries at runtime - import and export any native functions and variables - make alias names for C++ mangled functions and symbols - query libraries/objects and executables for sections and exported symbols - self loading and self querying - getting program and module location by exported symbol Github: https://github.com/apolukhin/Boost.DLL Docs: http://apolukhin.github.io/Boost.DLL/index.html -- Best regards, Antony Polukhin

4 6

Re: [boost] [ValueRef]
by THOMAS JORDAN 20 Apr '15

20 Apr '15

> Message: 11 > Date: Mon, 20 Apr 2015 13:22:35 +0300 > From: Andrey Semashev <andrey.semashev(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [ValueRef] Interest in a new library for immutable values with internal sharing? > Message-ID: <1988978.ROPBOsQPor@lastique-pc> > Content-Type: text/plain; charset="us-ascii" > On Monday 20 April 2015 11:04:22 THOMAS JORDAN wrote: > > Hi, > > I'd like to gauge whether there might be any interest in a new Boost > > library comprising a generic, non-intrusive, wrapper class for creating > > immutable/const values with sharing of the underlying object via internal > > reference counting. > Is this similar to Boost.Flyweight? It is similar in that both provide a 'smart' handle which can be used pretty much as a drop in for the wrapped type. However, Boost.Flyweight requires the wrapped type to be hashable. Also, there is a level of indirection with Flyweight which can mean that unnecessary temps may need to be created to do the initial lookup (and addition) to the Flyweight store, unless you use the Flyweight key-map interface. ValueRef does not use 'flyweighting.' That is, if there are two ValueRefs created independently with the same value, e.g., ValueRef<std::vector<int> > v1(10,10), v2(10,10); there will be two separate wrapped vector<int> objects - it is only when copying/assigning that sharing takes place. It is simpler than Flyweight and is essentially intended to be a more value-orientated option to shared-ptr-to-const. Another (less significant) difference is that ValueRef currently has no dependency on MPL, which I believe Flyweight does, though that could well change if needed.

2 1

Re: [boost] Feedback on Boost.Http
by Brian Wood 20 Apr '15

20 Apr '15

Vin?cius dos Santos Oliveira: > I recently submitted an HTTP server library to Boost Incubator and I'd > appreciate feedback: > http://rrsd.com/blincubator.com/bi_library/http/?gform_post_id=1460 <http://rrsd.com/blincubator.com/bi_library/http/?gform_post_id=1460> > > I intend to submit to Boost later. > > This is the library that I developed during GSoC 2014 and I made several > improvements (new features, bug fixes, better and extended > documentation...) after the end of GSoC. There are a few improvements that > I still want to do, but none of them would be a barrier for Boost > integration, in my opinion. > > This library doesn't have a builtin request router, opposed to several > libraries out there, then you can use whatever routing style you wish > (tree-based, middleware-based, no router...). > > Also, it follows Boost active style, then you can build your own scheduler > around it (prioritize requests from certain IPs, defer acceptance of new > connections during server high load, reuse prior constructed objects...). > > The library follows Asio threading model, then you also choose whether you > will handle all requests from the same thread (useful for embedded devices) > or multiples ones. The library is fully async, then one thread is not a > problem. > > It has a powerful and flexible file server API, supporting range-based > requests, conditional requests, support for ETags and so on. > > After the GSoC, I had the chance to add tests for asynchronous abstractions > and now the implementation is much more trustable and stable. The choice to > reuse an existing HTTP parser (the Node.js's C parser) also helps a lot. > > The simple message-based API helps to support HTTP pipelining, allocation > fine tuning and much more. Besides HTTP pipelining, HTTP chunking (and > other modern features like 100-continue and HTTP Upgrade) are also > supported. > Do you have any users? If you don't have users, I suggest you become the first user by developing an application. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

4 3

Boost.locale update
by Maks Naumov 20 Apr '15

20 Apr '15

Any plans to update the Boost.Locale ? In https://github.com/boostorg/locale/pulls there are some fixes.

1 0

[ValueRef] Interest in a new library for immutable values with internal sharing?
by THOMAS JORDAN 20 Apr '15

20 Apr '15

Hi, I'd like to gauge whether there might be any interest in a new Boost library comprising a generic, non-intrusive, wrapper class for creating immutable/const values with sharing of the underlying object via internal reference counting. This new class would be called ValueRef (or possibly just Value), and it would effectively provide an assignable/swappable 'reference'/handle to shared, const values. It can be considered an effective alternative to the commonly used shared-pointer-to-const idiom, providing cleaner and more explicit value semantics, whilst also hiding calls to 'new' as an internal implementation detail. In a nutshell, ValueRef adapts a regular type T to give a new type ValueRef<T> with const T value semantics and uses reference counting of an underlying object on the heap internally to reduce copying overhead. ValueRef will spawn off a new copy of the wrapped object (if necessary) if the ValueRef is assigned another ValueRef or another object of type T. Const functions of T do not incur any overhead of counter access or copy and are invoked by either * or -> syntax. Forwarding constructors are provided which permit the wrapped value to be constructed in place, and conversion operator allows inter-operation with values of the unwrapped type. ValueRef also provides the common relational operators. I have so far implemented a rough (C++03-only so far) version of this (based on a stripped down version of Adobe::copy_on_write library) and a test suite and it seems to work okay. Example usage: /* type of ValueRef wrapped std::vector<int> */ typedef ValueRef<std::vector<int> > ValueRefVecType; /* create vector of 10 elements via forwarding constructor */ ValueRefVecType valueRefVector1(10,1); /* non-mutating/const op */ assert( valueRefVector1->size() == 10 ); /* non-mutating/const op */ assert( (*valueRefVector1)[0] == 1 ); /* error - compilation failure occurs calling a non-const op */ (*valueRefVector)[0] = 2; /* copy ctor */ ValueRefVecType valueRefVector2(valueRefVector1); /* test for equality */ assert( valueRefVector1 == valueRefVector2 ); /* test for equality (implicit conversion) */ assert( valueRefVector2 == std::vector<int>(10,1) ); /* valueRefVector1 and valueRefVector2 share same std::vector */ assert( valueRefVector1.identity(valueRefVector2) ); /* ref count is no longer one */ assert( !valueRefVector1.unique_instance() ); /* new value */ valueRefVector1 = std::vector<int>(5); /* non-mutating/const */ assert( valueRefVector1->size() == 5 ); /* test for equality - value semantics */ assert( !(valueRefVector1 == valueRefVector2) ); /* valueRefVector1 and valueRefVector2 do not share same std::vector */ assert( !valueRefVector1.identity(valueRefVector2) ); I am not aware of anything else current that provides this functionality. Regards, Tom

3 2

[release] Python 3 build problems
by Daniel James 20 Apr '15

20 Apr '15

Hi, Is there anyone who can write a brief description of the build problem with python 3 for the release notes? We probably should say something. thanks, Daniel

4 12

[regex] Support for Perl's (*SKIP)
by Sei Lisa 20 Apr '15

20 Apr '15

I'd like to see support for Perl's (*SKIP) regex verb in Boost. There are a number of verbs, but that one has an interesting and frequent use case: it enables searching for an expression but only outside of some contexts. There is a page called "The best regex trick" with details about the process and a number of examples. I can't link to it as this is my first message (I attempted before but it was rejected). It explains how to do it with and without (*SKIP). I've seen several questions in Stack Overflow asking how to accomplish that task, so it seems it's quite frequent to run into that need. Let's say for example that we want to find the string 'foo' as an identifier in C. This is a crude example of a Perl regex that does it (a real one might need to be more elaborate; in particular, backslashes for line continuation are not considered): (?x-s) (?# free spacing, dot doesn't match newline) (?://.*+ (?# eat single-line comment text) |/\*[\S\s]*?\*/ (?# eat multi-line comment text) |"(?:\\.|[^"\n])*+" (?# eat string text) )(*SKIP)(?!) (?# skip these) |\bfoo\b (?# match this) regex::search will match that expression only when foo is present outside of a string or comment. Without (*SKIP), it can be done only by calling regex::search multiple times, using an expression like this: (?-s)//.*+|/\*[\S\s]*?\*/|"(?:\\.|[^"\n])*+"|(\bfoo\b) and ignoring every match where group 1 wasn't matched. That's presumed to be slower, and certainly more inconvenient for the programmer. Support for this particular use case would be a great feature to have in the regex engine. Sei

2 3

[master] Open for 1.59?
by Joaquin M Lopez Munoz 20 Apr '15

20 Apr '15

Is master already open for commits towards Boost 1.59? Thank you, Joaquín M López Muñoz Telefónica

1 0

[config] BOOST_SYMBOL_VISIBLE on MinGW
by Robert Ramey 20 Apr '15

20 Apr '15

I made adjustments so that the serialization library on Develop branch will build with default visibilty = hidden. There is a little more to this than one would think. Basically I used BOOST_SYMBOL_VISIBLE on all "exported" classes (and their base classes) and BOOST_ARCHIVE_DECL ( defined as either BOOST_ARCHIVE_IMPORT or BOOST_ARCHIVE_EXPORT) on exported/visible member functions. This seems to give me what I need in that things build and test for gcc, clang, MSVC. EXCEPT for gcc under MinGW. see http://www.boost.org/development/tests/develop/developer/output/MinGW-32%20… The message seems to indicate to me that I should have BOOST_SYMBOL_VISIBLE on the class declaration - which seemed to resolve similar compilation errors with GCC on other platforms. Poking around config/compiler/gcc.hpp and config/plaform/w32.hpp It seems to me that this scheme things look OK - that is it looks that BOOST_SYMBOL_VISIBILITY should be defined as __attribute__((__visibility__("default"))) I'm also puzzled by the fact that the linker craps out only on this on declaration. Any help appreciated. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/config-BOOST-SYMBOL-VISIBLE-on-MinGW-tp4… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2