- Boost - lists.preview.boost.org

Boost.Algorithms organization question
by Marshall Clow 14 Dec '11

14 Dec '11

So, while I'm waiting for my review result, I've been implementing the new algorithms that were to the standard library for C++11 (at least the ones that don't require the new language features) They are: all_of any_of none_of find_if_not copy_if copy_n is_partitioned partition_point is_sorted is_sorted_until minmax -- this one is already in boost minmax_element -- this one is already in boost, but doesn't satisfy the C++11 performance gaurantees iota (and, of course, Boost.Range versions wherever appropriate) I have not done: shuffle -- requires rvalue references random_shuffle -- requires rvalue references move -- already in Boost.Move; maybe just a forwarding header file? move_backward -- already in Boost.Move; maybe just a forwarding header file? Anyway - my question is: Should these all go into a "c++11" subdirectory? If so, should I create a "c++11.hpp" header file that includes all of them, so that users can just #include <boost/algorithm/C++11.hpp> and get all the C++11 algorithms? Alternately, should they just live in boost/algorithm ? -- Marshall

3 4

[review] [Local] Review Result - ACCEPTED
by Lorenzo Caminiti 14 Dec '11

14 Dec '11

On Mon, Dec 12, 2011 at 3:15 AM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung(a)gmail.com> wrote: > Local is ACCEPTED into Boost. :) > After following the lively Local review discussion several weeks ago, and > reviewing the discussion a second (and sometimes third) time, I have come to > the above conclusion. There was quite a bit of passion on both the sides of > "aisle", and thus, obviously, no decision I make would be well-received by > all. > > Let me start by summarizing the main arguments against including Local in > Boost: > > (a) Local functions are not very useful, at least in the presence of > existing alternatives (e.g., namespace functions and Boost.Phoenix). > (b) Local is really a portability library for C++03 presenting an imperfect > emulation of features readily available in C++11. > (c) Local's interface is primarily macro-based, making code ugly and > difficult to read. > > In my opinion as the review manager, a sufficient number of individuals in > the discussion found the library "useful" to address (a) (sometimes with > additional positive adverbs); indeed, at least a couple individuals have > shared positive experiences with real-world use. Namespace functions require > one to move code to somewhere other than where one may prefer to have it, > and often requires a significant amount of boilerplate when binding local > variables. Aside from any perceived issues with Boost.Phoenix's syntax and > compiler error messages, it has been noted that binding member functions > within Boost.Phoenix can get ugly. As far as (b) is concerned, the community > seems pretty far from reaching a consensus on whether a library described by > (b) belongs in Boost. There are certainly libraries currently in Boost that > could be pegged to satisfy (b) as well, though they all have other > mitigating features they make their situation different from Local in some > way. As far as (c) is concerned, several have acknowledged that a > macro-based interface is necessary to implement local functions in C++03, > and it seems to have been generally agreed that, given this limitation, > Lorenzo has done an admireable job making the interface as easy-to-use as > possible. Some find it ugly, others find it reasonable. > > In addition to the counterarguments of (a-c) above, the following facts > weighed into my final decision: > * Lorenzo has been engaging and in constant communication with the > developer's list during the development of Local. This gives me confidence > that he will continue to actively maintain (and improve?) Local. > * The documentation is unanimously agreed to be of Boost quality. > * The transition of some organizations from C++03 to C++11 may take several > more years, and Boost has a history of supporting "ancient" compilers (for > better or worse). The point being, a library that eases the transition from > C++03 to C++11 has some merit based on current precedent. > * There had been previous work on local functions by Alexander Nasanov and > Steven Watanabe shared on the developer's list, suggesting a desire for this > functionality for some time. > * Local is approximately an extension of Boost.ScopeExit; indeed, it > basically fulfills the request to Alexander Nasanov from the review result > [2] of Boost.ScopeExit to create such an extension. > > Lastly, my own opinion of "what Boost is" factored in here. I view Boost as > *partly* a collection of general purpose libraries that can be used in wide > variety of applications (and thus Boost frequently acts as a staging ground > for standard adoption). Based on review feedback, I believe Local satisfies > this criterion; and based on the mailing list discussion, I believe this > view of Boost is not entirely inconsistent with others on the mailing list. Thank you for the detailed explanation of the rationale of the decision. > Ultimately, it wasn't so much a # of "yes" votes versus # of "no" votes as > it was the above general considerations. Regardless, I think independent of > how the votes were counted, the "yes" votes outnumbered the "no" votes. This > required some discretion on my part as not everyone who expressed an opinion > submitted a formal review, and some participants were only arguing in favor > of some specific point supporting either acceptance or rejection of Local. My thanks to you and to the Boost community for clarifying two process questions I had during the review: 1) How to count votes-- not just yes vs. no but it's up to the review manager how to count and weight votes. 2) Should active authors' opinion count more-- yes if the review manager decides so. These points make sense to me. > "Yes" reviews (7) > -------- > Krzysztof Czainski > Andrzej Krzemienski > Pierre Morcello > Nat Lindon > John Bytheway > Edward Diener > Gregory Crosswhite > > "No" reviews (3) > -------- > Vicente J. Botet > Thomas Heller > Hartmut Kaiser > > Paul A. Bristow and Alexander Nasanov (the author of Boost.ScopeExit) both > submitted reviews but did not express an opinion (as far as I could tell) on > whether Local should be included in Boost, though if I had to peg Paul's, it > would be to reject Local. From what I gathered, Joel de Guzman, Joel Falcou, > Dean Michael Berris, and Lucanus J. Simonson were opposed to including Local > in Boost (the aforementioned did not submit a formal review, though a formal > review might be unnecessary if your vote is "no"). On the other hand, Brian > Wood, Philippe Vaucher, Mathias Gaunard, Robert Ramey, Nathan Ridge, Brent > Spillner, Thomas Klimpel, Christopher Jefferson, Daniel James, Rafael > Fourquet, Matthias Schabel, and Robert Stewart participated in the > discussion and argued in favor of some point that supported accepting Local > in Boost. I want to be clear here that certainly not everyone in the > aforementioned list even implied that they supported acceptance of Local (I > would guess that only roughly half implied as much), but they indirectly > helped its case by addressing arguments against inclusion. Overall, that > indicates to me that more individuals support acceptance of Local into Boost > than rejection. > > [Apologies for any name misspellings and absent accents.] My personal thanks to /everyone/ that participated to the discussions. > Regarding Boost.ScopeExit: 4 reviews were in favor of deprecating > Boost.ScopeExit; 3 reviews felt there was nothing wrong with both > Boost.ScopeExit and Local coexisting; and 3 reviews mentioned the > possibility of improving Boost.ScopeExit with the features provided by > Local's exits. As such I'm inclined to let Alexander (who opposed any kind > of merging of Local and Boost.ScopeExit) work with Lorenzo on improving > Boost.ScopeExit as he sees fit, and hopefully both libraries can address > this apparent duplication of functionality within their respective > documentation to avoid user confusion. I will add void and this_ to ScopeExit (keeping it's compatibility with C++11 lambda style binding) and remove local exits from my library. (I will add a note to my library docs on how to use local function to easily implement scope exits with constant binding-- rarely needed.) > Regarding local::function::overload: Based on the review comments, it makes > the most sense to add this to Boost.Functional. I will move overload to Functional. > Regarding BOOST_IDENTITY_TYPE: This should be added to Boost.Utility. On the > other hand, there doesn't appear to be a compelling use case for > BOOST_IDENTITY_VALUE. I will add IDENTITY_TYPE to utility while IDENTITY_VALUE will not be included in Boost. > The following are some suggested *possible* improvements that reviewers > brought up. This list is by no means exhaustive. Further, I personally don't > think all of these suggestions are necessarily "good", but I think it's fair > for Lorenzo (and the community) to consider them nonetheless. Parenthetic > comments are my own opinions. > > * Some aren't convinced of the utility of LOCAL_BLOCK. (It's use cases > appear fairly narrow so it might be best to simplify the library and remove > this capability.) I will remove local blocks (I will document how to trivially implement them with a void local function with no parameters invoked right after it is defined). > * Use "this_" (as opposed to "_this") as an alias for "this" within function > bodies, and possibly also within bind declarations. > * Present Boost.PP sequence interface as a workaround for the variadic > interface? (I don't have a problem with supporting both interfaces at the > top level.) > * "Local" and "Locale" look too much alike, suggesting a name change to > "Scope", "Scoped", "LocalFunction", "Closure" may be a good idea? Given that local exits and blocks will be removed, I will rename Boost.Local to Boost.LocalFunction. > * Allow use without dependence on Boost.TypeOf. > * Rename prefix and postfix macros from XXX_PARAMS/XXX_NAME to XXX/XXX_END? > (I don't mind the current macros.) > * Explicitly separate bound variables from function parameters. (I think > this suggestion has merit but I don't know what the interface could look > like.) > * Remove support for default parameters to simplify interface and > documentation? (It doesn't seem like default function parameters would be > very useful.) > * Use "capture" instead of "bind" for the bind/capture keyword? (I like and > prefer "bind".) I will keep bind and add a note to the docs. > Finally, here the links to the submitted formal reviews, for reference. Of > particular note are Krzysztof's and John's reviews for their comments on the > documentation. Some "yes" votes were conditional, but AFAIK Lorenzo has > already agreed to address the relevant conditions. > > Krzysztof Czainski > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225543 > > Vicente J. Botet > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225604 > > Andrzej Krzemienski > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225656 > > Paul A. Bristow > [...cannot find link to review...] > > Pierre Morcello > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225694 > > Nat Lindon > http://permalink.gmane.org/gmane.comp.lib.boost.user/71508 > > Thomas Heller > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225736 > > Hartmut Kaiser > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225745 > > John Bytheway > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225746 > > Alexander Nasanov > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225783 > > Edward Diener > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225795 > > Gregory Crosswhite > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225807 Here's a list of all the changes I will make as they were identified during the review: http://sourceforge.net/apps/trac/contractpp/report/1 #2 Remove local blocks #3 Remove local exits #5 Rename the library Boost Local Function #4 Rename FUNCTION_PARAMS/_NAME to FUNCTION/_END #21 Use this_ also in local function declaration #7 Leave BOOST_IDENITY_TYPE but not _VALUE #8 Move PP_KEYWORD macros to implementation details #10 Move local::function::overload to Boost Functional #16 Make sure that the local function closures work like C++11 lambda closures #6 Expose result_type, argN_type, and arity #9 Use Boost Preprocessor built-in variadic support #12 Present the sequencing syntax as a work-around #14 Allow to specify result type within the LOCAL_FUNCTION macro #15 Try to reduce dependency on Boost Typeof #17 Improve motivation section #24 Document that local function can access protected/private members #11 Create regression tests #20 Fix documentation typos #22 Investigate MSVC errors with /ZI #26 Consider using assert instead of example writing to cout #28 Improve docs on need for Typeof registration #29 Document that a local function cannot be named recursive #1 Change the order of the Tutorial subsections #13 Add example for the GCC_LAMBDA macros #19 Document that bind cannot be use as a parameter type #23 Add the C++11 lambda const-binding workaround to the Alternatives #25 Indicate Phoenix and Lambda version numbers in Alternatives #27 Free arrays in examples without checking !=0 Please let me know if I missed anything. Two personal reflections from this experience: 1) I should have studied Phoenix more before the review started. I would have been better prepared for some of the discussions. 2) A while back, someone on this ML suggested that an library author should participate to 3 reviews before being able to have his/her library reviewed. This comment was in the context of getting more participation to the reviews. I thought the comment made sense (it was "fair") so I participated to 3 reviews before my library was reviewed. I have to say that such experience really helped me during the review of my library. I don't know if it'd make sense to make "participating to 3 reviews" a requirement for a library submission... maybe a requirement that can be waived only by the review wizards. > Finally, really big thanks to everyone for participating in the review and > ancillary discussions. I attempted to be as transparent as possible in > outlining the rationale for my decision above, but if you have any further > questions, do not hesitate to ask. > > - Jeff, Review Manager for Local Thank you very much Jeff for managing the review! --Lorenzo > [1] http://thread.gmane.org/gmane.comp.lib.boost.devel/168612 > [2] http://lists.boost.org/boost-announce/2008/05/0190.php

1 0

[Serialization] (Commented) assertion when using types in multiple DLLs on Windows (Ticket #3934 and #4394)
by Martin B. 14 Dec '11

14 Dec '11

[Serialization] (Commented) assertion when using types in multiple DLLs on Windows (Ticket #3934 and #4394) ----------------------------------- ## Problem: We were using boost serialization in a DLL that is "statically" loaded into our main application. We are using Boost 1.44 and the serialization library as a DLL. (boost_serialization-vc80-mt-gd-1_44.dll) Now, the serialized types that we are using in this DLL have also been pulled into the main application -- that is, the .h+.cpp files of these types are included and linked in the exe as well as in the DLL project. (But the types are used independently in the exe and the dll module.) In Boost 1.44 this leads to a runtime assertion in void_cast.cpp[1_44_0, line 230]. ## Investigation: Since this code is in the function called void_caster::recursive_register I *assume* that this is the point where the types registered for serialization are registered with the library. I have found that this runtime assert was commented out in release 1.45 and all subsequent versions: std::pair<void_cast_detail::set_type::const_iterator, bool> result; // comment this out for now. result = s.insert(this); //assert(result.second); *Apparently* this was done in response to trac ticket #4394[1], at least judging from the comment Robert Ramey added to the ticket: > For now I'm going to comment out the assert. > When I have time, I'll likely re-enable it with a way to override it. I can only assume that ticket #3934[2] refers to the same or a similar problem. ## Issue with the conclusion in #4394 Robert writes in his comment: > The problem is that the way the code is structured, > you'll have multiple instances of some functions. > The best way would be eliminate the source of the > problem by structuring code like this: > ... > and he proposes to move the `template<class Archive> void serialize` function of the classes from the header file into the cpp file. However, *our* code already does this, and we get this assertion regardless. The reason I suspect is that both the main module code as well as the DLL module code are calling into the recursive_register function to register the type, and since the code for the class is (identically) duplicated in the DLL as well as in the executable, obviously it is registered twice. ## Question: Am I correct? So, the first question obviously is whether I'm correct in my analysis. I.e., the `assert(result.second);`that is currently commented out can *never* work properly for types that live in two modules (DLLs) in the same process and Boost:serialization is used as DLL. ## Question: Any harm done? Secondly, is there any adverse effect of a type being registered twice with the serialization DLL? What will happen on unload? Is it possible the type is unloaded too early because of this setup? Note: What about accidentally identical type keys for actually different types in different DLLs? ## Question: Solutions? What is a proper solution? Should we use dllexport types, so that the type is only registered once per process? What else? Robert, I hope you can chime in on this. I'll try to add a link to this mail to the trac issue #4394. cheers, Martin [1] : https://svn.boost.org/trac/boost/ticket/4394 [2] : https://svn.boost.org/trac/boost/ticket/3934

2 4

[Boost] Is there any interest in min-max heap and bounded priority queue implementations?
by Andrea Sansottera 14 Dec '11

14 Dec '11

Dear Boost developers and users, I have implemented the min-max heap<http://www.akira.ruc.dk/~keld/teaching/algoritmedesign_f03/Artikler/02/Atki…> algorithms and a bounded priority queue container adapter. I was wondering if anyone is interested in including this code in Boost. I have made the code <https://www.assembla.com/code/sway-1/subversion/nodes/trunk>available here, under the BSD license (I might switch to the Boost license if needed). For those not familiar with min-max heaps, a min-max heap is an implicit data structure that can be build in linear time and provides constant time access to both the minimum and maximum elements. Other operations require logarithmic time. Hence, they allow the efficient implementation of double ended priority queues. My min-max heap implementation is designed similarly to the STL heap algorithms and consists of the following template functions: make_minmaxheap, push_minmaxheap, popmin_minmaxheap, popmax_minmaxheap. The bounded priority queue container adapter is built on top of the min-max heap algorithms and its interface is similar to the STL priority_queue. The methods of the bounded_priority_queue template class are: push, top, bottom, pop_top, pop_bottom, size, max_size, empty. The template arguments are the item type, the container type and the compare functor. The code compiles and works correctly with the GNU, Intel, Clang and Microsoft compilers. I have unit tests based on Boost.Test. Any feedback would be appreciated. Regards, Andrea Sansottera

2 2

Proposal for a Differential Evolution C++ library
by Adrian Michel 14 Dec '11

14 Dec '11

Hello everybody, Would there be interest in a C++ Differential Evolution optimization (DE) library as part of boost? The library is functional but hasn't been made public yet. The full documentation is at http://www.amichel.com/de/doc/html but I'd suggest these pages for a first read http://www.amichel.com/de/doc/html/dd/d53/overview.html and http://www.amichel.com/de/doc/html/db/d4e/tutorial.html . The zip containing the DE C++ library and helper files is at http://www.amichel.com/de/de.zip. The DE main page is at http://www.icsi.berkeley.edu/~storn/code.html . Thanks, Adrian Michel

5 4

Error in docs or code when trying zero unit tests
by Daryle Walker 14 Dec '11

14 Dec '11

[Woah, Hotmail's Web interface doesn't do unformatted mail; it implements it as formatted mail surrounded by <pre> tags and hex-conversion to almost all the punctuation!] When I tried the example on <http://www.boost.org/doc/libs/1_48_0/libs/test/doc/html/tutorials/new-year-…>: //===#define BOOST_TEST_MODULE const_string test#include <boost/test/unit_test.hpp>//=== Instead of getting: //===*** No errors detected//=== I got: //===[Session started at 2011-12-11 18:18:15 -0500.]Test setup error: test tree is empty CRC Unit Test has exited with status 200.//=== (The first and last lines are from my compiler's IDE.) Either the docs are wrong claiming that an empty test program is OK, or the code is wrong for choking when running with zero unit tests. It's probably the former but I personally prefer the latter to be fixed instead.

1 0

Boost Interchange / Carbon
by Tom Sanham 13 Dec '11

13 Dec '11

Hello I am new to this list. I wonder if someone can help me: Is it possible to use XCode on OS X 10.7 to build a .dylib which depends on Boost Interchange library (which we need to be statically linked), for Carbon? The reason I ask is that: when XCode version >=4.2, Carbon is (apparently) no longer supported, but Boost Interchange Library compiles successfully. when XCode version <4.2, Carbon is supported, but Boost Interchange library cannot compile (due to an compiler error involving the handling of Templates, where it appears the library employs a mechanism supported only in the later XCode versions). Is it possible to achieve this? Could somebody offer some pointers? Thank you in advance Tom

2 1

Interested in bounded buffer class for threaded producer/consumer communication?
by André Offringa 13 Dec '11

13 Dec '11

Hi all, I seem to have come across a producer/consumer situation a few times now, and everytime I do, I seem to want a slightly different functionality for a bounded buffer-kind of class that is not generally provided. I am looking for such a class that is also efficient for large amounts of data, and so I wonder if there does already exists a class in boost to efficiently push work between producers and consumers when they are running in different threads, i.e., that is thread safe. Asio seems to have a lot of communicating mechanisms, but I did not yet come across such a mechanism (pipe/channel/lane/unidirectional stream/bounded buffer... I'll call it a 'lane' for now) between two threads. If it does not exist yet in boost, I wonder if there is a general interest for such a class. The situation, is that - one or more threads produce data 'packages' of some type T, until the buffer is full. - one or more other threads have to wait for the availability of these packages, and once available, get one and process them. Googling around there are numerous suggestions (e.g. blog entries) for an implementation of thread safe queues that synchronize writing/reading and wake readers when data is available. However, I think there are fewer implementations that both use a circular buffer and will also block the producer when the buffer is 'full', and even less that are efficient for large amounts of data. Typical examples for this situation occur in signal processing. For example, it could be that one thread reads packets of work from the hard disk or some other device, write it to the lane-object, while one or a few different other threads try to read packets from the lane-object for processing. In a particular case, I had a consumer which needed a certain amount of packets at a time. The lane holds a (circular) buffer of a given size, and if it is full, producing threads will be blocked. Consuming threads will be blocked if the buffer is empty. There is a bounded_buffer example given to implement such a thing with the circular buffer. It does exactly what I suggest, but I assume it is not so efficient for pushing large amounts of data over, as each individual object requires a push, thus a lock if implemented as in bounded_buffer, and involves unnecessary updates of the counters (involving a decrement() each time) on each push, which is not necessary if you know you are pushing a number of elements at once. I assume this could be fixed by wrapping the insert(range) method instead of the individual push functions. What I found most useful however, is when the 'main' interface of such a class consists of these methods: template<typename T> class lane { public: lane(size_t capacity); void write(const T& element); // (or push if you wish) void write(const T* elements, size_t n); // or as a data range void write_end(); bool read(const T& element); // false if write_end() has been called and empty() size_t read(const T* elements, size_t n); // returns n, unless write_end() has been called and is empty() size(), empty(), etc. } ..and that's basically how I implemented it right now. The lane is just like the circular buffer in boost, and owns the elements, and thus copies the data once on write to its own buffer and once on read. The write_end() method will change the state of the lane, such that blocked reading threads will no longer be blocked, i.e., it assumes the producer(s) is finished and the consumer should finish as well after the last data has been read. No element ever gets overwritten before being read. In my case I never needed it to be an actually "real" container, thus valid iterators and begin() and end()'s are not necessary. With such a class, setting up an efficient multi-threaded consumer/producer scenario, that can be easily end by either the producer or yet another separate (e.g., user interface) thread, is really easy. As said, especially in signal processing application (why it is somewhat low-leveler), this kind of class is very nice to have. I guess there are many flavours of such a 'lane', e.g. with deque's or circular_buffers, with or without owning data, with or without bounding the producer and with or without providing efficient large data pushers. In my case, the above interface seemed to have been the solution a few times, but I don't know how common it really is. So, I'm curious if this problem frequently arises, if it's solved already and/or if there would be interest in such a class. Regards, André Offringa

4 4

[review] [Local] Review Result - ACCEPTED
by Jeffrey Lee Hellrung, Jr. 13 Dec '11

13 Dec '11

Local is ACCEPTED into Boost. After following the lively Local review discussion several weeks ago, and reviewing the discussion a second (and sometimes third) time, I have come to the above conclusion. There was quite a bit of passion on both the sides of "aisle", and thus, obviously, no decision I make would be well-received by all. Let me start by summarizing the main arguments against including Local in Boost: (a) Local functions are not very useful, at least in the presence of existing alternatives (e.g., namespace functions and Boost.Phoenix). (b) Local is really a portability library for C++03 presenting an imperfect emulation of features readily available in C++11. (c) Local's interface is primarily macro-based, making code ugly and difficult to read. In my opinion as the review manager, a sufficient number of individuals in the discussion found the library "useful" to address (a) (sometimes with additional positive adverbs); indeed, at least a couple individuals have shared positive experiences with real-world use. Namespace functions require one to move code to somewhere other than where one may prefer to have it, and often requires a significant amount of boilerplate when binding local variables. Aside from any perceived issues with Boost.Phoenix's syntax and compiler error messages, it has been noted that binding member functions within Boost.Phoenix can get ugly. As far as (b) is concerned, the community seems pretty far from reaching a consensus on whether a library described by (b) belongs in Boost. There are certainly libraries currently in Boost that could be pegged to satisfy (b) as well, though they all have other mitigating features they make their situation different from Local in some way. As far as (c) is concerned, several have acknowledged that a macro-based interface is necessary to implement local functions in C++03, and it seems to have been generally agreed that, given this limitation, Lorenzo has done an admireable job making the interface as easy-to-use as possible. Some find it ugly, others find it reasonable. In addition to the counterarguments of (a-c) above, the following facts weighed into my final decision: * Lorenzo has been engaging and in constant communication with the developer's list during the development of Local. This gives me confidence that he will continue to actively maintain (and improve?) Local. * The documentation is unanimously agreed to be of Boost quality. * The transition of some organizations from C++03 to C++11 may take several more years, and Boost has a history of supporting "ancient" compilers (for better or worse). The point being, a library that eases the transition from C++03 to C++11 has some merit based on current precedent. * There had been previous work on local functions by Alexander Nasanov and Steven Watanabe shared on the developer's list, suggesting a desire for this functionality for some time. * Local is approximately an extension of Boost.ScopeExit; indeed, it basically fulfills the request to Alexander Nasanov from the review result [2] of Boost.ScopeExit to create such an extension. Lastly, my own opinion of "what Boost is" factored in here. I view Boost as *partly* a collection of general purpose libraries that can be used in wide variety of applications (and thus Boost frequently acts as a staging ground for standard adoption). Based on review feedback, I believe Local satisfies this criterion; and based on the mailing list discussion, I believe this view of Boost is not entirely inconsistent with others on the mailing list. Ultimately, it wasn't so much a # of "yes" votes versus # of "no" votes as it was the above general considerations. Regardless, I think independent of how the votes were counted, the "yes" votes outnumbered the "no" votes. This required some discretion on my part as not everyone who expressed an opinion submitted a formal review, and some participants were only arguing in favor of some specific point supporting either acceptance or rejection of Local. "Yes" reviews (7) -------- Krzysztof Czainski Andrzej Krzemienski Pierre Morcello Nat Lindon John Bytheway Edward Diener Gregory Crosswhite "No" reviews (3) -------- Vicente J. Botet Thomas Heller Hartmut Kaiser Paul A. Bristow and Alexander Nasanov (the author of Boost.ScopeExit) both submitted reviews but did not express an opinion (as far as I could tell) on whether Local should be included in Boost, though if I had to peg Paul's, it would be to reject Local. From what I gathered, Joel de Guzman, Joel Falcou, Dean Michael Berris, and Lucanus J. Simonson were opposed to including Local in Boost (the aforementioned did not submit a formal review, though a formal review might be unnecessary if your vote is "no"). On the other hand, Brian Wood, Philippe Vaucher, Mathias Gaunard, Robert Ramey, Nathan Ridge, Brent Spillner, Thomas Klimpel, Christopher Jefferson, Daniel James, Rafael Fourquet, Matthias Schabel, and Robert Stewart participated in the discussion and argued in favor of some point that supported accepting Local in Boost. I want to be clear here that certainly not everyone in the aforementioned list even implied that they supported acceptance of Local (I would guess that only roughly half implied as much), but they indirectly helped its case by addressing arguments against inclusion. Overall, that indicates to me that more individuals support acceptance of Local into Boost than rejection. [Apologies for any name misspellings and absent accents.] Regarding Boost.ScopeExit: 4 reviews were in favor of deprecating Boost.ScopeExit; 3 reviews felt there was nothing wrong with both Boost.ScopeExit and Local coexisting; and 3 reviews mentioned the possibility of improving Boost.ScopeExit with the features provided by Local's exits. As such I'm inclined to let Alexander (who opposed any kind of merging of Local and Boost.ScopeExit) work with Lorenzo on improving Boost.ScopeExit as he sees fit, and hopefully both libraries can address this apparent duplication of functionality within their respective documentation to avoid user confusion. Regarding local::function::overload: Based on the review comments, it makes the most sense to add this to Boost.Functional. Regarding BOOST_IDENTITY_TYPE: This should be added to Boost.Utility. On the other hand, there doesn't appear to be a compelling use case for BOOST_IDENTITY_VALUE. The following are some suggested *possible* improvements that reviewers brought up. This list is by no means exhaustive. Further, I personally don't think all of these suggestions are necessarily "good", but I think it's fair for Lorenzo (and the community) to consider them nonetheless. Parenthetic comments are my own opinions. * Some aren't convinced of the utility of LOCAL_BLOCK. (It's use cases appear fairly narrow so it might be best to simplify the library and remove this capability.) * Use "this_" (as opposed to "_this") as an alias for "this" within function bodies, and possibly also within bind declarations. * Present Boost.PP sequence interface as a workaround for the variadic interface? (I don't have a problem with supporting both interfaces at the top level.) * "Local" and "Locale" look too much alike, suggesting a name change to "Scope", "Scoped", "LocalFunction", "Closure" may be a good idea? * Allow use without dependence on Boost.TypeOf. * Rename prefix and postfix macros from XXX_PARAMS/XXX_NAME to XXX/XXX_END? (I don't mind the current macros.) * Explicitly separate bound variables from function parameters. (I think this suggestion has merit but I don't know what the interface could look like.) * Remove support for default parameters to simplify interface and documentation? (It doesn't seem like default function parameters would be very useful.) * Use "capture" instead of "bind" for the bind/capture keyword? (I like and prefer "bind".) Finally, here the links to the submitted formal reviews, for reference. Of particular note are Krzysztof's and John's reviews for their comments on the documentation. Some "yes" votes were conditional, but AFAIK Lorenzo has already agreed to address the relevant conditions. Krzysztof Czainski http://permalink.gmane.org/gmane.comp.lib.boost.devel/225543 Vicente J. Botet http://permalink.gmane.org/gmane.comp.lib.boost.devel/225604 Andrzej Krzemienski http://permalink.gmane.org/gmane.comp.lib.boost.devel/225656 Paul A. Bristow [...cannot find link to review...] Pierre Morcello http://permalink.gmane.org/gmane.comp.lib.boost.devel/225694 Nat Lindon http://permalink.gmane.org/gmane.comp.lib.boost.user/71508 Thomas Heller http://permalink.gmane.org/gmane.comp.lib.boost.devel/225736 Hartmut Kaiser http://permalink.gmane.org/gmane.comp.lib.boost.devel/225745 John Bytheway http://permalink.gmane.org/gmane.comp.lib.boost.devel/225746 Alexander Nasanov http://permalink.gmane.org/gmane.comp.lib.boost.devel/225783 Edward Diener http://permalink.gmane.org/gmane.comp.lib.boost.devel/225795 Gregory Crosswhite http://permalink.gmane.org/gmane.comp.lib.boost.devel/225807 Finally, really big thanks to everyone for participating in the review and ancillary discussions. I attempted to be as transparent as possible in outlining the rationale for my decision above, but if you have any further questions, do not hesitate to ask. - Jeff, Review Manager for Local [1] http://thread.gmane.org/gmane.comp.lib.boost.devel/168612 [2] http://lists.boost.org/boost-announce/2008/05/0190.php

7 6

[test, parameter, fusion] en/disable_if name clash in trunk
by Tim Blechmann 13 Dec '11

13 Dec '11

it seems that the new boost::unit_test::decorator::enable_if, introduced in [1] clashes with boost::enable_if under certain circumstances. this currently breaks the boost.heap testsuite (see [2]). maybe the test/parameter/fusion maintainers could discuss, how that can be resolved? thanks, tim [1] https://svn.boost.org/trac/boost/changeset/74663 [2] http://www.boost.org/development/tests/trunk/developer/heap.html

4 14

Question regarding parallel boost graph library status
by Delalondre Fabien Jonathan 13 Dec '11

13 Dec '11

Hi, I would like to use the parallel boost graph library for projects I am working on and was wondering whether I could get an update on its development. I am for example wondering: 1) Whether this is still an projet under active development and how many people are working on it. 2) What the status of the mpi/threading implementation is. 3) What are the machines on which the implementation has been tested (and on how many processors). I am interested in using it on HPC machines such as Cray and IBM which includes more than 100k processors. Thank you, Fabien Delalondre

2 1

Use constexpr with BOOST_STATIC_CONSTANT?
by Daryle Walker 12 Dec '11

12 Dec '11

Should BOOST_STATIC_CONSTANT be changed to add the C++11 "constexpr" attribute, if it's defined? I guess we would need a preprocessor flag to check if constexpr is available.

3 2

[regex] compilation warnings questions by a newbee
by Rai, Neeraj 12 Dec '11

12 Dec '11

Hi All, Reposting this based on feedback from Beman. I get the same error with latest boost. I earlier posted this to user group and atleast one user confirmed (s)he was getting the same error with newer version and not getting any error with older one. It is a simple program (just declares regex). Pls advise. Thx Neeraj _____________________________________________ From: Rai, Neeraj [ICG-MKTS] Sent: Friday, December 09, 2011 1:29 PM To: 'boost(a)lists.boost.org' Subject: [boost-dev] compilation warnings questions by a newbee Hi, I am writing my first boost program and having trouble with the compiler warning against boost 1.44.0. Is there any way to get rid of those warnings so I can focus on real warnings in my code ? This seems to happen with newer version of g++ : tried 4.4.5 and 4.6 The gist of warning is : boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: warning: the result of the conversion is unspecified because '-0x00000000000000001' is outside the range of type 'boost::numeric::udt_builtin_mixture_enum' [-Wconversion] Any help or pointers are appreciated. Neeraj ====== The following program is a cut down version of my code, just declares sregex #include <iostream> #include <boost/xpressive/xpressive.hpp> int main (int _argc, const char** _argv) { std::cout << "argc=" << _argc << " argv=" << _argv << std::endl; using namespace boost::xpressive; std::string keyword(""); sregex const re(sregex::compile(keyword, sregex::icase)); } ====== The following cmd is used to build it (tried g++ v 4.4.5 and 4.6 with same results) g++ -ftemplate-depth-128 -O0 -fno-inline -Wall -g -Wconversion -Wno-strict-aliasing -Wextra -Wnon-virtual-dtor -Wno-missing-field-initializers -Wno-array-bounds -Wno-ignored-qualifiers -Wno-parentheses -Wno-strict-aliasing -fPIC -DBOOST_ALL_NO_LIB -I/work/loc1/atddds -I/work/loc1/boost_1_44_0/include -Iinclude -c -o boost_regex_test.o boost_regex_test.cpp ====== The following cmd is used to build it (tried g++ v 4.4.5 and 4.6) g++ -ftemplate-depth-128 -O0 -fno-inline -Wall -g -Wconversion -Wno-strict-aliasing -Wextra -Wnon-virtual-dtor -Wno-missing-field-initializers -Wno-array-bounds -Wno-ignored-qualifiers -Wno-parentheses -Wno-strict-aliasing -fPIC -DBOOST_ALL_NO_LIB -I/work/loc1/atddds -I/work/loc1/boost_1_44_0/include -Iinclude -c -o boost_regex_test.o boost_regex_test.cpp In file included from /work/loc1/boost_1_44_0/include/boost/mpl/integral_c.hpp:32:0, from /work/loc1/boost_1_44_0/include/boost/type_traits/integral_constant.hpp:11, from /work/loc1/boost_1_44_0/include/boost/type_traits/detail/bool_trait_def.hpp:15, from /work/loc1/boost_1_44_0/include/boost/type_traits/is_volatile.hpp:40, from /work/loc1/boost_1_44_0/include/boost/type_traits/remove_const.hpp:14, from /work/loc1/boost_1_44_0/include/boost/proto/proto_fwd.hpp:25, from /work/loc1/boost_1_44_0/include/boost/xpressive/xpressive_fwd.hpp:53, from /work/loc1/boost_1_44_0/include/boost/xpressive/detail/detail_fwd.hpp:24, from /work/loc1/boost_1_44_0/include/boost/xpressive/regex_primitives.hpp:21, from /work/loc1/boost_1_44_0/include/boost/xpressive/xpressive_static.hpp:24, from /work/loc1/boost_1_44_0/include/boost/xpressive/xpressive.hpp:18, from boost_regex_test.cpp:2: /work/loc1/boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>': /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/meta.hpp:30:13: instantiated from 'boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u> >' /work/loc1/boost_1_44_0/include/boost/mpl/if.hpp:67:11: instantiated from 'boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u> >, boost::mpl::identity<boost::numeric::convdetail::get_subranged_BuiltIn2BuiltIn<unsigned char, int> >, boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)1u> >, boost::mpl::identity<boost::mpl::identity<boost::numeric::convdetail::subranged_BuiltIn2Udt<unsigned char, int> > >, boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)2u> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2BuiltIn<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2Udt<unsigned char, int> > > > >' /work/loc1/boost_1_44_0/include/boost/mpl/eval_if.hpp:37:41: instantiated from 'boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u> >, boost::mpl::identity<boost::numeric::convdetail::get_subranged_BuiltIn2BuiltIn<unsigned char, int> >, boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)1u> >, boost::mpl::identity<boost::mpl::identity<boost::numeric::convdetail::subranged_BuiltIn2Udt<unsigned char, int> > >, boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)2u> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2BuiltIn<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2Udt<unsigned char, int> > > > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/meta.hpp:82:9: instantiated from 'boost::numeric::convdetail::ct_switch4<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)1u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)2u>, boost::numeric::convdetail::get_subranged_BuiltIn2BuiltIn<unsigned char, int>, boost::mpl::identity<boost::numeric::convdetail::subranged_BuiltIn2Udt<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2BuiltIn<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2Udt<unsigned char, int> > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/udt_builtin_mixture.hpp:45:9: instantiated from 'boost::numeric::convdetail::for_udt_builtin_mixture<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, boost::numeric::convdetail::get_subranged_BuiltIn2BuiltIn<unsigned char, int>, boost::mpl::identity<boost::numeric::convdetail::subranged_BuiltIn2Udt<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2BuiltIn<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2Udt<unsigned char, int> > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/is_subranged.hpp:206:11: [ skipping 9 instantiation contexts ] /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:281:13: instantiated from 'boost::xpressive::detail::sequence<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::parse_alternates(FwdIter&, FwdIter) [with FwdIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:212:75: instantiated from 'boost::xpressive::basic_regex<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile_(FwdIter, FwdIter, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type, std::forward_iterator_tag) [with FwdIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:120:60: instantiated from 'boost::xpressive::basic_regex<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile(InputIter, InputIter, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type) [with InputIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:129:71: instantiated from 'typename boost::disable_if<boost::is_pointer<InputRange>, boost::xpressive::basic_regex<BidiIter> >::type boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile(const InputRange&, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type) [with InputRange = std::basic_string<char>, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, typename boost::disable_if<boost::is_pointer<InputRange>, boost::xpressive::basic_regex<BidiIter> >::type = boost::xpressive::basic_regex<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/basic_regex.hpp:193:61: instantiated from 'static boost::xpressive::basic_regex<BidiIter> boost::xpressive::basic_regex<BidiIter>::compile(const InputRange&, boost::xpressive::basic_regex<BidiIter>::flag_type) [with InputRange = std::basic_string<char>, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, boost::xpressive::basic_regex<BidiIter>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' boost_regex_test.cpp:9:57: instantiated from here /work/loc1/boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: warning: the result of the conversion is unspecified because '-0x00000000000000001' is outside the range of type 'boost::numeric::udt_builtin_mixture_enum' [-Wconversion] /work/loc1/boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>': /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/meta.hpp:30:13: instantiated from 'boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u> >' /work/loc1/boost_1_44_0/include/boost/mpl/if.hpp:67:11: instantiated from 'boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u> >, boost::mpl::identity<boost::numeric::convdetail::get_subranged_Int2Int<unsigned char, int> >, boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)1u> >, boost::mpl::identity<boost::mpl::identity<boost::numeric::convdetail::subranged_Int2Float<unsigned char, int> > >, boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)2u> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Int<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Float<unsigned char, int> > > > >' /work/loc1/boost_1_44_0/include/boost/mpl/eval_if.hpp:37:41: instantiated from 'boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u> >, boost::mpl::identity<boost::numeric::convdetail::get_subranged_Int2Int<unsigned char, int> >, boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)1u> >, boost::mpl::identity<boost::mpl::identity<boost::numeric::convdetail::subranged_Int2Float<unsigned char, int> > >, boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)2u> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Int<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Float<unsigned char, int> > > > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/meta.hpp:82:9: instantiated from 'boost::numeric::convdetail::ct_switch4<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)1u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)2u>, boost::numeric::convdetail::get_subranged_Int2Int<unsigned char, int>, boost::mpl::identity<boost::numeric::convdetail::subranged_Int2Float<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Int<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Float<unsigned char, int> > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/int_float_mixture.hpp:63:9: instantiated from 'boost::numeric::convdetail::for_int_float_mixture<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, boost::numeric::convdetail::get_subranged_Int2Int<unsigned char, int>, boost::mpl::identity<boost::numeric::convdetail::subranged_Int2Float<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Int<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Float<unsigned char, int> > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/is_subranged.hpp:184:35: [ skipping 10 instantiation contexts ] /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:281:13: instantiated from 'boost::xpressive::detail::sequence<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::parse_alternates(FwdIter&, FwdIter) [with FwdIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:212:75: instantiated from 'boost::xpressive::basic_regex<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile_(FwdIter, FwdIter, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type, std::forward_iterator_tag) [with FwdIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:120:60: instantiated from 'boost::xpressive::basic_regex<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile(InputIter, InputIter, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type) [with InputIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:129:71: instantiated from 'typename boost::disable_if<boost::is_pointer<InputRange>, boost::xpressive::basic_regex<BidiIter> >::type boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile(const InputRange&, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type) [with InputRange = std::basic_string<char>, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, typename boost::disable_if<boost::is_pointer<InputRange>, boost::xpressive::basic_regex<BidiIter> >::type = boost::xpressive::basic_regex<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/basic_regex.hpp:193:61: instantiated from 'static boost::xpressive::basic_regex<BidiIter> boost::xpressive::basic_regex<BidiIter>::compile(const InputRange&, boost::xpressive::basic_regex<BidiIter>::flag_type) [with InputRange = std::basic_string<char>, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, boost::xpressive::basic_regex<BidiIter>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' boost_regex_test.cpp:9:57: instantiated from here /work/loc1/boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: warning: the result of the conversion is unspecified because '-0x00000000000000001' is outside the range of type 'boost::numeric::int_float_mixture_enum' [-Wconversion]

1 1

Re: [boost] FW: FW: Proposal for a Differential Evolution C++ library
by Adrian Michel 12 Dec '11

12 Dec '11

On 12/12/2011 7:19 AM, Sebastian Redl wrote: > Your website went down, it redirects the webhost's site. My apologies - I ftp-ed an updated version of the documentation with the wrong structure - instead of it being located at .../de/doc/html/... it was at .../de/html, as Thomas Kimpel noted in his reply. It should work again shortly. Also, I realized posting urls for individual documentation pages was a mistake, as I don't believe doxygen guarantees they will stay the same as the documentation evolves, so if you notice any errors when accessing the Overview or Tutorial urls, try the documentation home page http://www.amichel.com/de/doc/html/. Thanks both. Adrian

1 0

A demonstration of why horrendous error messages can destroy usability
by Gregory Crosswhite 12 Dec '11

12 Dec '11

At the unfortunate risk of reopening a poisonous argument, I just wanted to relate an experience I had just earlier today to emphasize a point that I and others tried to make a couple of weeks ago. For the last couple of days I have been trying to get Digikam to compile on my machine using MacPorts. Getting software written for Linux to compile on OSX is always a bit of a black art, so I wasn't surprised when I started running into hurdles. The first problem that I ran into was that I had set Python 3.1 to be my default rather than Python 2.7, which screwed up the libplist CMake configuration script; fortunately, although I had to scratch my head for a few minutes, it was clear roughly where the error was taking place and that gave me enough information to eventually figure out where the problem was. I also went ahead and filed a bug report to MacPorts to let them know about this problem. After that it was smooth sailing until I got to the final package, Digikam itself. Unfortunately, it refuses to build. Why is that? For reasons that apparently took an overwhelming *56 kilobytes of error message* to explain. (See attached, if you dare. ) Now, you could argue that this is the fault of the compiler for not being more helpful, the fault of Digikam for using deprecated methods, the fault of MacPorts for creating a bad environment for configuration, or whatever else you want. You could also argue that were I familiar with Boost and/or the Digikam codebase then the implication of this message would be obvious --- heck, maybe it even *is* obvious to many of the people here. All of this is beside the point, though. I am not an expert in any of these codebases and I really don't care whether it is ultimately the fault of Boost, Digikam, Qt, MacPorts, or the compiler for producing such horrendous error messages. All that matters to me is that these pages of error messages are so overwhelming that they make it very difficult for me to get any sense at all of what kind of thing is going wrong so that I can track down what needs to be done to fix it. Furthermore, the error message is such a mess that it is hard for me to even *motivate* myself to *want* to go through it to figure out where is going on, and seeing the impact that this kind of thing can have on end users really turns me off a bit from the idea of continuing to use Boost libraries in my projects in the future. That is to say, I had heard people in the past say that they actively avoid Boost (and sometimes even C++) because of the way they introduced nasty complexities (like horrible error messages), and I used to (politely :-) ) scoff at them because I figured that they were overstating the problems in practice. Now however, having experienced these problems from the viewpoint of a casual user who just wants to get some darn code to compile so that I can run a program I wanted to try out, I can really appreciate their point. To be perfectly clear, I am not saying that this has made me never want to use Boost again, for I really hate rolling out my own code to solve a problem when somebody else has already developed and tested a solution for me. :-) My point is exactly and *only* the following: horrendous error messages are a *big deal* with a *serious impact* on usability not only for the developers using a library, but for end-users who want to compiler and use the software being developed. Most people here fortunately already seem to recognize this, but I have been truly shocked to hear so many arguments that horrendous error messages are *not* a serious problem, either because they are someone else's fault, because they only occur when the code is wrong, or --- worst of all --- because it is ultimately the fault of the user for being ignorant or lazy when he or she cannot quickly figure out what the problem causing the message was. So I just wanted to share this anecdote to provide a real-world example where horrendous error messages have added an incredible cost for a relatively technically experienced end-user to actually use a particular piece of software. And once more, I am sorry to bring this tired point up again, it's just that the experience I had today really reminded me just how frustrating these kinds of error messages can be, and the absurdity of denying that this is in any way a problem. I feel very strongly that the ultimate goal of writing software is not merely to push the boundaries of what we can do but to provide people with tools that make their lives easier. Horrendous error messages, even when there is no better design to accomplish a particular task (in C++, at least), are *really bad things* and should *not* be dismissed as something not worth fussing about, *especially* when fault is then placed on the *user* (as in some cases it sadly seemed to be) for being too ignorant or lazy to be willing to go to the trouble to decipher them. I am not claiming to know what the solution is to these kinds of issues, and in many cases there might not even be better solutions given the current design of C++. I was just very concerned to see that in the eyes of many the presence of such error messages are not considered in any way to be a problem (*) with a library, and to hear it claims that if anything users turned off by horrendous messages are simply being lazy by not just sucking them up for the good of the cause. Cheers, Greg (*) And let me be clear that by "problem" here I really do mean "less than ideal circumstance" rather than "flaw", because in many cases these libraries are very elegantly designed codes which are probably close to the optimal solution given the limits imposed by the C++ language.

5 8

[BGL] reverse_graph
by Fabien Castan 12 Dec '11

12 Dec '11

Hi, I have some troubles using boost::transpose_graph since boost 1.48. See the sample code. Fabien #include <boost/graph/graph_traits.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/copy.hpp> #include <boost/graph/transpose_graph.hpp> template<class GraphIn, class GraphOut> class Copier { public: Copier( const GraphIn& gIn, GraphOut& gOut ) : _gIn(gIn) , _gOut(gOut) {} template<class VIn, class VOut> void operator()(const VIn& vIn, VOut& vOut) { _gOut[vOut] = _gIn[vIn]; } private: const GraphIn& _gIn; GraphOut& _gOut; }; struct CustomVertex { }; struct CustomEdge { }; typedef boost::adjacency_list< boost::setS, // disallow parallel edges (OutEdgeList) boost::vecS, // vertex container (VertexList) boost::bidirectionalS, // directed graph CustomVertex, CustomEdge, boost::no_property, // no GraphProperty boost::listS // EdgeList > GraphContainer; int main( int argc, char** argv ) { const GraphContainer a; GraphContainer b; Copier< GraphContainer, GraphContainer > copier( a, b ); // still works as before boost::copy_graph( a, b, boost::vertex_copy(copier).edge_copy(copier) ); // works with boost 1.47, but doesn't compile with boost 1.48 boost::transpose_graph( a, b, boost::vertex_copy(copier).edge_copy(copier) ); //<<<<< }

2 4

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 12 Dec '11

12 Dec '11

I was asked this question regarding DE: >... The Boost Graph Library (BGL) >is often used for graph optimization purposes, and the geometry stuff >is used to do things like lay out integrated circuits with lots of >costs and constraints. There are the math and statistical functions. >Are these and other Boost libraries complementary or orthogonal to >your library? > I'm not familiar with BGL, but from its documentation, DE and BGL seem to be rather orthogonal. As for the math and statistical functions, I believe DE could complement these as yet another mathematical tool. Adrian Michel

1 0

Re: [boost] FW: Proposal for a Differential Evolution C++ library
by Adrian Michel 12 Dec '11

12 Dec '11

Hi Beman On 12/11/2011 6:31 PM, Beman Dawes wrote: > >> Would there be interest in a C++ Differential Evolution optimization (DE) >> library as part of boost? > > Seems interesting, and you've clearly put in a lot of work, and the > documentation makes a good initial impressions. But see below... > Thanks! >> The full documentation is at http://www.amichel.com/de/doc/html but I'd >> suggest these pages for a first read >> http://www.amichel.com/de/doc/html/dd/d53/overview.html and >> http://www.amichel.com/de/doc/html/db/d4e/tutorial.html . > > After skim reading the overview and the beginning of the tutorial, I > was left with several unanswered questions: > > * What are some practical scientific or engineering problems that DE > is good for? I personally got interested in DE while doing some research in the area of algorithmic trading system optimization. But DE is generic - it can be used to optimize any function that would otherwise be very hard or impossible to optimize using more traditional methods. DE is used in many areas, some of which are listed here: http://www.icsi.berkeley.edu/~storn/code.html#appl and here: http://www.icsi.berkeley.edu/~storn/code.html#comm or to summarize: chemistry, electronics, physics, agriculture, telecommunications etc. > I'm having trouble calibrating - is your library > primarily aimed at research and academic problems or is it an everyday > tool for use in a broad spectrum of organizations? > I believe the answer is "both". > * Who is the library aimed at? Is the library most likely to be used > by optimization specialists who already know about DE or is it > something that can be used by a wide range of programmers? > I tried to design the library so that it can be easily used "out of the box" by all programmers, who can choose any of the predefined policy classes for default behavior. The de_test application illustrates this usage mode: the user can implement a de::objective_function derived class with their own function to optimize, and then build and run the application to get the best output. However, those interested in tweaking its behavior, can create their own policy classes and override the defaults. One of the obvious advantage of a standardized DE library is that these customized components could then be shared with the community at large. BTW, DE has the added benefit of not having been patented by its authors, for the very purpose of making it widely available. Thanks, Adrian Michel

1 0

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 12 Dec '11

12 Dec '11

Hi Oliver, On 12/11/2011 9:52 PM, Oliver Kullmann wrote: > > >> I took a peak at the overview and some of the other pages and from >> what I can see initially, it looks like a very useful library for >> artificial intelligence. I have very limited knowledge in the field >> but this is something that grabs my interest, so if it's made public >> I'll definitely use it for future projects that would benefit from >> it. Of course whether it is suitable for Boost is for others to >> determine. >> >> Philip Bennefall >> > > It seems to me that the application domain is not "artificial intelligence", > but arbitrary optimisation problems. > In general, I would like to see more algorithms in Boost. > This library seems a good example, judging from its applicability: > it seems to be widely applicable. > > Oliver > Yes, you are correct, DE is generic, doesn't know or care what the nature of the objective function is. Thanks, Adrian

1 0

Re: [boost] Boost.Thread and Boost.Move collision
by onlyone＠senet.com.au 11 Dec '11

11 Dec '11

>Vicente J. Botet Escriba: >> Le 01/12/11 18:11, onlyone(a)senet.com.au a ?crit : >>>>> 1) Move Boost.Move elements to boost::move:: namespace >>>>> 2) Move Boost.Thread elements to boost::thread namespace >>>>> 3) Modify Boost.Thread to make use of Boost.Move >>>>> >>>> FWIW, I think 3) is what sounds obvious to me. Now maybe there's >>>> reasons to >>>> avoid coupling those libraries together but I'm not sure what they >>>> would be. >>>> >>>> Philippe >>> Hi, >>> I have been working on a patch to do just that. I have not run into >>> any major issues so far. Modifying Boost.Thread to use >>> Boost.Move solves two problems: >>> >>> 1) It fixes the name collision (obviously). >>> 2) It allows types that have been designed to use the Boost.Move >>> emulation to interoperate with Boost.Thread. (This is relevant >>> for futures/promises.) >>> >> Could you post the patch or attach it to a Trac ticket? >> >Any news of this patch? > I have been working on it. I was able to implement the basic functionality in a matter of hours (Boost.Move is very easy to use). Unfortunately, I have been having trouble "Boostifying" the code, as I am unfamiliar with the reasons for many of the workarounds in the existing code (I am worried about causing regressions in these). I have not yet started on the documentation or tests. This patch is still my #1 priority, so expect it soon! Regards, Evan Wallace

2 1

update from 1_44 to 1_48: build questions
by Oliver Kullmann 11 Dec '11

11 Dec '11

Hello, we want to update from 1_44_0 to 1_48_0. Our old build-process is as follows (for Linux): 1. cd tools/jam/src 2. CC="$(gcc_call)" CFLAGS="-fno-strict-aliasing" ./build.sh cc 3. cp bin.*/bjam $(boost_base_build_dir) 4. cd ../../.. 5. echo "using gcc : $(gcc_version) : $(gcc_call) : ;" > $(boost_base_build_dir)/bjam_config 6. $(boost_base_build_dir)/bjam --user-config=$(boost_base_build_dir)/bjam_config --prefix=$(boost_installation_dir) --build-dir=$(boost_build_dir) install --without-python --without-wave --without-mpi -sBZIP2_INCLUDE=$(bzip2_source_library) -sBZIP2_LIBPATH=$(bzip2_link_library) It seems that "b2" is (just) bjam? However it is not really clear from the documentation how to build (and use) bjam (apparently via boostrap?)? And then apparently some of the above parameters of bjam, for example prefix, are now parameters of bootstrap? We would be glad if somebody could tell us (or some link) how to update the above process. Thanks in any case for your consideration. Oliver

2 2

[chrono] i/o to locale or not to locale
by Vicente J. Botet Escriba 10 Dec '11

10 Dec '11

Hi all, currently Chrono provides a limited localization interface for duration and time_point I/O that is not satisfactory. The current implementation Boost.Chrono V1.2 (Boost 1.48) is based on the alternative A1 (see below) in which the hour,minute,second and the epoch can be localized. This could give the impression that chrono i/o is localized, but as Aryton as signaled it is not enough. I'm working on redesigning the chrono i/o in order to make a proposal with Howard Hinnant to the C++ committee. Two main alternatives A1- follow the formatting of recognized international body as ISO. A2- Add localization of specific units and epoch to the preceding format. It seems that the localized alternative seems to have less chances to be adopted, as no other library in the standard is providing these kind of facilities, and locale message facility is not completely satisfying. Things could change if we had a concrete proposal for improving the standard locale library (in which Aryton seems to be working IUC). More detail on the two alternatives: A1- Provide formatted i/o following the ISO 80000 http://en.wikipedia.org/wiki/ISO/IEC_80000, http://en.wikipedia.org/wiki/ISO_31-1, The format for duration could be <value> <unit> With unit been day, hour, minute, second, decisecond, centisecond, ..., decasecond, hectosecond, ... Note that the unit is always in singular form and in English. Next follows several valid inputs for duration 3 day 9 hour 1 second 0 second -1 second 3.77 millisecond 34 [1/30]second time_points could be formatted as <duration> <since epoch> where <since epoch> is a string that identifies the starting point of the epoch's clock, e.g. since boot, since process startup, .... The string associated to each clock are fixed and configurable specializing the trait clock_string Next follows several valid inputs for time_point. 123456 second since boot A1.a We can also consider ISO 8601. IMO, an acceptable format for durations could be a variation of the extended format independently of the date. <hours>:<minutes>:<seconds>[.fractional_seconds] Note that <hours> here is not limited to 24, and gives the total number of hours. A1.b An additional alternative could be to represent a duration as following a variant of the period representation: P[n]Y[n]M[n]DT[n]H[n]M[n]S in which the year and month are represented by days. E.g. P[n]DT[n]H[n]M[n]S[n]F P1234DT12H30M5S555F A2 - Make durations and time point i/o locale dependent. Based on the previous alternative, add the possibility to add specific locale facets that could format a duration following the pattern <value> <unit> <unit> <value> <hours><:><minutes><:><seconds>[<.>fractional_seconds] Here <value> and <unit> will be formatted following the specific locale and in this case the unit could have specific plural forms. For example in French the user could specialize the facets so that she could get 1 jour 3 jours 9 heures 1 seconde 0 secondes -1 seconde 3.77 milliseconds 34 [1/30] de seconde and in Spanish 1 segundo 0 segundo -1 segundo Add the possibility to add specific locale facets that could format a time_point following the pattern <duration> <epoch> <epoch> <duration> system_clock::time_point is a special case that should be formatted as a localized date, relative to the epoch 1900/01/01. A3 - Add on top of A2 some _byname facets. The fist alternative is in line with the money standard locale category that uses standard symbols, as $ or USD. It has the drawback that the <value> could be localized while the <unit> is not, e.g. 1,234 second Note the use of ','. The third alternative is IMO closer to the user expectations, but needs a better locale messages/by_name facet. The second alternative is a pragmatic one that left the possibility to build A3 when a satisfying messages/by_name facet is available. Boost.Chrono 2.0 in the trunk is a prototype of A2, that doesn't provides facets by locale name, only a default English implementation. That means that for the time been, the user needs to imbue a locale with her specific facet to get the expected localization (See french.cpp example in the SVN repository) What the Boost community think about this? Towards which alternative should Boost.Chrono move? Should Boost.Chrono wait until a concrete standard proposal is accepted? Thanks in advance, Vicente

2 6

Re: [boost] Boost.Thread and Boost.Move collision
by onlyone＠senet.com.au 10 Dec '11

10 Dec '11

>> >> 1) Move Boost.Move elements to boost::move:: namespace >> 2) Move Boost.Thread elements to boost::thread namespace >> 3) Modify Boost.Thread to make use of Boost.Move >> > >FWIW, I think 3) is what sounds obvious to me. Now maybe there's reasons to >avoid coupling those libraries together but I'm not sure what they would be. > >Philippe Hi, I have been working on a patch to do just that. I have not run into any major issues so far. Modifying Boost.Thread to use Boost.Move solves two problems: 1) It fixes the name collision (obviously). 2) It allows types that have been designed to use the Boost.Move emulation to interoperate with Boost.Thread. (This is relevant for futures/promises.) Evan Wallace

2 2

Phoenix Quoting
by paul Fultz 09 Dec '11

09 Dec '11

Hi, Is there a way using Phoenix to do quoting? I would like to do something like this: quote x("x"); string s = (x < 3 and x > 0)(); //s = "x < 3 and x > 0" Is there some kind of quote class in Phoenix or a way to create a quote class? Thanks, Paul

3 5

[boost-dev] compilation warnings questions by a newbee
by Rai, Neeraj 09 Dec '11

09 Dec '11

Hi, I am writing my first boost program and having trouble with the compiler warning against boost 1.44.0. Is there any way to get rid of those warnings so I can focus on real warnings in my code ? This seems to happen with newer version of g++ : tried 4.4.5 and 4.6 The gist of warning is : boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: warning: the result of the conversion is unspecified because '-0x00000000000000001' is outside the range of type 'boost::numeric::udt_builtin_mixture_enum' [-Wconversion] Any help or pointers are appreciated. Neeraj ====== The following program is a cut down version of my code, just declares sregex #include <iostream> #include <boost/xpressive/xpressive.hpp> int main (int _argc, const char** _argv) { std::cout << "argc=" << _argc << " argv=" << _argv << std::endl; using namespace boost::xpressive; std::string keyword(""); sregex const re(sregex::compile(keyword, sregex::icase)); } ====== The following cmd is used to build it (tried g++ v 4.4.5 and 4.6 with same results) g++ -ftemplate-depth-128 -O0 -fno-inline -Wall -g -Wconversion -Wno-strict-aliasing -Wextra -Wnon-virtual-dtor -Wno-missing-field-initializers -Wno-array-bounds -Wno-ignored-qualifiers -Wno-parentheses -Wno-strict-aliasing -fPIC -DBOOST_ALL_NO_LIB -I/work/loc1/atddds -I/work/loc1/boost_1_44_0/include -Iinclude -c -o boost_regex_test.o boost_regex_test.cpp ====== The following cmd is used to build it (tried g++ v 4.4.5 and 4.6) g++ -ftemplate-depth-128 -O0 -fno-inline -Wall -g -Wconversion -Wno-strict-aliasing -Wextra -Wnon-virtual-dtor -Wno-missing-field-initializers -Wno-array-bounds -Wno-ignored-qualifiers -Wno-parentheses -Wno-strict-aliasing -fPIC -DBOOST_ALL_NO_LIB -I/work/loc1/atddds -I/work/loc1/boost_1_44_0/include -Iinclude -c -o boost_regex_test.o boost_regex_test.cpp In file included from /work/loc1/boost_1_44_0/include/boost/mpl/integral_c.hpp:32:0, from /work/loc1/boost_1_44_0/include/boost/type_traits/integral_constant.hpp:11, from /work/loc1/boost_1_44_0/include/boost/type_traits/detail/bool_trait_def.hpp:15, from /work/loc1/boost_1_44_0/include/boost/type_traits/is_volatile.hpp:40, from /work/loc1/boost_1_44_0/include/boost/type_traits/remove_const.hpp:14, from /work/loc1/boost_1_44_0/include/boost/proto/proto_fwd.hpp:25, from /work/loc1/boost_1_44_0/include/boost/xpressive/xpressive_fwd.hpp:53, from /work/loc1/boost_1_44_0/include/boost/xpressive/detail/detail_fwd.hpp:24, from /work/loc1/boost_1_44_0/include/boost/xpressive/regex_primitives.hpp:21, from /work/loc1/boost_1_44_0/include/boost/xpressive/xpressive_static.hpp:24, from /work/loc1/boost_1_44_0/include/boost/xpressive/xpressive.hpp:18, from boost_regex_test.cpp:2: /work/loc1/boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>': /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/meta.hpp:30:13: instantiated from 'boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u> >' /work/loc1/boost_1_44_0/include/boost/mpl/if.hpp:67:11: instantiated from 'boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u> >, boost::mpl::identity<boost::numeric::convdetail::get_subranged_BuiltIn2BuiltIn<unsigned char, int> >, boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)1u> >, boost::mpl::identity<boost::mpl::identity<boost::numeric::convdetail::subranged_BuiltIn2Udt<unsigned char, int> > >, boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)2u> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2BuiltIn<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2Udt<unsigned char, int> > > > >' /work/loc1/boost_1_44_0/include/boost/mpl/eval_if.hpp:37:41: instantiated from 'boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u> >, boost::mpl::identity<boost::numeric::convdetail::get_subranged_BuiltIn2BuiltIn<unsigned char, int> >, boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)1u> >, boost::mpl::identity<boost::mpl::identity<boost::numeric::convdetail::subranged_BuiltIn2Udt<unsigned char, int> > >, boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)2u> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2BuiltIn<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2Udt<unsigned char, int> > > > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/meta.hpp:82:9: instantiated from 'boost::numeric::convdetail::ct_switch4<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)1u>, mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)2u>, boost::numeric::convdetail::get_subranged_BuiltIn2BuiltIn<unsigned char, int>, boost::mpl::identity<boost::numeric::convdetail::subranged_BuiltIn2Udt<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2BuiltIn<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2Udt<unsigned char, int> > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/udt_builtin_mixture.hpp:45:9: instantiated from 'boost::numeric::convdetail::for_udt_builtin_mixture<mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, (boost::numeric::udt_builtin_mixture_enum)0u>, boost::numeric::convdetail::get_subranged_BuiltIn2BuiltIn<unsigned char, int>, boost::mpl::identity<boost::numeric::convdetail::subranged_BuiltIn2Udt<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2BuiltIn<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Udt2Udt<unsigned char, int> > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/is_subranged.hpp:206:11: [ skipping 9 instantiation contexts ] /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:281:13: instantiated from 'boost::xpressive::detail::sequence<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::parse_alternates(FwdIter&, FwdIter) [with FwdIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:212:75: instantiated from 'boost::xpressive::basic_regex<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile_(FwdIter, FwdIter, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type, std::forward_iterator_tag) [with FwdIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:120:60: instantiated from 'boost::xpressive::basic_regex<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile(InputIter, InputIter, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type) [with InputIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:129:71: instantiated from 'typename boost::disable_if<boost::is_pointer<InputRange>, boost::xpressive::basic_regex<BidiIter> >::type boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile(const InputRange&, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type) [with InputRange = std::basic_string<char>, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, typename boost::disable_if<boost::is_pointer<InputRange>, boost::xpressive::basic_regex<BidiIter> >::type = boost::xpressive::basic_regex<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/basic_regex.hpp:193:61: instantiated from 'static boost::xpressive::basic_regex<BidiIter> boost::xpressive::basic_regex<BidiIter>::compile(const InputRange&, boost::xpressive::basic_regex<BidiIter>::flag_type) [with InputRange = std::basic_string<char>, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, boost::xpressive::basic_regex<BidiIter>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' boost_regex_test.cpp:9:57: instantiated from here /work/loc1/boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: warning: the result of the conversion is unspecified because '-0x00000000000000001' is outside the range of type 'boost::numeric::udt_builtin_mixture_enum' [-Wconversion] /work/loc1/boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>': /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/meta.hpp:30:13: instantiated from 'boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u> >' /work/loc1/boost_1_44_0/include/boost/mpl/if.hpp:67:11: instantiated from 'boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u> >, boost::mpl::identity<boost::numeric::convdetail::get_subranged_Int2Int<unsigned char, int> >, boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)1u> >, boost::mpl::identity<boost::mpl::identity<boost::numeric::convdetail::subranged_Int2Float<unsigned char, int> > >, boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)2u> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Int<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Float<unsigned char, int> > > > >' /work/loc1/boost_1_44_0/include/boost/mpl/eval_if.hpp:37:41: instantiated from 'boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u> >, boost::mpl::identity<boost::numeric::convdetail::get_subranged_Int2Int<unsigned char, int> >, boost::mpl::eval_if<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)1u> >, boost::mpl::identity<boost::mpl::identity<boost::numeric::convdetail::subranged_Int2Float<unsigned char, int> > >, boost::mpl::if_<boost::numeric::convdetail::equal_to<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)2u> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Int<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Float<unsigned char, int> > > > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/meta.hpp:82:9: instantiated from 'boost::numeric::convdetail::ct_switch4<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)1u>, mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)2u>, boost::numeric::convdetail::get_subranged_Int2Int<unsigned char, int>, boost::mpl::identity<boost::numeric::convdetail::subranged_Int2Float<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Int<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Float<unsigned char, int> > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/int_float_mixture.hpp:63:9: instantiated from 'boost::numeric::convdetail::for_int_float_mixture<mpl_::integral_c<boost::numeric::int_float_mixture_enum, (boost::numeric::int_float_mixture_enum)0u>, boost::numeric::convdetail::get_subranged_Int2Int<unsigned char, int>, boost::mpl::identity<boost::numeric::convdetail::subranged_Int2Float<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Int<unsigned char, int> >, boost::mpl::identity<boost::numeric::convdetail::subranged_Float2Float<unsigned char, int> > >' /work/loc1/boost_1_44_0/include/boost/numeric/conversion/detail/is_subranged.hpp:184:35: [ skipping 10 instantiation contexts ] /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:281:13: instantiated from 'boost::xpressive::detail::sequence<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::parse_alternates(FwdIter&, FwdIter) [with FwdIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:212:75: instantiated from 'boost::xpressive::basic_regex<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile_(FwdIter, FwdIter, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type, std::forward_iterator_tag) [with FwdIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:120:60: instantiated from 'boost::xpressive::basic_regex<BidiIter> boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile(InputIter, InputIter, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type) [with InputIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/regex_compiler.hpp:129:71: instantiated from 'typename boost::disable_if<boost::is_pointer<InputRange>, boost::xpressive::basic_regex<BidiIter> >::type boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::compile(const InputRange&, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type) [with InputRange = std::basic_string<char>, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, RegexTraits = boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> >, CompilerTraits = boost::xpressive::compiler_traits<boost::xpressive::regex_traits<char, boost::xpressive::cpp_regex_traits<char> > >, typename boost::disable_if<boost::is_pointer<InputRange>, boost::xpressive::basic_regex<BidiIter> >::type = boost::xpressive::basic_regex<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >, boost::xpressive::regex_compiler<BidiIter, RegexTraits, CompilerTraits>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' /work/loc1/boost_1_44_0/include/boost/xpressive/basic_regex.hpp:193:61: instantiated from 'static boost::xpressive::basic_regex<BidiIter> boost::xpressive::basic_regex<BidiIter>::compile(const InputRange&, boost::xpressive::basic_regex<BidiIter>::flag_type) [with InputRange = std::basic_string<char>, BidiIter = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, boost::xpressive::basic_regex<BidiIter>::flag_type = boost::xpressive::regex_constants::syntax_option_type]' boost_regex_test.cpp:9:57: instantiated from here /work/loc1/boost_1_44_0/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: warning: the result of the conversion is unspecified because '-0x00000000000000001' is outside the range of type 'boost::numeric::int_float_mixture_enum' [-Wconversion]

2 1

[filesystem] boost::filesystem::copy
by Tim Blechmann 09 Dec '11

09 Dec '11

hi all, is there any reason, why boost::filesystem v3 does not provide the copy function? it seems to be implemented in namespace boost::filesystem3, but it is not pulled into namespace boost::filesystem. thanks, tim

2 1

mail quotes color coding
by Maxim Yanchenko 09 Dec '11

09 Dec '11

Hi Boosters, If you're using one of web-based mailing list web-sites (like GMane or Google Groups), you may find this GreaseMonkey script useful: http://userscripts.org/scripts/show/92919 It adds coloring of different levels of quotation similar to lists.boost.org. Enjoy! Maxim

1 0

[Regex] Calling convention for _MANAGED code still somewhat broken when mixing native and managed projects
by Martin B. 09 Dec '11

09 Dec '11

Hi there! Background ---------- The header boost/regex/config.hpp currently contains the following code: #if defined(BOOST_MSVC) && (BOOST_MSVC >= 1200) && defined(_MSC_EXTENSIONS) #if defined(_DEBUG) || defined(__MSVC_RUNTIME_CHECKS) || defined(_MANAGED) # define BOOST_REGEX_CALL __cdecl #else # define BOOST_REGEX_CALL __fastcall #endif # define BOOST_REGEX_CCALL __cdecl #endif the `|| defined(_MANAGED)` was added in 2006 (SVN history) to cater for the fact that __fastcall does not work on managed C++/CLI (/clr compiled) projects. See, e.g. this: http://lists.boost.org/boost-users/2004/12/9203.php Problem ------- This is really quite suboptimal, as with the solution as posted above, you need *a separate* lib/dll for managed-C++ and native-C++ Projects. Especially for the DLL, this is a non-solution, as I can only have one DLL for projects/modules that are used in the same application. _MANAGED is a define set by the VC compiler if the /clr switch is present, therefore it is actually never set when compiling the boost libraries. Of course you can set it via `define=_MANAGED` and you can then use these generated libraries from a C++/CLI project. (Which I have done: ... `define=_MANAGED` ... --with-regex ...) BUT: You can now *not* use these libraries from a non-managed ("native") C++ project as that, obviously, doesn't have _MANAGED set, and unlike with the boost build, I don't think it's feasible to define this wholesale for a native project. (And anyways, I'm rather hesitant to define this myself.) Obviously, I could just edit regex/config.hpp, but that is a maintenance nightmare of its own here. Solution -------- I *think* what really would be needed would be a define that the user could specify, something like this: #if defined(_DEBUG) || ... || defined(BOOST_REGEX_NO_FASTCALL) # define BOOST_REGEX_CALL __cdecl ... (I have attached a patch, hope this works.) Would this make sense? To add a short rationale: We use C++/CLI projects as bridges between managed and native modules of our application. In the C++ part, we use boost regexes, and sometimes it would make sense to reuse some native code in a C++/CLI bridge module. If this native code uses Boost.Regex, this doesn't work currently, as the native code file will also be compiled with /clr, and then we have a calling convention mismatch and can't use our boost-regex-dll. cheers, Martin

2 2

[1.49.0] Schedule finalized
by Beman Dawes 08 Dec '11

08 Dec '11

The 1.49.0 schedule has been posted to the Boost C++ Libraries calendar. Milestones (all dates are Mondays): December 19: 1.49.0 (I.E. branches/release) Closed for new libraries. December 26: Quality checks begin January 9: Closed for major changes January 16: Closed for all changes January 23: Beta target date February 20: Release target date The longer period between the beta and release is intended to allow more time to respond to problem reports. --The Release Team

1 0

[msm] deferral stack overfolw
by Richard Szabo 08 Dec '11

08 Dec '11

Hi Christophe just playing around with event deferral I have found a problem which leads to a stack overflow it ends in an infinite loop if I want to defer 2 events in the same state. see attached example it somehow similar to the problem we had earlier but that was fixed ... I have ran this test on MSM trunk version from yesterday. Cheers Richie

2 8

[build] Little help required
by Antony Polukhin 08 Dec '11

08 Dec '11

Hi, I need to create Jamfile.v2 where one of the tests must be compiled on MSVC compilers with additional flag /Zc:wchar_t- How shall I change the following lines: test-suite conversion : # A lot of [ run ... ] lines [ run lexical_cast_typedefed_wchar_test.cpp ../../test/build//boost_unit_test_framework/<link>static ] # Requires /Zc:wchar_t- ; Best regards, Antony Polukhin

2 4

Re: [boost] Boost.Math and Math Constants
by Brent Spillner 08 Dec '11

08 Dec '11

On Wed, 7 Dec 2011 15:33:21 Paul A. Bristow wrote: >John Maddock has now added a new cunning feature that allows the vast majority of users who just >want a built-in double to get the constants quickly as plain variables. So in non-template code, >users can write > > using boost::math::double_constants; > double area = pi * r * r; > >and users can read the equations easily. > >(Float and long double are similarly available in their own namespaces). It's a little bit of work up front, but if you define a custom type with separate overloads for each arithmetic operator/operand type combination (i.e. *(float), *(double), +(float), +(double), etc.) you should be able to offer a single namespace with constants that auto-promote (or demote) to the right type in expressions. That's also easily extensible to user-defined storage classes such as an extended precision float, and I think it's more maintainable since the using declaration (which is now untyped) can't get out of sync with the usage context. To prevent ambiguous overloads (in contexts where the constant itself is supplied as an argument to a polymorphic function, not in expressions), you can leave just one type (perhaps double) as implicitly castable-to, with explicit casts for the others. That seems more Boost-y to me, at any rate.

4 3

[stl_ext_adv] ] Interest in advanced data structures
by Vadim Stadnik 08 Dec '11

08 Dec '11

Hi all, Advanced data structures (ADS) offer useful STL extensions that are not possible or not efficient with basic data structures, such as arrays, linked lists and red-black trees. The project https://github.com/vstadnik/stl_ext_adv http://dl.dropbox.com/u/51041088/stl_ext_adv_doc/index.html focuses mainly on a generalized and unified computer representation of sequences using the augmented B+ trees. It provides the following STL extensions: - The sequence container supports random access iterators and a union of interfaces of STL containers: vector, list and deque. This sequence offers the advantage of efficient update operations with logarithmic running time compared with linear running time of the same operations of std::vector. - The associative containers (set, multiset, map and multimap) with random access iterators. - The enhanced random access iterators effectively address the fundamental problem of the iterator invalidation. - The function accumulate() with logarithmic computational complexity can significantly improve performance of many practically important algorithms and applications, such as the numerical integration, the statistics, the data analysis etc. The examples demonstrate how to improve the computational complexity from O(N) to O(log N) in the following applications and problems: - numerical integration. - calculation of mean value and standard deviation; - calculation of weighted mean value; - testing if any number of consecutive elements are equal; - counting intersections of one interval with sequence intervals; Is there an interest in this project and implemented STL extensions? Interest in potentially useful, but not yet implemented algorithms and specialized containers: 1. The function accumulate() with constant computational cost. With this function some user algorithms, such as the numerical integration, can come close to the absolute theoretical limit of the computational cost. The function can be implemented through iterators enhanced with functionality of accumulators. For more details, see the section “Random access iterators” in the documentation. 2. The functions sequence::splice() with logarithmic running time in the worst case. Note that functions std::list::splice() provide in many cases constant computational cost, however, in the worst case the cost is linear. 3. Any other potentially useful specialized containers, iterators or algorithms? Augmented B+ trees are versatile and powerful data structures. They can be designed to maximize efficiency of particular algorithms and programming solutions. The limitation of specialized containers is that the computational cost of some other operations may increase. About augmented red black trees. The augmented red black trees can also support various STL extensions. The red black trees are yet out of the scope of this project for the reasons explained in the documentation. However, historically augmented red-black trees are probably the first ADS that could extend STL, since the method of augmenting red black trees was described as early as in 1990 [T.H. Cormen, C.E. Leiserson and R.L. Rivest.” Introduction to Algorithms” (1st ed.). MIT Press and McGraw-Hill, 1990]. This means, in particular, that the very first version of STL could provide associative containers with random access iterators. Also, as I understand the previously submitted project https://github.com/boost-vault/Containers/blob/master/countertree.zipimplem… containers based on the augmented red black trees. It is hardly possible to make an exact prediction, but without a doubt future versions of STL will benefit from advanced data structures. Regards, Vadim Stadnik

11 29

boost.heap in trunk
by Tim Blechmann 07 Dec '11

07 Dec '11

hi all, i've imported my boost.heap library into trunk. it currently won't compile with gcc, but i've submitted patches against boost.parameter [1] and boost.fusion [2]. i hope they are applied, soon. i managed to integrate it into the documentation system, but it still needs to be integrated into the bug tracker and the regression test system. can i do that myself? tim [1] https://svn.boost.org/trac/boost/ticket/6214 [2] https://svn.boost.org/trac/boost/ticket/6215

3 2

Re: [boost] c++11 and gcc 4.7
by Leo Goodstadt 07 Dec '11

07 Dec '11

> > From: Bruce Adams <tortoise_74(a)yahoo.co.uk> > Date: Tue, 6 Dec 2011 19:08:56 +0000 (GMT) > > Hi, > I am attempting to do a cost benefit analysis to justify adopting the > subset of C++11 that is supported by gcc 4.7. > As threads are one of the biggest features of c++11, I may be asked to > justify just boost.thread vs > gcc 4.7 + boost.thread. You may also wish to consider using a higher level threading library on top of std::thread / boost::thread. We have been using Intel Threading Building Blocks (http://threadingbuildingblocks.org/) for a while now, and it seems to live very happily alongside Boost. TBB means that you don't have to roll your own thread pools, or adjust the parallelism each time your programme is run. It is also a very thin layer in terms of efficiency. The modern trend across many programming languages also seems to move away from using (manual) synchronisation primitives whenever possible (just as "raw" new and delete has become rare in c++ over the past 20 years). TBB allows complex pipelines to be supported quite naturally in terms of a data flow. My only reservation is that it requires dynamic linking, which is not always desirable or even possible. Finally, the extra level of abstraction in TBB probably means that the onus on supporting varying standards of c++ 11 conformance falls on Intel and not you or your company! Leo

1 0

Is there any interest in a library which solves C++ class reflection feature just like Java does?
by jinhua luo 07 Dec '11

07 Dec '11

Hi, In brief, I'd designed and implemented somehow C++ class reflection based on boost libraries. It has some unique advantages: a) it doesn't require code generator b) platform independent and compiler independent (I tested it on Windows and Linux, with vs2008 and gcc respectively) c) it's non-intrusive for the class definition, instead, you just need to declare and describe your class via some straightforward macros anywhere (header file or source file, and may be within any namespace), which also means you can wrap an external third-party library (which you have no way to touch the source codes) and reflects it classes. d) Cross shared library boundary, you can dynamic load the shared library and reflect the classes within it, without need to export any symbol manunally in C wrapper function way e) the API looks like Java reflection API Below is some codes snippet to have an overview of this library: -----libTest.cpp---start--- #include <iostream> #include <string> #include <boost/reflection/reflection.hpp> namespace test { class AccountItf { public: virtual std::string getId() const = 0; virtual void setId(std::string id) = 0; }; #define ACCOUNT_INTERFACE_REFL_DECLARE \ BOOST_REFL_INTERFACE(test::AccountItf) \ BOOST_REFL_CONST_METHOD(getId, std::string()) \ BOOST_REFL_METHOD(setId, void(std::string)) class Account : public AccountItf { std::string id; public: Account() : age(0) {} Account(std::string id, unsigned int age) : id(id), age(age) {} static void echo(Account* acct, std::string banner) { std::cout << banner + ": " << acct->getId() << std::endl; } std::string getId() const { return id; } void setId(std::string id) { this->id = id; } public: unsigned int age; }; //Account declaration for used by reflection //this declaration can be placed anywhere, even the header file BOOST_REFL_CLASS ( (test)(Account), //constructors BOOST_REFL_CONSTRUCTOR() BOOST_REFL_CONSTRUCTOR(std::string id, unsigned int age) //static methods BOOST_REFL_STATIC_METHOD(echo, void (Account* acct, std::string banner)) //properties BOOST_REFL_PROPERTY(age, unsigned int) //derived Inteface ACCOUNT_INTERFACE_REFL_DECLARE ) } -----libTest.cpp----end-- Compile the libTest.cpp into the libTest.dll or libTest.so. -----main.cpp----start-- #include <iostream> #include <string> using namespace std; #include <boost/reflection/reflection.hpp> using namespace boost::reflection; #if defined(BOOST_WINDOWS) #include <Windows.h> #else #include <dlfcn.h> #endif int main(int argc, char* argv[]) { #if defined(BOOST_WINDOWS) LoadLibraryA (argv[1]); #else dlopen(argv[1], RTLD_NOW); #endif Class t = Class::forName("test.Account"); boost::any obj = t.newInstance(std::string("Account-id-100"), (unsigned int)26); t.invokeStatic("echo", obj, std::string("TEST")); TypeInfoArray tArray; tArray.push_back(BOOST_REFL_TYPEID(std::string)); Method m1 = t.getMethod("setId", tArray); m1.invoke(obj, std::string("Account-id-200")); Method m2 = t.getMethod("getId"); boost::any ret = m2.invoke(obj); std::cout << "Account getId(): " << boost::any_cast<std::string>(ret) << std::endl; Property prop = t.getProperty("age"); prop.set(obj, (unsigned int)30); std::cout << "Account age: " << boost::any_cast<unsigned int>(prop.get(obj)) << std::endl; return 0; } -----main.cpp---end--- Compile the main.cpp into the executable and execute it: ./main libTest.dll it will output: TEST: Account-id-100 Account getId(): Account-id-200 Account age: 30 This library is very useful for framework-level design which needs C++ reflection, e.g. recently I'm working on somehow SQL mapping library for C++, just like MyBatis, and reflection makes possible to invoke the getter/setter of the object instances of classes specified in the XML file. Regards, JinHua

8 25

c++11 and gcc 4.7
by Bruce Adams 06 Dec '11

06 Dec '11

Hi, I am attempting to do a cost benefit analysis to justify adopting the subset of C++11 that is supported by gcc 4.7. I believe there is a strong case for doing so from just the minor features and library improvements. However, I am having a hard time putting together a convincing cost benefit analysis (actually I would like to be able to do this with parts of boost too - any help with this would be great). I have many subjective arguments for boost, C++11 and TR1 but am tasked with trying to justifying any change in terms of costs and benefits. One of Boost's roles is to fill in gaps in c++ support where compiler vendors have not yet provided an implementation. I know that g++4.7 has incomplete support for multi-threading but it is unclear whether this is in the core language area and/or library area and what platforms it applies to. I am specifically interested in GNU/Linux. The status of boost for gcc4.7 is unclear (I know it has not been officially released yet but the status for gcc 4.6.2 is also unclear). Both of the following links from www.boost.org are several years and versions out of date http://www.boost.org/doc/libs/1_34_0/status/compiler_status.html http://boost.sourceforge.net/regression-logs/ Will boost.thread work as a drop in replacement for std::thread or is anything missing or broken on the core language side? (On the gcc side I am also interested in whether std::thread is a sufficiently complete implementation of the standard that boost.thread might not be necessary). The answer to this question may make my work harder. I was asked to justifiy either TR1, some part of boost or C++11 as my preference. I opted for C++11 as the most useful. I would probably have to justify boost libraries on a case by case basis. Justifying use of C++11 actually amounts to justifying a compiler upgrade + possibly training + possibly boost.thread As threads are one of the biggest features of c++11, I may be asked to justify just boost.thread vs gcc 4.7 + boost.thread. Surprisingly another thing that is unclear is the exact set of boost libraries that were included in C++11. I don't have either the standard (other than the February draft http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf) or a good summary of the standard to hand. Suprisingly neither the boost website nor the g++ page have a list either, though the following two links are helpful: http://www.boost.org/doc/libs/1_48_0/?view=filtered_std-tr1 http://www.boost.org/doc/libs/1_48_0/?view=filtered_std-proposal I found a reference somewhere online (that I can no longer find) claiming, I believe incorrectly, that boost file_system is in C++11. This isn't mentioned on: http://www.boost.org/doc/libs/1_48_0/libs/filesystem/v3/doc/index.htm But nor its is presence in the 2005 "TR2" proposal. I worry that the 2005 TR2 proposal may be confused with any real TR2 proposal following on from C++11. I note that boost.chrono claims to be implemnting C++11 but I would have thought it was other way around and that the boost library was incorporated into the standard. http://www.boost.org/doc/libs/1_48_0/doc/html/chrono.html Anyway, the closest I've come to a list of libraries in C++11 outside of n3242 is: http://www2.research.att.com/~bs/C++0xFAQ.html#library Regards, Bruce.

3 2

Re: [boost] Is there any interest in a library which solves C++ class reflection feature just like Java does?
by Brian Wood 06 Dec '11

06 Dec '11

Matus Chochlik on Tue, Dec 6, 2011 at 2:40 AM, jinhua luo <ljh.home.king(a)gmail.com> wrote: > Hi, > Hi, >> It has some unique advantages: >> a) it doesn't require code generator > Good, but it is not so unique Because C++ compiler is a code generator? [ ...] >> d) Cross shared library boundary, you can dynamic load the shared library >> and reflect the classes within it, without need to export any symbol >> manunally in C wrapper function way > I believe (and I have some expertise in using and implementing reflection > in C++ to base that belief upon) that the basic reflection should > compile-time and any run-time reflection should be built on top > of that. Agreed. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/> (651) 251-9384

1 0

[chrono] steady_clock efficiency
by Kenneth Porter 06 Dec '11

06 Dec '11

I expect most people will use boost::chrono::steady_clock to measure performance. I've been considering switching from my raw calls to the Windows peformance counter APIs to the steady_clock. I'm a little worried about the overhead of what should be a non-intrusive facility. In examing the source, I see that steady_clock::now() reads the performance counter and then multiplies it by the reciprocal of the counter's frequency (acquired on first use of the clock) to return the time in nanoseconds. How expensive is this 64 bit multiply on a 32 bit system? How hard would it be to have now() return a time_point that stores the raw tick value and only converts it to nanoseconds when a calculation in real units is required? (Comparison to another time_point could still be done in performance counter ticks, saving the multiply.) Is it worth the extra complexity to demand-convert ticks to nanoseconds? Source is in boost_1_48_0\boost\chrono\detail\inlined\win\chrono.cpp

5 15

Status of ISO/IEC TR 24733 library idea?
by Mateusz Łoskot 06 Dec '11

06 Dec '11

Hi, There is ISO/IEC TR 24733 draft on decimal floating-point arithmetic. I found old thread by Stefan Slapeta: Decimal floating point library [1] I wonder, what is status of this idea in Boost? [1] http://lists.boost.org/Archives/boost/2006/02/101457.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

3 5

[release] Is Rlease branch is open for merge?
by Artyom Beilis 06 Dec '11

06 Dec '11

Hello, Is release brunch is open for merge of updates from trunk? Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

2 2

disable_if conundrum
by Marshall Clow 05 Dec '11

05 Dec '11

I have a function that returns a pair of iterators. There's also a version that takes a comparison predicate. template<class ForwardIterator, class Compare> std::pair<ForwardIterator, ForwardIterator> foo ( ForwardIterator first, ForwardIterator last ); template<class ForwardIterator, class Compare> std::pair<ForwardIterator, ForwardIterator> foo ( ForwardIterator first, ForwardIterator last, Compare comp ); I want to provide a range-based version of it. template<class Range> std::pair<typename boost::range_iterator<const Range>::type, typename boost::range_iterator<const Range>::type> foo ( const Range &r ); template<class Range, class Compare> std::pair<typename boost::range_iterator<const Range>::type, typename boost::range_iterator<const Range>::type> foo ( const Range &r, Compare comp ); Ok. There's a problem. If I call: foo ( first, last ) I get an error, because there are two perfectly good two argument candidates. Fine. Been there, seen that. I can use disable_if to make sure that the second range based version is only "active" when the arguments are different types. It's verbose, but it (usually) works template<class Range, class Compare> typename boost::disable_if_c<boost::is_same<Range, Compare>::value, std::pair<typename boost::range_iterator<const Range>::type, typename boost::range_iterator<const Range>::type> >::type foo ( const Range &r, Compare comp ); But this time it does not! I get a compile error telling me that the compiler can't deal with boost::range_iterator<XXX>::type, when XXX = some random iterator. It seems that the compiler wants to evaluate all the parameters of disable_if_c before deciding whether or not to SFINAE it (I guess that's not unreasonable, but it's not what I want) Apparently, all the other times that I did this, the return type of the function was not a dependent type of the template arguments. Any suggestions for a workaround here? -- Marshall -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

4 9

[enable_if] compile failure in trunk
by Tim Blechmann 05 Dec '11

05 Dec '11

trying to merge boost.heap into trunk, there is one issue, which seems to be triggered by the enable_if in the boost.heap testsuite. compiling with gcc (4.5 or 4.6), i get the following error: In file included from /home/tim/workspace/boost-trunk/boost/parameter.hpp:17:0, from /home/tim/workspace/boost-trunk/boost/heap/policies.hpp:12, from /home/tim/workspace/boost-trunk/boost/heap/detail/stable_heap.hpp:20, from /home/tim/workspace/boost_heap/libs/heap/test/../../../boost/heap/fibonacci_heap.hpp:20, from /home/tim/workspace/boost_heap/libs/heap/test/fibonacci_heap_test.cpp:8: /home/tim/workspace/boost-trunk/boost/parameter/name.hpp:52:1: error: template argument 2 is invalid In file included from /home/tim/workspace/boost-trunk/boost/fusion/support/detail/segmented_fold_until_impl.hpp:20:0, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin_impl.hpp:15, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/begin.hpp:17, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector10.hpp:15, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector_fwd.hpp:14, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/tuple/tuple.hpp:11, from /home/tim/workspace/boost-trunk/boost/fusion/tuple.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/include/tuple.hpp:10, from /home/tim/workspace/boost-trunk/boost/math/tools/tuple.hpp:89, from /home/tim/workspace/boost-trunk/boost/math/special_functions/detail/igamma_inverse.hpp:13, from /home/tim/workspace/boost-trunk/boost/math/special_functions/gamma.hpp:1543, from /home/tim/workspace/boost-trunk/boost/math/special_functions/detail/bessel_jy.hpp:14, from /home/tim/workspace/boost-trunk/boost/math/special_functions/bessel.hpp:17, from /home/tim/workspace/boost-trunk/boost/math/special_functions.hpp:18, from /home/tim/workspace/boost-trunk/boost/random/generate_canonical.hpp:22, from /home/tim/workspace/boost-trunk/boost/random.hpp:52, from /home/tim/workspace/boost_heap/libs/heap/test/mutable_heap_tests.hpp:1, from /home/tim/workspace/boost_heap/libs/heap/test/fibonacci_heap_test.cpp:12: /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:77:9: error: expected nested-name-specifier before ‘enable_if’ /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:77:18: error: expected initializer before ‘<’ token /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:88:9: error: expected nested-name-specifier before ‘enable_if’ /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:88:18: error: expected initializer before ‘<’ token /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:98:31: error: ‘boost::fusion::iterator_operators::operator==’ has not been declared /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:99:31: error: ‘boost::fusion::iterator_operators::operator!=’ has not been declared In file included from /home/tim/workspace/boost-trunk/boost/fusion/iterator/segmented_iterator.hpp:13:0, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin.hpp:11, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/begin.hpp:17, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector10.hpp:15, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector_fwd.hpp:14, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/tuple/tuple.hpp:11, from /home/tim/workspace/boost-trunk/boost/fusion/tuple.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/include/tuple.hpp:10, from /home/tim/workspace/boost-trunk/boost/math/tools/tuple.hpp:89, from /home/tim/workspace/boost-trunk/boost/math/special_functions/detail/igamma_inverse.hpp:13, from /home/tim/workspace/boost-trunk/boost/math/special_functions/gamma.hpp:1543, from /home/tim/workspace/boost-trunk/boost/math/special_functions/detail/bessel_jy.hpp:14, from /home/tim/workspace/boost-trunk/boost/math/special_functions/bessel.hpp:17, from /home/tim/workspace/boost-trunk/boost/math/special_functions.hpp:18, from /home/tim/workspace/boost-trunk/boost/random/generate_canonical.hpp:22, from /home/tim/workspace/boost-trunk/boost/random.hpp:52, from /home/tim/workspace/boost_heap/libs/heap/test/mutable_heap_tests.hpp:1, from /home/tim/workspace/boost_heap/libs/heap/test/fibonacci_heap_test.cpp:12: /home/tim/workspace/boost-trunk/boost/fusion/container/list/cons.hpp:91:22: error: expected nested-name-specifier before ‘disable_if’ /home/tim/workspace/boost-trunk/boost/fusion/container/list/cons.hpp:91:32: error: expected ‘,’ or ‘...’ before ‘<’ token /home/tim/workspace/boost-trunk/boost/fusion/container/list/cons.hpp:122:18: error: expected nested-name-specifier before ‘disable_if’ /home/tim/workspace/boost-trunk/boost/fusion/container/list/cons.hpp:122:28: error: expected initializer before ‘<’ token compiling with gcc against 1.48 works fine. clang++ correctly compiles this code against boost-trunk. any idea, what could go wrong there? thanks, tim

2 2

[units] - learning to use
by Janek Kozicki 05 Dec '11

05 Dec '11

Hi, I wrote a short function that integrates Huyghens spherical wave for diffraction. (This is a single slit experiment btw). I have some questions, marked with (*) double integral( const quantity<length> x // x - position where light intensity is calculated , const quantity<length> R // R - distance from slit to screen , const quantity<length> D // D - slit width , const quantity<length> lambda // lambda - wavelength , double steps // steps - number of integration steps // (*) ) { complex<double> i(0,1); complex<double> a(0); static const double pi = 3.14159265358979323846; // (**) quantity<wavenumber,complex<double> > k=2*pi/lambda; quantity<length> d=-0.5*D; // d - position on the slit quantity<length> dd=D/steps; // dd - width of integral step // integrate from -d to d: exp(i*k*r)/r for( ; d<= 0.5*D ; d+=dd ) { quantity<length> r=sqrt(pow<2>(R)+pow<2>(x-d)); a += (dd*exp(i*k*r)/r).value(); // (***) } return pow<2>(abs(a)); } (*) it should be `int steps` but if I write it this way I get a compilation error here: quantity<length> dd=D/steps; // dd - width of integral step That looks like a conversion problem. (**) why do I need to define pi ? I expected to find it somewhere, but I couldn't. (***) it seems strange that I need to take .value() here. The result is dimensionless, why can't it directly convert to complex<double> ? There is a risk that .value() would be expressed in millimeters or angstroms or whatever (maybe depending on dd), and then .value() would return a wrongly scaled number? Another question, why this works: quantity<length> wavelength ( 632.8 *nano*meters); and this does not? quantity<length> wavelength = 632.8 *nano*meters; Of course I know about extra copying, and waste of CPU resources on execution, when compiler isn't able to optimize this away (and usually it is able to do that). But why the heck this simple assignment can't work? PS: I am attaching a short test version of this program, it's in polish, but I hope you don't mind. best regards and thanks in advance for your help -- Janek Kozicki http://janek.kozicki.pl/ |

5 22

New Container: Hashed Vector
by Sam Hertz 05 Dec '11

05 Dec '11

Boost Developers, Let me start by saying that I love the Boost Libraries. I use them frequently. Most of the time, when I need some unique data structure in my code, Boost can solve my problems. I saw the recent release of the Container library and I love the idea of the flat_set/map structures. In my code, I require a data structure that has fast associative lookup (like an unordered_set). However, this data structure should preserve the order of element insertion. In other words, the data structure would be similar to the flat_set/map structures, but would preserve order of insertion instead of relying on the < operator or a Comparable function object. Right now, I am calling this structure a hashed_vector. I am aware of Boost.Multi-Index, but this library is very general purpose and cumbersome to use to implement a hashed_vector. Ideally the structure would have an identical interface to the std::vector class, but with a much speedier find member function. Right now I am creating a wrapper class for multi_index_container to implement the hashed_vector, but hopefully a more direct implementation could be added to the Boost Libraries. I am sharing this idea with all of you because I want to see if you think such a structure is worth including in the libraries and if anyone is interested in implementing it. I would love to implement it myself, but I am currently a full-time graduate student and my experience with template programming is laughable when considering the amount currently used in the Boost Libraries. Looking forward to your feedback! Sam

2 1

[smart-ptr][containers] type of the operator[] index
by Vicente J. Botet Escriba 05 Dec '11

05 Dec '11

Hi, which is the correct type used as index of operator[]. scoped_array uses std::ptrdiff_t. Others containers use std::size_t. The standard uses also std::size_t, but in 13.6 Built-in operators 13 For every cv-qualified or cv-unqualified object type T there exist candidate operator functions of the form T* operator+(T*, std::ptrdiff_t); T& operator[](T*, std::ptrdiff_t); T* operator-(T*, std::ptrdiff_t); T* operator+(std::ptrdiff_t, T*); T& operator[](std::ptrdiff_t, T*); we see again std::ptrdiff_t. When using an index to move from a scoped_array to another container which should be the type if the index? Best, Vicente

6 19

[thread][general] Using and building the library
by Vicente J. Botet Escriba 04 Dec '11

04 Dec '11

Hi, there is a ticket for the Boost.Thread #4921 BOOST_THREAD_USE_DLL and BOOST_THREAD_USE_LIB are crucial and need to be documented (https://svn.boost.org/trac/boost/ticket/4921) related to the documentation of how the library can be used and build. Boost.Config provides some tools that the library authors can adopt, but is there a documented way to do it? If yet could you point it Here it is what could be added to for Boost.Thread Using and building the library Boost.Thread is configured following the conventions used to build libraries with separate source code (http://www.boost.org/doc/libs/1_48_0/libs/config/doc/html/boost_config/boos…) Boost.Thread will import/export the code only if the user has specifically asked for it, by defining either BOOST_ALL_DYN_LINK if they want all boost libraries to be dynamically linked, or BOOST_THREAD_DYN_LINK if they want just this one to be dynamically liked. The source code compiled when building the library defines a macros BOOST_THREAD_SOURCE that is used to import or export it. The user must not define this macro in any case. Best, Vicente

1 0

[parameter] Boost.Graph program not responding at run-time
by Lorenzo Caminiti 03 Dec '11

03 Dec '11

Hello all, If I move the call to boost::depth_first_search into a template depth_first_search_impl and out of the Boost.Parameter function body, the code compiles (both MSVC and GCC with latest Boost from trunk) but the executable runs forever and prints nothing to cout... What am I doing wrong? #include <boost/parameter.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/depth_first_search.hpp> #include <boost/graph/graph_traits.hpp> #include <boost/range/irange.hpp> #include <boost/pending/indirect_cmp.hpp> #include <boost/type_traits/is_convertible.hpp> #include <boost/type_traits/is_integral.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/mpl/and.hpp> #include <boost/mpl/placeholders.hpp> #include <iostream> namespace graphs { template< typename G > struct vertex_descriptor { typedef typename boost::graph_traits<G>::vertex_descriptor type; }; template< typename T > struct is_incidence_and_vertex_list_graph : boost::mpl::and_< boost::is_convertible< typename boost::graph_traits<T>::traversal_category , boost::incidence_graph_tag > , boost::is_convertible< typename boost::graph_traits<T>::traversal_category , boost::vertex_list_graph_tag > > {}; template< typename T, typename Key > struct is_property_map_of_key : boost::is_same<Key, typename boost::property_traits<T>::key_type> {}; template< typename T, typename Key > struct is_integral_property_map_of_key { typedef typename boost::mpl::and_< boost::is_integral<typename boost::property_traits<T>::value_type> , is_property_map_of_key<T, typename Key::type> >::type type; static const bool value = type::value; }; template< typename Size, typename IndexMap > boost::iterator_property_map<boost::default_color_type*, IndexMap, boost::default_color_type, boost::default_color_type&> default_color_map ( Size const& num_vertices, IndexMap const& index_map ) { std::vector<boost::default_color_type> colors(num_vertices); return &colors[0]; } template< typename graph_type, typename visitor_type, typename root_vertex_type, typename index_map_type, typename color_map_type > void depth_first_search_impl ( graph_type graph, visitor_type visitor, root_vertex_type root_vertex, index_map_type index_map, color_map_type color_map ) { boost::depth_first_search(graph, boost::visitor(visitor). color_map(color_map).root_vertex(root_vertex). vertex_index_map(index_map)); } BOOST_PARAMETER_NAME(graph) BOOST_PARAMETER_NAME(visitor) BOOST_PARAMETER_NAME(root_vertex) BOOST_PARAMETER_NAME(index_map) BOOST_PARAMETER_NAME(color_map) BOOST_PARAMETER_FUNCTION( (void), depth_first_search, tag, (required (graph, *(is_incidence_and_vertex_list_graph<boost::mpl::_>)) ) (optional (visitor, *, boost::dfs_visitor<>()) (root_vertex, (vertex_descriptor<tag::graph::_>), *boost::vertices(graph).first) (index_map, *(is_integral_property_map_of_key< boost::mpl::_, vertex_descriptor<tag::graph::_> >), boost::get(boost::vertex_index, graph)) (in_out(color_map), *(is_property_map_of_key< boost::mpl::_, vertex_descriptor<tag::graph::_> >), default_color_map(boost::num_vertices(graph), index_map)) ) ) { return depth_first_search_impl<graph_type, visitor_type, root_vertex_type, index_map_type, color_map_type>(graph, visitor, root_vertex, index_map, color_map); } } // namespace graphs template< typename TimeMap > struct dfs_time_visitor : public boost::default_dfs_visitor { typedef typename boost::property_traits<TimeMap>::value_type T; dfs_time_visitor ( TimeMap dmap, TimeMap fmap, T& t ) : dmap_(dmap), fmap_(fmap), time_(t) {} template< typename V, typename G > void discover_vertex ( V u, G const& g ) const { put(dmap_, u, time_++); } template< typename V, typename G > void finish_vertex ( V u, G const& g ) const { put(fmap_, u, time_++); } private: TimeMap dmap_; TimeMap fmap_; T& time_; }; int main ( void ) { typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS> G; typedef boost::graph_traits<G>::vertices_size_type size_type; enum {u, v, w, x, y, z, N}; char names[] = {'u', 'v', 'w', 'x', 'y', 'z'}; typedef std::pair<int, int> E; E edges[] = {E(u, v), E(u, x), E(x, v), E(y, x), E(v, y), E(w, y), E(w, z), E(z, z)}; G g(edges, edges + sizeof(edges) / sizeof(E), N); std::vector<size_type> dtime(boost::num_vertices(g)); std::vector<size_type> ftime(boost::num_vertices(g)); size_type t = 0; dfs_time_visitor<size_type*> vis(&dtime[0], &ftime[0], t); graphs::depth_first_search(g, vis); std::vector<size_type> dorder(N); boost::integer_range<size_type> r(0, N); std::copy(r.begin(), r.end(), dorder.begin()); std::sort(dorder.begin(), dorder.end(), boost::indirect_cmp<size_type*, std::less<size_type> >(&dtime[0])); std::cout << "order of discovery: "; for(int i = 0; i < N; ++i) std::cout << names[dorder[i]] << " "; std::cout << std::endl; std::vector<size_type> forder(N); std::copy(r.begin(), r.end(), forder.begin()); std::sort(forder.begin(), forder.end(), boost::indirect_cmp<size_type*, std::less<size_type> >(&ftime[0])); std::cout << "order of finish: "; for(int i = 0; i < N; ++i) std::cout << names[forder[i]] << " "; std::cout << std::endl; return 0; } Thanks. --Lorenzo

2 6

Phoenix documentation problems
by Dave Abrahams 03 Dec '11

03 Dec '11

A few things I just noticed: 1. http://www.boost.org/doc/libs/release/libs/phoenix/doc/html/phoenix/what_s_… says: "Bind is no completely compatible with Boost.Bind" There's a letter missing after "no," the choice of which ("w" or "t") can invert the meaning of the sentence! It wasn't until I got to http://www.boost.org/doc/libs/release/libs/phoenix/doc/html/phoenix/modules… that I realized it was "w"! 2. On the same page I think there's a messed up cross-reference, because "phoenix.modules.function phoenix::function" Doesn't make a whole lot of sense. 3. On libs/phoenix/doc/html/phoenix/starter_kit/values.html I see: Confused? val(3) is a unary function, you say? Yes it is. No, it isn't. val is a unary function. val(3) *invokes* a unary function. 4. libs/phoenix/doc/html/phoenix/starter_kit/lazy_operators.html says that x[ref(i)] is an error but it gives only a confusing partial explanation that doesn't seem to follow the rules above it. operator[] looks as much like a binary operation as operator*; the difference is that the former must be a member. 5. Can we please, finally, *deprecate* Boost.Lambda and put a sign on its docs directing people to look at Phoenix? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

4 3

[1.49.0] New libraries?
by Beman Dawes 03 Dec '11

03 Dec '11

What new libraries are ready for 1.49.0? What is that state of any new libraries that want to go in 1.49.0? Are they in trunk and do the developers think they are ready to be merged into release? The release managers would like to have a four week beta period of 1.49.0. That means we have to get going on new libraries right way if we are going meet our early February release schedule. --The release team

6 12

[thread] patch to allow custom stack size.
by Brett Lentz 03 Dec '11

03 Dec '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patch and (very) rudimentary usage example is attached. A couple months ago, I sent mail to the list looking to see if there's interest in getting some patches merged from Phusion Passenger. (See: http://marc.info/?t=131722868200003&r=1&w=2 ) So, here's the first patch I'd like to try to get committed. On pthread-based systems, it allows for the user to request a custom stack size. This is useful in Passenger's case where they want to reduce the VM size without requiring the user to hassle with ulimit settings. Passenger spawns many threads rather than using a thread pool for performance reasons. As a result of this design decision, they also need the ability to tune the stack size. Ticket #5956 already exists for this patch. I've verified that the patch works against the current (1.49) codebase out of SVN. What next steps need to be taken before this is committed? - -- - ---Brett. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO1lZEAAoJEEAzW/nB31+3fx4H/iulwAM7vGlZW56xsuezTXPC 6SSuYzUlkyVeCngpireVyD0+Um/ACFBM8FSf76cRnewX5449T01IycmX3fUe+z7g DjjUCQAHJ/9pdfrqEHz0d7wZcZbeBHUm2zggdDGcn703JQSagg2Q5d5mz48RU8/J ixTe/oAOAaXk5TQo/92fHrAmtpwfQON4tPsS7Om0kJ5vcv3PbIqQ0Q4eBKRJCVHI /CFfc3xXwSaR1xUkwhPHtjydlIWAMo0+bdKgJE5HGnn6fQSU5jlZ+ihDyajOmM88 ueaIcWi7pa3OZwLzrUNG0xIH4m7wtk0ga8edym4+ZvuovUi4vYRA1k4dIzBOtvg= =0dQJ -----END PGP SIGNATURE-----

6 14

[thread] [rfc] patch to change condition_variable and mutex error checks
by Brett Lentz 02 Dec '11

02 Dec '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patch is attached. I'd like to get some comments about this patch. Does it seem reasonable enough to accept? Is there a better way to handle it? BOOST_VERIFY aborts on EINTR, but EINTR is usually not fatal, it just means you need to try later. So, the attached patch makes it so that the condition_variable and mutex error checks retry on EINTR, but will still fail on any other error. This issue was uncovered on one of Phusion Passenger's customers' production systems. - -- - ---Brett. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO1pVQAAoJEEAzW/nB31+3CgMIAMPYRMvuuYWdHbmWF7qWt13i pKRLGDjT5fT75SzVdcmwFNJLlboaP5tNi8g89Kw+iS+jjghEbyZr2Zx6BdCL67ne +XtA1DqlmNHD3GZiLMlQDdPqbV7qliqj4d7+8xXqXnivxULYPwQMzW1XXY8Cs4Ys uHBK/NrvZM+/LL2umHSCOLbKz7AEli6tSzuUyw557ubp42UPnE+gc+mUb7QYmcgW BKzizZ03s+V4qJA/B+N4Ux8RvvhWgNLXnYoC958mzvnTwaTbdGfEmzVkKaWucI50 jsEzfejn/Gru2BNeC2MwVmecxmkHugoXxvVUYIH4PaDET96BM3ihHWV+4SLg7ik= =xkyz -----END PGP SIGNATURE-----

3 6

[serialization] duplicate symbols when trying to BOOST_CLASS_EXPORT
by V D 02 Dec '11

02 Dec '11

Hi, I'm using boost serialization to serialize a bunch of classes, sometimes I need to serialize via a base pointer to a derived class. Let's consider the very simple case where we have a class B deriving from class A. /*** a.h ***/ #ifndef __A__H #define __A__H #include <iostream> class A { private: virtual void make_polymorphic() = 0; friend class boost::serialization::access; template <typename Archive> void serialize(Archive& ar, const unsigned int version) { std::cout << "A!\n"; } }; #endif /*** b.h ***/ #ifndef __B__H #define __B__H #include <boost/serialization/base_object.hpp> #include <boost/serialization/export.hpp> #include "a.h" class B : public A { private: friend class boost::serialization::access; template <typename Archive> void serialize(Archive& ar, const unsigned int version) { ar & boost::serialization::base_object<A>(*this); std::cout << "B!\n"; } virtual void make_polymorphic() {} }; BOOST_CLASS_EXPORT(B); #endif I'm using the BOOST_CLASS_EXPORT so that it registers a GUID for class B, so that serialization of a base pointer to a derived class works. This works fine. My problem is that, if I have 2 files that include b.h, I will get duplicate symbols for B's guid. For example, suppose we add b.cpp with an empty default constructor, just so that we compile another file. #include "b.h" B::B() { } Let's use the following main: // main.cpp #include <iostream> #include <fstream> #include <boost/archive/binary_oarchive.hpp> #include "b.h" int main() { std::ofstream of("mybin.bin"); boost::archive::binary_oarchive oa(of); A* b = new B(); oa << b; return 0; } Which I compile with g++ main.cpp b.cpp -lboost_system -lboost_serialization -o main I get, ld: duplicate symbol boost::archive::detail::extra_detail::init_guid<B>::g If I don't have 2 files, then of course I don't have duplicate symbols and the serialization of the polymorphic object works fine. Any idea how to resolve this issue? Thank you -V

2 2

Boost.Log plan
by Leon 02 Dec '11

02 Dec '11

Hi, What's the current plan for Boost.Log? Will it be part of 1.49.0? Bests, Leon

2 1

Local and Phoenix idiosyncrasy
by Thomas Heller 02 Dec '11

02 Dec '11

Hi list, Can we please put an end to this insane idiosyncrasy going on here lately? It doesn't lead to anywhere! Ok, we get it ... people want to write local functions in the usual way. Here is what I have to propose: Why not combine Boost.Local and Boost.Phoenix and keep everybody happy? If the macros provided by Boost.Local would emit some instance of a phoenix::function. It would be great if this could be done completely polymorphic, maybe some tricks with boost::any? That way we gain these advantages: 1) We can get rid of the need to capture variables in scope by the macro. 2) People who don't want to put their functions in global/namespace/class scope and are afraid of writing a phoenix expression don't have to 3) The resulting lazy function will be composable in the usual phoenix way and will be far more useful! 4) We can put an end to this useless Phoenix vs. Local discussion In peace, Thomas

7 12

Boost.Thread and Boost.Move collision
by Ion Gaztañaga 01 Dec '11

01 Dec '11

Hi, I've recently received some bugs caused by name collision between Boost.Move and Boost.Thread. Like many other libraries, Boost.Thread has its own move emulation code, and those functions are in the top-level namespace. I guess there is no trivial solution for this. Options: 1) Move Boost.Move elements to boost::move:: namespace 2) Move Boost.Thread elements to boost::thread namespace 3) Modify Boost.Thread to make use of Boost.Move I would like to know your opinion on this as this issue is related to two official Boost libraries. Best, Ion

8 8

Re: [boost] New libraries implementing C++11 features in C++03
by Brent Spillner 01 Dec '11

01 Dec '11

On 23 Nov 2011 10:21:50 Joel de Guzman wrote: >a good approximation of lambda is already existing in Boost. Namely: bind, >lambda and phoenix. I posted a Spirit example of lambda in action using >Phoenix: > >http://tinyurl.com/7w2h2r9 > >Try as hard as you can, but you cannot ever come close to the clarity of >he syntax presented there. Proponents of locals have cited error-messages >generated by the compiler as a justification for Locals. Locals is probably >a good workaround. But hear me out... First of all, this "trivial" example didn't even compile on the first machine I tried it on, which had Boost 1.45 (which doesn't expose qi:_val_type or qi:_1_type). This is a pretty good reminder of the fact that Phoenix remains a fast moving target (1.45 is less than a year old) and still appears unnecessarily baroque to new users (why are typenames that need to be cited in even a basic tutorial prefixed with an underscore?) Local/Closure, on the other hand, seems to have a pretty stable interface at this point. On a machine with 1.48, the example compiles just fine. If you were to pass std::string::iterators instead of const_iterators to phrase_parse(), though ( a pretty common class of mistake in the real world), you get this error message (GCC 4.4.4): /usr/include/boost/spirit/home/qi/reference.hpp: In member function 'bool boost::spirit::qi::reference<Subject>::parse(Iterator&, const Iterator&, Context&, const Skipper&, Attribute&) const [with Iterator = __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, Context = boost::spirit::context<boost::fusion::cons<int&, boost::fusion::nil>, boost::spirit::locals<mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na> >, Skipper = boost::spirit::qi::phrase_parse(Iterator&, Iterator, const Expr&, const Skipper&, boost::spirit::qi::skip_flag::enum_type, Attr&) [with Iterator = __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, Expr = client::calculator<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, Skipper = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, Attr = int]::skipper_type, Attribute = int, Subject = const boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>]': /usr/include/boost/spirit/home/qi/parse.hpp:164: instantiated from 'bool boost::spirit::qi::phrase_parse(Iterator&, Iterator, const Expr&, const Skipper&, boost::spirit::qi::skip_flag::enum_type, Attr&) [with Iterator = __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, Expr = client::calculator<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, Skipper = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, Attr = int]' /usr/include/boost/spirit/home/qi/parse.hpp:197: instantiated from 'bool boost::spirit::qi::phrase_parse(Iterator&, Iterator, const Expr&, const Skipper&, Attr&) [with Iterator = __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, Expr = main()::calculator, Skipper = boost::spirit::ascii::space_type, Attr = int]' calc3.cpp:101: instantiated from here /usr/include/boost/spirit/home/qi/reference.hpp:43: error: no matching function for call to 'boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>::parse(__gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&, const __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&, boost::spirit::context<boost::fusion::cons<int&, boost::fusion::nil>, boost::spirit::locals<mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na> >&, const boost::spirit::qi::char_class<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >&, int&) const' But that's nothing; if you omit the '>>' from the expression or term definition you get the 33 kilochar beauty copied at the bottom of this email. There have been several postings to this list in the past about trivial errors (substituting the wrong type or omitting a forward declaration and so forth) that generate hundreds of kilobytes of compiler barf with no apparent relation to what is actually wrong with the source. Yes, the compiler is also largely to blame (although GCC does not seem any worse here than the other mainstream options) and perhaps someday this will finally get better, but I think you grossly underestimate the deterrent effect this has on new users and on wider adoption of Phoenix and similar libraries. Phoenix is great when you really need it, but there's also quite a lot to be said for alternatives (including Boost.Local) that don't build massive, fragile scaffolds of parametric types and in some sense keep what the compiler 'sees' on a given line of source similar to what the programmer sees in a text editor. Don't get me wrong; I think Phoenix is an amazing piece of work, and for someone who needs late binding and lazy evaluation in an expression (or a small DSEL without depending on an external parser generator) it's a godsend. I just happen to believe that you could say the same things about Boost.Local--- if this is what you need, it's *exactly* what you need. Many Boost users may never need local functions, but you could again say the same thing about the vast majority of the 113 official components of 1.48. If you want to keep Boost limited to the bare essentials, it's already far too late. The bar for entry should be that the library is well designed, well documented, well implemented, serves a need that a nontrivial number of users have, and isn't likely to interfere with the implementation of other future language or Boost features, not that it will be used just as frequently as enable_if<> or optional<>. >Keep in mind that Boost has been at the forefront of C++ library development. >It is because of these libraries that push the limits of C++ that we see the >advancement in C++ that we enjoy now in C++11. Case in point is Boost Lambda Hey, that's great. I just think that we all need to recognize that very little C++ software is written with "push the limits of the language" as one of the goals in mind. The participants on this particular list have self-selected for interest in developing state-of-the-art libraries, but most also have day jobs where they're just trying to maintain an existing codebase with minimal hassle for their colleagues and customers, as well as side projects where getting something running quickly and correctly is more important (if not always more interesting) than figuring out just how far we can push overload resolution rules. And probably 99% of Boost users and 99.9% of potential Boost users aren't the kind of programmers on this list and have no interest at all in "pushing the envelope"--- they just want tools with simple, stable syntax and easy debugging, both of which Local offers. Furthermore, no matter how slick your personal environment is, it's a simple fact that there are thousands and thousands of important projects that will never have the benefit of a C++11 compiler for a variety of reasons. I *really* don't understand the criticism from several people about using macros to implement the library. Part of the power of C++ is that its syntax is extensible, and the preprocessor and operator overloading are the two mechanisms that enable that. The preprocessor is part of the language specification, arguably even more so than the standard library since a (nonconforming) implementation that ships with only 10% of the standard library implemented is far more useful in practice than an implementation that ships with only 10% of the preprocessor implemented. Yes, macros can be abused, as can operator overloading (as many would criticize Phoenix), but often they're the most appropriate choice. There should be only two questions here: are there a nontrivial number of users who desire or would benefit from local functions, and is there a better way to provide them than what Lorenzo has chosen? ------------------- Horrific error messages follow --------------------- /usr/include/boost/spirit/home/qi/nonterminal/rule.hpp: In static member function 'static void boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>::define(boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>&, const Expr&, mpl_::false_) [with Auto = mpl_::bool_<false>, Expr = boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::plus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::minus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, T1 = int(), T2 = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, T3 = boost::spirit::unused_type, T4 = boost::spirit::unused_type]': /usr/include/boost/spirit/home/qi/nonterminal/rule.hpp:220: instantiated from 'boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>& boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>::operator=(const Expr&) [with Expr = boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::plus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::minus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, T1 = int(), T2 = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, T3 = boost::spirit::unused_type, T4 = boost::spirit::unused_type]' calc3.cpp:49: instantiated from 'client::calculator<Iterator>::calculator() [with Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]' calc3.cpp:90: instantiated from here /usr/include/boost/spirit/home/qi/nonterminal/rule.hpp:176: error: no matching function for call to 'assertion_failed(mpl_::failed************ (boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>::define(boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>&, const Expr&, mpl_::false_) [with Auto = mpl_::bool_<false>, Expr = boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::plus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::minus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, T1 = int(), T2 = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, T3 = boost::spirit::unused_type, T4 = boost::spirit::unused_type]::error_invalid_expression::************)(boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::plus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::minus_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>))' /usr/include/boost/spirit/home/qi/nonterminal/rule.hpp: In static member function 'static void boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>::define(boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>&, const Expr&, mpl_::false_) [with Auto = mpl_::bool_<false>, Expr = boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::multiplies_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::divides_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, T1 = int(), T2 = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, T3 = boost::spirit::unused_type, T4 = boost::spirit::unused_type]': /usr/include/boost/spirit/home/qi/nonterminal/rule.hpp:220: instantiated from 'boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>& boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>::operator=(const Expr&) [with Expr = boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::multiplies_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::divides_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, T1 = int(), T2 = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, T3 = boost::spirit::unused_type, T4 = boost::spirit::unused_type]' calc3.cpp:56: instantiated from 'client::calculator<Iterator>::calculator() [with Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]' calc3.cpp:90: instantiated from here /usr/include/boost/spirit/home/qi/nonterminal/rule.hpp:176: error: no matching function for call to 'assertion_failed(mpl_::failed************ (boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>::define(boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>&, const Expr&, mpl_::false_) [with Auto = mpl_::bool_<false>, Expr = boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::multiplies_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::divides_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, T1 = int(), T2 = boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, T3 = boost::spirit::unused_type, T4 = boost::spirit::unused_type]::error_invalid_expression::************)(boost::proto::exprns_::expr<boost::proto::tagns_::tag::multiplies, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::multiplies_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char&>, 0l>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, int(), boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space, boost::spirit::char_encoding::ascii> >, 0l>, boost::spirit::unused_type, boost::spirit::unused_type>&, boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::divides_assign_eval, boost::fusion::vector<boost::spirit::attribute<0>, boost::spirit::argument<0>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >&>, 0l> >, 2l>&>, 2l>&>, 2l>&>, 2l>))'

18 82

error LNK2019: unresolved external symbol "public: void __thiscall BaseState::serialize<class boost::archive::xml_oarchive>
by Farren, Patrick 01 Dec '11

01 Dec '11

Hi I'm using VS2008 and boost 1.45 I have a static library that serializes to an xml file. I have a test app that calls a method within this static library to create the XML file. The following linker problem occurs and I cannot resolve it. Can anyone assist? Error 1 error LNK2019: unresolved external symbol "public: void __thiscall BaseState::serialize<class boost::archive::xml_oarchive>(class boost::archive::xml_oarchive &,unsigned int)" (??$serialize@Vxml_oarchive@archive@boost@@@BaseState@@QAEXAAVxml_oarchive@archive@boost@@I@Z) referenced in function "public: static void __cdecl boost::serialization::access::serialize<class boost::archive::xml_oarchive,class BaseState>(class boost::archive::xml_oarchive &,class BaseState &,unsigned int)" (??$serialize@Vxml_oarchive@archive@boost@@VBaseState@@@access@serialization@boost@@SAXAAVxml_oarchive@archive@2@AAVBaseState@@I@Z) dataAPIcpp.lib TestAPI Patrick.

1 0

[predef] RFC: Predefined version numbers library..
by Rene Rivera 01 Dec '11

01 Dec '11

Long ago, yes, years ago, I proposed normalizing the variety of ways of defining (in the preprocessor) version numbers and reflecting the predefined version information. As can be seen here <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig>. Time traveling to the present I have finally put the finishing touches on the end result of this concept as a "Predef" library. It's now grown to include detection of more types of predefs, almost complete documentation with a reference generated directly from the source, and some utilities on adding new predefs. I'm still working on cross-platform testing. But I thought now would be a good time to ask for comments and for people to try it out. The lib is in the sandbox at <http://svn.boost.org/svn/boost/sandbox/predef>. And the docs can be rad directly from <http://svn.boost.org/svn/boost/sandbox/predef/libs/predef/doc/html/index.ht…>. Enjoy. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

Interest in hardware abstraction layer library
by Szymon Gutaj 01 Dec '11

01 Dec '11

Hi Everyone, please share your comments/interest in a library that would ease writing hardware abstraction layers (HAL's) for complex devices (like large ASIC/FPGA). Here's the description: 1. Let's assume that we've got a memory mapped IO device, controlled via its registers. Each register is divided into few bitfields. Each bitfield controls separate functionality and has its properties, like: read/write/special access, numeral/enumerated value type, value signedness, valid value range(s) etc. All these are typically listed in device's specification: +----------------+--------------+ |Register offset |Register name | +----------------+--------------+ |0x12FE |CONTROL_REG1 | +----------------+--------------+ +--------------+--------------+-------+-----------+------------+ |Bits occupied |Bitfield name |Access |Signedness |Value range | +--------------+--------------+-------+-----------+------------+ |31:25 |TEMPERATURE |RA |SIGNED |- | +--------------+--------------+-------+-----------+------------+ |24:1 |FAN_RPM |WA |UNSIGNED |0:6000 | +--------------+--------------+-------+-----------+------------+ |0:0 |ENABLE |RWA |UNSIGNED |0:1 | +--------------+--------------+-------+-----------+------------+ Note: RA: Read Access, WA: Write Access, RWA: Read/Write Access 2. Let's assume that there's a whole family of these ASICs (subsequent generations/revisions). Each new revision differs from previous one only in few details. The point is that we may have few thousand bitfields per ASIC plus revision changes. Coding such amount of information "by hand" is obviously error-prone. Using text processing (perl/python) to translate the specification to code may obfuscate it's nice tabular format (and may miss features/optimisation offered by metaprogramming). 3. Our goal is to create an abstract interface (HAL). Its implementations would "talk to" corresponding bitfields via inner (intermediate) interface. The purpose of that intermediate code would be to: - present bitfield's name exactly "as is in specification", - extract bitfield's value from its register in a typed, endiannes-correct manner, - enforce correct usage (like forbidding writing read-only fields), - provide value validation, - provide value conversion (enumeration-to-numeral etc.), - provide array-style access if needed, - provide debugging features, - and few more cherries on top. The key point is to have most of this code generated from the specification using only simple regexp (to the form required by proposed library). 4. Code snippet (using specification from point 1) - simple and simplified: Let's create an interface with one member function "operate". Implementation of this function will "talk to" bitfields of CONTROL_REG1 through get<BITFIELD> and set<BITFIELD> functions. These functions (and few other utilities) are being generated by the proposed library, using provided metadata. // Definition of HAL interface --------------------------- namespace some_subsystem { namespace driver { class some_controller { public: virtual bool operate() = 0; }; }} // Definition of bitfields (metadata) -------------------- // Concrete device definition enclosed in a dedicated namespace namespace some_subsystem { namespace driver { namespace asic_ver_123 { // Legend: // BOOST_HAL_DEF_REGISTER_BEG(REGISTER_OFFSET, REGISTER_NAME) // BOOST_HAL_DEF_FIELD(MSBIT, LSBIT, BITFIELD_NAME, ACCESS, SIGNEDNESS, VALIDATOR) // BOOST_HAL_DEF_REGISTER_END() BOOST_HAL_DEF_REGISTER_BEG(0x12FE, CONTROL_REG1) // Register definition BOOST_HAL_DEF_FIELD(30, 25, TEMPERATURE, RA, SIGNED, CTP_ESC(no_check)) // CTP_ESC meant for commas escaping BOOST_HAL_DEF_FIELD(24, 1, FAN_RPM, WA, UNSIGNED, CTP_ESC(range<0, 6000>)) BOOST_HAL_DEF_FIELD(0, 0, ENABLE, WA, UNSIGNED, CTP_ESC(range<0, 1>)) BOOST_HAL_DEF_REGISTER_END() }}} // Definition of HAL implementation ---------------------- namespace some_subsystem { namespace driver { namespace asic_ver_123 { class some_controller_impl : public some_controller { public: virtual bool operate() { bool result = false; // Suitable bitfield type is deduced from its definition (but can be manually overridden) // In this case it will be signed char or bigger (CONTROL_REG1::TEMPERATURE = 6 bits) suitable<CONTROL_REG1::TEMPERATURE>::type temperature = 0; // Library automatically generates the bitfield's getter // which reads the register, masks & shifts unrelated bits, // performs (optional) value conversion and (mandatory) cast. // Debugging/logging also possible result = get<CONTROL_REG1::TEMPERATURE>(temperature); // Pass "temperature" by reference // This would not compile, CONTROL_REG1::TEMPERATURE is read-only // result |= set<CONTROL_REG1::TEMPERATURE>(temperature); // Compile error if(true == result && temperature > 20) { // Library automatically generates the bitfield's setter // which performs read-modify-write with value validation result |= set<CONTROL_REG1::FAN_RPM>(1000); result |= set<CONTROL_REG1::ENABLE>(true); // This would return "false" (7000 is an invalid value for FAN_RPM) // result |= set<CONTROL_REG1::FAN_RPM>(7000); } else { result |= set<CONTROL_REG1::FAN_RPM>(0); result |= set<CONTROL_REG1::ENABLE>(false); } return result; } }; }}} // End of snippet ---------------------------------------------- This snippet shows the very basic functionality, anyway please share your opinions if the idea is catchy and suitable for boost! Best regards, -- Szymon Gutaj

1 0

typos in boost/atomic/details/interlocked.hpp
by Clark Sims 01 Dec '11

01 Dec '11

It looks like there are a lot of typos in this file. It would not compile on Visual Studio 2005 for me. I fixed all the typos, and now I can compile with no problem. There were lots of cases where the author looks like he forgot to add the variable, order, to the argument list of the function. < atomic_thread_fence(memory_order order) --- > atomic_thread_fence(memory_order) Here is a link to my final version of the file: http://acumensoftwareinc.com/interlocked.hpp Here is the diff of the 2 versions: 10d9 < #include <boost/memory_order.hpp> 33c32 < platform_fence_before(memory_order order) --- > platform_fence_before(memory_order) 38c37 < platform_fence_after(memory_order order) --- > platform_fence_after(memory_order) 43c42 < platform_fence_before_store(memory_order order) --- > platform_fence_before_store(memory_order) 55c54 < platform_fence_after_load(memory_order order) --- > platform_fence_after_load(memory_order) 57,58c56,57 < if (order == memory_order_seq_cst) { < x86_full_fence(); --- > if (order == memory_order_seq_cst()) { > x86_full_fence(void); 89c88 < atomic_thread_fence(memory_order order) --- > atomic_thread_fence(memory_order) 91,92c90,91 < if (order == memory_order_seq_cst) { < detail::atomic::x86_full_fence(); --- > if (order == memory_order_seq_cst()) { > detail::atomic::x86_full_fence(void)

1 0

Library categories
by Vicente J. Botet Escriba 30 Nov '11

30 Nov '11

Hi, I was wondering if we can add other categories to the library catalog (http://www.boost.org/users/history/version_1_47_0.html) Here is a proposal Best, Vicente Domain Specific crc - Cyclic Redundancy Code, from Daryle Walker. units - Zero-overhead dimensional analysis and unit/quantity manipulation and conversion, from Matthias Schabel and Steven Watanabe. uuid - A universally unique identifier, from Andy Tompkins. Idioms base-from-member - Idiom to initialize a base class with a member, from Daryle Walker. compressed_pair - Empty member optimization, from John Maddock, Howard Hinnant, et al. Language Emulation: these are libraries are emulating a missing language feature exception - A library for transporting of arbitrary data in exception objects, and transporting of exceptions between threads (N2179), from Emil Dotchevski. move - Portable move semantics for C++03 and C++1 compilers, from Ion Gaztañaga scope_exit - Execute arbitrary code at scope exit, from Alexander Nasonov. typeof - Typeof operator emulation, from Arkadiy Vertleyb and Peder Holt. Patterns: libraries that implement a known pattern flyweight - Design pattern to manage large quantities of highly redundant objects, from Joaquín M López Muñoz. signals - managed signals & slots callback implementation, from Doug Gregor. signals2 - managed signals & slots callback implementation (thread-safe version 2), from Frank Mori Hess. State Machines meta state machine - High-performance expressive UML 2.0 finite state machines, from Christophe Henry. statechart - Arbitrarily complex finite state machines can be implemented in easily readable and maintainable C++ code, from Andreas Huber. System: libraries that are close to the underlying system chrono - Useful time utilities, from Howard Hinnant, Beman Dawes, Vicente J. Botet Escribá. date_time - Date-Time library from Jeff Garland. filesystem - Portable paths, iteration over directories, and other useful filesystem operations, from Beman Dawes. system - Operating system support, including the diagnostics support that will be part of the C++0x standard library, from Beman Dawes. I would add also the following to exixting categories Data structures optional - Discriminated-union wrapper for optional values, from Fernando Cacciola. tribool - 3-state boolean type library, from Doug Gregor. I have no suggestion for the following, so we can maintain them in Miscellaneous conversion - Polymorphic and lexical casts, from Dave Abrahams and Kevlin Henney. swap - Enhanced generic swap function, from Joseph Gauterin. timer - Event timer, progress timer, and progress display classes, from Beman Dawes. TR1 - An implementation of the Technical Report on C++ Library Extensions, using other Boost libraries as a basis, from John Maddock. utility - Class noncopyable plus checked_delete(), checked_array_delete(), next(), prior() function templates, plus base-from-member idiom, from Dave Abrahams and others. value_initialized - Wrapper for uniform-syntax value initialization, from Fernando Cacciola, based on the original idea of David Abrahams. The following libraries are already in another category lexical_cast - General literal text conversions, such as an int represented as a string, or vice-versa, from Kevlin Henney. numeric/conversion - Optimized Policy-based Numeric Conversions, from Fernando Cacciola. program_options - Access to configuration data given on command line, in config files and other sources, from Vladimir Prus.

7 18

[rfc] lockfree API/naming suggestions
by Tim Blechmann 30 Nov '11

30 Nov '11

hi all, i am preparing boost.lockfree so that it can be merged to trunk. however i'd request some suggestions, concerning interface and names: ringbuffer naming: there is a fixed-sized single-producer/single-consumer wait-free queue, which is implemented as ringbuffer. the linux kernel uses the name `kfifo', the jack-audio-connection-kit refers to it as `ringbuffer', herlihy/shavit discuss it under the name `BoundedQueue'. the boost.lockfree implementation is currently named `ringbuffer', but i could rename it before merging it into trunk. suggestions: ringbuffer waitfree_queue spsc_queue bounded_queue personally i'd be in favor of `ringbuffer' (because i have been using this name for years) or `spsc_queue' (because it makes clear that it doesn't support multiple produces/consumers). but i'd be curious, what other people suggest. fifo/queue bounded push: fifo and queue can be configured to use a dynamically growing freelist for memory management. in this case, the `push' operations may block if the freelist is exhausted and a new node has to be allocated from the OS. currently this can be avoided by a per-class policy. however it would be reasonable to move this policy from a per-class to a per- call policy. so instead of: queue<T, boost::lockfree::bounded<true> > q; T t; q.push(t); one could write: queue<T> q; T t; q.push_nonblocking(t); however this would imply 3 flavors of `push' * push, which may block during memory allocation * push_unsafe, which is not thread-safe (but faster) * push_nonblocking, which is guaranteed not to hit the memory allocator. so i am not sure, whether this introduces too much complexity into the API. any thoughts/comments? thanks, tim

5 8

installing 1.48 on debian squeeze
by Janek Kozicki 30 Nov '11

30 Nov '11

Hi, does anybody here know some not too complex way to install boost 1.48 on debian squeeze? Preferably using a .deb package. manual install is also acceptable, but in a way where it will not conflict with native installed boost 1.42. looking forward for your help -- Janek Kozicki http://janek.kozicki.pl/ |

2 1

[spirit] scan_keyword: scan an InputIterator for a keyword.
by Vicente J. Botet Escriba 30 Nov '11

30 Nov '11

Hi, for chrono input I'm using a scan_keyword function that adapted from libc++ library (you can find the code in[1]). Next follows the interface: // scan_keyword // Scans [b, e) until a match is found in the basic_strings range // [kb, ke) or until it can be shown that there is no match in [kb, ke). // b will be incremented (visibly), consuming CharT until a match is found // or proved to not exist. A keyword may be "", in which will match anything. // If one keyword is a prefix of another, and the next CharT in the input // might match another keyword, the algorithm will attempt to find the longest // matching keyword. If the longer matching keyword ends up not matching, then // no keyword match is found. If no keyword match is found, ke is returned // and failbit is set in err. // Else an iterator pointing to the matching keyword is found. If more than // one keyword matches, an iterator to the first matching keyword is returned. // If on exit b == e, eofbit is set in err. // Examples: // Keywords: "a", "abb" // If the input is "a", the first keyword matches and eofbit is set. // If the input is "abc", no match is found and "ab" are consumed. template <class InputIterator, class ForwardIterator> ForwardIterator scan_keyword(InputIterator& b, InputIterator e, ForwardIterator kb, ForwardIterator ke, std::ios_base::iostate& err ); What is the better way to do that (or something similar) with Spirit/Lexer? Can we hope that the Spirit solution could perform much better? What about if the strings to parse are know at compile-time? [1] https://svn.boost.org/svn/boost/trunk/boost/chrono/detail/scan_keyword.hpp Best, Vicente

2 3

temp_ptr<> - preventing use as a member
by Gottlob Frege 29 Nov '11

29 Nov '11

I'm trying to see if I can replace all raw pointers with suitable smart pointers that clearly describe the pointer's lifetime, sharing, etc. For example, a pointer passed into a function, that is only valid for the lifetime of the function call. A temp_ptr or callstack_ptr or ... some better name. So this pointer would need a copy constructor so it can be passed along into a function (I don't think requiring a ref to the pointer would be good; I'd rather pass by value). It would also need construction from a raw pointer, but to avoid having a temp_ptr being kept beyond the function call, it would not have assignment (from another temp_ptr). To prevent constructing one via the copy constructor that will be kept around, I can define a custom new operator but keep it private. The only thing, I think, that I can't prevent, is construction of a new wrapper struct that has a temp_ptr as a member (which is copy constructed in wrapper's constructor). Can anyone think of a way to prevent that? I think anyone that goes out of their way to make a wrapper struct gets what they deserve, so I don't really *need* to prevent all bad uses. But I can aslo imagine someone just using it improperly inside their class due to misunderstanding or whatever. And thoughts on the goal of specific smart pointers for all occasions? Tony

6 11

[trac] please add component
by Akira Takahashi 29 Nov '11

29 Nov '11

Hi, I seems to so that the 1.48.0 library component is not registered in Trac(container, move, and locale). Please add component.

2 2

[optional] std::tr2::optional
by Andrzej Krzemienski 29 Nov '11

29 Nov '11

Hi, I use boost::optional quite often, find it very useful, and cannot imagine that it could not get into TR2. I am considering writing a proposal for adding it myself (if it is possible to propose things without attending the committee meetings), but I would first want to know how boost::optional could be improved given the new features in C++11. I provide a list of modifications that I could think of. What is your opinion? * Conversion explicit conversion to bool should be declared as explicit. * Should exception safety guarantees for assignment operations be enforced? In boost::optional they only provide a basic guarantee. One option is to provide strong guarantee for types T which implement operator= with strong guarantee, and give basic guarantee for other cases Other option (not sure if it is possible) is to provide strong guarantee for all cases at the cost of run-time performance (heap allocation). * Add move operations optional<T> & operator=( optional<T> && ) noexcept( nothrow_move_constructible<T>::value ); optional<T> & operator=( T && ) noexcept( nothrow_move_constructible<T>::value ); * move operations for optional references? But I am not sure what optional references are for... * What are optional references for anyway? * it could add an rvalue reference overload for stored object access: T&& operator*( ) && However using this overload implies that the user is not checking if an optional has been initialized, so it may encourage a bad practice. * Are in-place factories necessary if we have perfect forwarding? Instead, we can provide a reset function and a "variadic constructor": template< typename ... Args > void reset( Args&& ...args ); template< typename ... Args > optional( Args&& ...args ); The constructor will clash with another optional constructor: optional<T>::optional( bool cond, const T& val ); but perhaps it is not needed if we have std::optional<T> std::make_optional( bool cond,const T& val ); and move construction of optionals? * noexcept default construction and destroy operations * constexpr default ctor * Use nullptr instead of boost::none? - this will make some uses of optional pointers harder, but will make usage more clear in other cases. Regards, &rzej

7 7

Proposed Boost.Algorithms Review Ends
by Dave Abrahams 28 Nov '11

28 Nov '11

The review of Marshall Clow's proposed Boost.Algorithms submission officially ended yesterday, but if you get your review in before the end of the weekend, as review manager I'll probably consider it. So far we've had five votes, which is reasonable for something of this scale. Thanks everybody for your time and interest. I'll be posting the review results next week. Regards, Dave -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 3

[msm] guard behavior if guard guards the transition MSM threats event as handled is that correct?
by Michael.Herchel＠rohde-schwarz.com 28 Nov '11

28 Nov '11

Hi Christophe, Regarding our compile-time problem in the past and therefore, the changes Richard made: Would it be also feasible to develop an additional backend that is derived from the MSM one, but only implements the process_event() method for each event and not in a generic template-based way? With this approach we could still use MSM out-of-box and not having the need for internal transition tables or having references from inner to outer state machines etc but still gain small compiler units. I understand that we will loose flexibility and creating new state machines becomes more work, but I think we could live with that. What is your opinion? Am I thinking too short? Thanks, Michael

2 1

Fwd: [msm] guard behavior if guard guards the transition MSM threats event as handled is that correct ?
by Richard Szabo 28 Nov '11

28 Nov '11

Hi Christophe the attached example I think shows 2 problems. 1st is that the deferral of event3 is not happening. 2nd is that the no_transition function is never called. the output of the run is : MS1 Entering State: Idle by: event1 MS1 Leaving State: Idle by: event1 MS1 Entering State: SubRunning by: event1 FwdGuard: returns:1, event: event2 Processing BaseEvent Instance(event2) Setting guard false FwdGuard: returns:0, event: event3 FwdGuard: returns:0, event: event4 FwdGuard: returns:0, event: event5 MS1 Leaving State: SubRunning by: event5 MS1 Entering State: AfterSub by: event5 I think it shall be : MS1 Entering State: Idle by: event1 MS1 Leaving State: Idle by: event1 MS1 Entering State: SubRunning by: event1 FwdGuard: returns:1, event: event2 Processing BaseEvent Instance(event2) Setting guard false FwdGuard: returns:0, event: event3 FwdGuard: returns:0, event: event4 MS1 no_transition event (event4) MS1 Leaving State: SubRunning by: event5 MS1 Entering State: AfterSub by: event5 MS1 no_transition event (event3) So in this example event3 and event4 are never triggered a transition ... the Row < SubRunning , baseEvent , none , ProcessBaseEvent , FwdGuard > was guarded by the FwdGuard for these events. Is my expected behavior wrong ? If guard is executed but the transition actually is triggered because it is guarded out why this event treated as handled event ?. This 2 problems breaks my current nested state machine implementation because I'm using no_transition to forward the event to the outer state machine. I'm confused :(. Cheers Richie

2 6

[spirit] missing boost/endian/integers.hpp
by Jürgen Hunold 28 Nov '11

28 Nov '11

Hi, after the version number bump to 1.49.0 my builds fail with src/devel/boost/boost/spirit/home/support/detail/endian.hpp:24:37: fatal error: boost/endian/integers.hpp: No such file or directory It seems that spirit want to use Boost.Endian from 1.49 which is not merged to trunk yet. Patch attached, ok to commit? Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

2 1

[preprocessor] Get last token
by Roman Perepelitsa 28 Nov '11

28 Nov '11

Is it possible to extract the last token from a list of space separated tokens? LAST_TOKEN(a b) // expands to b LAST_TOKEN(blah blah b) // expands to b LAST_TOKEN(* & b) // expands to b Roman Perepelitsa.

2 4

Re: [boost] [Boost-commit] svn:boost r75690 - trunk/tools/build/v2/tools
by Steven Watanabe 27 Nov '11

27 Nov '11

AMDG On 11/27/2011 04:50 AM, bdawes(a)acm.org wrote: > Author: bemandawes > Date: 2011-11-27 07:50:00 EST (Sun, 27 Nov 2011) > New Revision: 75690 > URL: http://svn.boost.org/trac/boost/changeset/75690 > > Log: > Change deprecated /Op option to its replacement, /fp:precise. This quiets a warning from the Intel compiler, which uses the msvc toolset. > Did you miss my reply on boost-build? Please revert this. It's wrong. > On 11/26/2011 06:03 AM, Beman Dawes wrote: >> > The patch below clears a warning from Intel 12.1, and works fine for >> > MSVC 8, 9, and 10. >> > >> > Unless someone objects, I'll apply it tomorrow. I'm posting advance >> > notice in case any of the math folks want to give it a try beforehand. >> > > I object. This branch is for msvc 6 and 7, which > only have /Op. /fp:precise is for msvc 8 and > up. The real problem is that intel-win is assuming > vc7.1 compatibility. > > Text files modified: > trunk/tools/build/v2/tools/msvc.jam | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > Modified: trunk/tools/build/v2/tools/msvc.jam > ============================================================================== > --- trunk/tools/build/v2/tools/msvc.jam (original) > +++ trunk/tools/build/v2/tools/msvc.jam 2011-11-27 07:50:00 EST (Sun, 27 Nov 2011) > @@ -240,7 +240,7 @@ > > # Improve floating-point accuracy. Otherwise, some of C++ Boost's "math" > # tests will fail. > - toolset.flags $(toolset).compile CFLAGS $(conditions) : /Op ; > + toolset.flags $(toolset).compile CFLAGS $(conditions) : /fp:precise ; > > # 7.1 and below have single-threaded static RTL. > toolset.flags $(toolset).compile CFLAGS $(conditions)/<runtime-debugging>off/<runtime-link>static/<threading>single : /ML ; > _______________________________________________ > Boost-commit mailing list > Boost-commit(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-commit >

2 1

[local] Any "active Boost library author" in favor of Boost.Local?
by Lorenzo Caminiti 26 Nov '11

26 Nov '11

Hello all, I will be honest: The fact that some of the people arguing for not including Boost.Local are "active Boost library authors" (Thomas, Joel, and Hartmut) seems to make their opinion weight more than the opinion of others that have also submitted a review for the library. Two questions: 1) Should reviews from "active Boost library authors" carry more weight? (This is /not/ a rhetoric question.) 2) Is there any "active Boost library author" out there that is in favor of including Boost.Local? (If so, please say so by replying to this thread.) Thanks a lot :) --Lorenzo

8 18

Re: [boost] New libraries implementing C++11 features in C++03
by Brent Spillner 25 Nov '11

25 Nov '11

On 24 Nov 2011 20:19:17 Joel de Guzman wrote: >The funny thing is that the new feature came from Spirit, not >Phoenix. Phoenix API has been stable for many years now. Triple >sheesh for ya! :-) Then why did V3 require a review earlier this year? Phoenix is great if you want things that are easy in a functional programming language to seem easy in C++, but it does have a learning curve. Local requires a little more typing for short snippets, but is probably far less intimidating, and has far fewer potential "gotchas", for the typical user. I don't think the two are competing with each other at all--- Phoenix provides a far richer set of building blocks for those who want them, and Local offers a stable interface, trivial execution model, and straightforward error messages for those who simply want to use a local function here and there. For a non-guru who just wants to reduce code duplication or port something from Delphi, Local is in many cases the more appealing choice.

2 2

Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local?
by Andrzej Krzemienski 25 Nov '11

25 Nov '11

> Hello all, > I will be honest: The fact that some of the people arguing for not > including Boost.Local are "active Boost library authors" (Thomas, > Joel, and Hartmut) seems to make their opinion weight more than the > opinion of others that have also submitted a review for the library. > Two questions: > 1) Should reviews from "active Boost library authors" carry more > weight? (This is /not/ a rhetoric question.) Hi Lorenzo. I am /not/ an active Boost library author or maintainer. I will only address the first question. I was asking myself the same question recently, and my answer to it is that their opinions should weigh more than others'. Well, "others" is an ambiguous term; I meant someone like me, who is just a Boost user, and says "I want to have this, and this, and that one". My argument is that Boost as an organization has its goals or status, or spirit (no pun intended). I tried to look for something like "what is our goal" on the Boost site, but I did not find a satisfactory answer. The only thing that I found useful is a section in Scott Meyers's "Effective STL". I am not sure if Boost developers will agree, but he says that Boost was founded in part by people who submitted proposals for Standard Library to the C++ committee that were rejected. Boost was supposed to be the place where these libraries were still to be developed, maintained and widely used, which would give them the grater chance to succeed in the next round of standardization. On the other hand, some existing Boost libraries do not appear (at least in my limited view) to meet this criterion (as well as other criteria mentioned recently). I am thinking about the unit testing framework. Do not get me wrong I am not trying to imply that it shouldn't be there, and in fact this is my preferred unit testing framework for many valid reasons. But I was trying to apply the recently risen acceptance criteria to all Boost libraries that I know, and this example appeared the most interesting. Even though it provides a non-macro alternative it encourages using macros for nearly everything in the "automated version": tests, checks, suites, modules. Even thought there are other free libraries for C++ that are known to provide almost the same functionality without a single macro: http://tut-framework.sourceforge.net/. It does not look like a potential candidate for the inclusion into the standard; there are many unit-testing frameworks out there that do not appear to be any worse. It does not appear to encourage some good coding style (apart from the fact that having good unit tests is a good development style).... Given this lack of clear criteria, active Boost library authors and maintainers should be in the better position to assess if the tacit criteria for library admission are met. Some of them have been with boost since its inception (almost 15 years now). If we think otherwise, we are risking the situation where Boost users that just want some library "in the Boost package" will outnumber the few library developers that have a broader goal in mind, and may not even have time to submit a review because they are busy maintaining their libraries or submitting proposals to ISO Committee. I guess that in case of Boost.Local review, this argument would be stronger if the "active Boost library author" reviewers were not the authors of libraries that /somehow/ overlap with Boost.Local. Thus I believe you are bringing the valid point in trying to engage other Boost library authors, and it would be beneficial, also to the entire Boost community, if someone responded to your question. Regards, &rzej

1 0

Formal Review Schedule Queue
by Ben Robinson 25 Nov '11

25 Nov '11

Currently, there are eight library submissions in the queue, none of which have a review manager or a scheduled review period. What is the process to assign review managers? I realize that the Boost.Local review is still in progress (and quite a lively discussion). :) Ben Robinson, Ph.D.

2 1

[Boost.Local] Review
by Hartmut Kaiser 25 Nov '11

25 Nov '11

This is not a full review, mainly because I have not had the time to devote more than a quick glance over the documentation (which is a good read, btw). Upfront my vote: no, please do not include this library into Boost. My reasons are: a) Boost is a library which has quite some visibility not only for library writers but also for application developers. IMHO, Boost not only has the task of finding new ways for using C++, but it plays the role of evangelizing good programming style, great API design, and thoughtful functionality. Using macros as the sole API of a library to be mainly used by application writers (not library authors) is not a good idea because of all those well know problems related to macros: difficult to debug, error messages are even more difficult to interpret than those generated by TMP, macros are type agnostic and have absolutely no knowledge of C++, etc. b) The proposed library does not add any functionality which couldn't be _easily_ replaced by using existing C++ language features or libraries. This is especially true if we talk about C++11 (which we should, IHMO). c) A very personal reason: code written based on the proposed library for me tends to be an unreadable mess. I have problems to remember, what arguments to the macros means what, when to use additional parenthesis and when not, etc. This is especially true when it comes to using 'default' and 'bind' in the argument list. This just does not 'look right' to me. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

7 20

Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local
by Brian Wood 25 Nov '11

25 Nov '11

Lorenzo Caminiti: > Hello all, > > I will be honest: The fact that some of the people arguing for not > including Boost.Local are "active Boost library authors" (Thomas, > Joel, and Hartmut) seems to make their opinion weight more than the > opinion of others that have also submitted a review for the library. > > Two questions: > 1) Should reviews from "active Boost library authors" carry more > weight? (This is /not/ a rhetoric question.) > 2) Is there any "active Boost library author" out there that is in > favor of including Boost.Local? (If so, please say so by replying to > this thread.) I'm in favor of accepting it. Not because I plan to use it, but think Boost could use the help and you have been learning the ropes. Regardless of the outcome of the review, I like the tenacity you've shown. I'm not a Boost library author. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

1 0

Error in the getting started guide?
by Philip Bennefall 24 Nov '11

24 Nov '11

I was just looking at the getting started guide on Windows for version 1.48.0 and saw this paragraph: The easiest way to get a copy of Boost is to use an installer. The Boost website version of this Getting Started guide will have undated information on installers as they become available, ..." I'm guessing it should be "updated"? It might confuse new users slightly so I thought I'd mention it. If the list is not the right place for this note, then I apologize. Kind regards, Philip Bennefall

2 1

[lexical_cast] Error casting void* to std::string
by GMan 24 Nov '11

24 Nov '11

I did a search on the mailing list and found nothing, but apologies if I missed it. This bug seems to be new to 1.48. Compiling the following code in MSVC2010: #include <boost/lexical_cast.hpp> #include <string> int main() { void* ptr = 0; boost::lexical_cast<std::string>(ptr); } Results in an error, pointing to line 1738 in boost\lexical_cast.hpp, stating: 'removed_ptr_t': illegal sizeof operand. ('removed_ptr_t' is, however, defined a few lines above.) I see nothing wrong with the code from a C++ point-of-view, so I'm guessing this is another MSVC bug. Is this known? I don't see an immediate permanent workaround. A client-side workaround exists by introducing this small class: struct print_ptr { explicit print_ptr(void* ptr) : mPtr(ptr) {} friend std::ostream& operator<<(std::ostream& sink, print_ptr printPtr) { return sink << printPtr.mPtr; } private: void* mPtr; }; And using: boost::lexical_cast<std::string>(print_ptr(ptr)); -- GMan, Nick Gorski

3 3

Re: [boost] What is boost:
by Brian Wood 24 Nov '11

24 Nov '11

From: Gregory Crosswhite > Perhaps, but could you give us some examples of what you mean to provide a better sense of what you are thinking? Thanks! :-) If a library hasn't had a maintainer for a certain period then it gets removed. If I'm using a library that is close to being removed I'd either have to do something to help maintain it or decide to use another library. I'm OK with it becoming easier to add libraries if it also becomes easier to remove them. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

3 2

Policy when duplicate code detected
by Ioannis Papadopoulos 24 Nov '11

24 Nov '11

Hi, I was wondering what is the policy when someone finds code that is clearly duplicated or implements the same thing with just different interface? What is the best way to report it? Thanks

2 1

Re: [boost] What is boost:
by Brian Wood 24 Nov '11

24 Nov '11

Lorenzo Caminiti: >On Wed, Nov 23, 2011 at 2:09 PM, Robert Ramey <ramey(a)rrsd.com> wrote: >> >> So I'm more of the view that we let stuff into boost as long at it meets >> quality standards. ?Then let users decide. > > +1 I guess, but is there any way to remove libraries from Boost? I think it almost needs pruning more than it needs more libs. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Re: [boost] [Boost.Local] Review
by Brent Spillner 24 Nov '11

24 Nov '11

On 23 Nov 2011 10:24:53 Leo Goodstadt wrote: >For "acknowledgment" / "acknowledgement": both spellings started out in the >16th c. but the first form historically was found more in the US. Citations >from the 19th and 20th c show that both variants are found on both sides >of the Atlantic (e.g. the short form in the UK in Dickens, Bronte, Macaulay) >though the long form seems to predominate in the 20c only in U.K. >newspapers. I too appreciate the clarification--- guess I didn't understand this quite as well as I thought. In the US, "acknowledgement" does seem to correlate frequently with a casual attitude toward spelling, but it looks like I need to broaden my horizons a bit.

1 0

Re: [boost] [local] Review (and resignation from review assistant)
by Andrzej Krzemienski 23 Nov '11

23 Nov '11

> > Ok, I am not sure if there are no better ways to write it in each variant, > > and I may be biased. I also didn't try to compile the examples. But it > > should give the potential users an overview of options they have. > > Yep. This highlights the verbosity well: > for_each( vec.begin(), vec.end(), if_(empty(_1)) [_1 = "n/a"] ); > vs: > BOOST_CLOSURE_PARAMS( std::string & n ) { > if( n.empty() ) n = "n/a"; > }BOOST_CLOSURE_NAME(replace_empties); > for_each( vec.begin(), vec.end(), replace_empties ); Honestly, my goal was to show an example where Phoenix has limitations and Local could be considered an attractive alternative. Obviously my example failed to do that. I wanted to see how you can call member functions. I can see Phoenix has nice support for container-like operations. But how about changing the rules a bit, and calling an arbitrary member function? for_each( vec.begin(), vec.end(), if_(bind(&SuperLib::SuperString::IsVulgar, arg1)) [arg1 = "unknown" ] ); vs. BOOST_CLOSURE_PARAMS( SuperLib::SuperString & n ) { if( n.isVulgar() ) n = "unknown"; }BOOST_CLOSURE_NAME(replace_vulgar); for_each( vec.begin(), vec.end(), replace_vulgar ); I realize that one can tweak examples to show whatever one wants. But member access does not appear too unusual. This really happened to me that I used a very complicated bind statement where I had to bind some variables and leave some free, pass some by reference, some by value. I thought "it was the right way because this is Boost way", until I realized no-one else in the team knows what that is suppose to mean. Regards, &rzej

2 1

[parameter] increase BOOST_PARAMETER_MAX_ARITY
by Tim Blechmann 23 Nov '11

23 Nov '11

hi, i've been using boost.parameter extensively with boost.heap and now came to a point, that i need to raise BOOST_PARAMETER_MAX_ARITY to at least 7 in order to be able to compile it. i am planning to merge boost.heap into trunk in the next few days, so i wonder, would it be reasonable to increase the default of this value to e.g. 8 (patch attached)? currently, boost.heap defines BOOST_PARAMETER_MAX_ARITY before including boost/parameter.hpp, but this will break, if boost/parameter.hpp is included before the boost.heap headers. it would be great, if the default would be high enough to compile all boost libraries, or could this cause any issues? thanks, tim

1 0

[local] not just "better" error messages (was: Re: New libraries implementing C++11 features in C++03)
by Lorenzo Caminiti 23 Nov '11

23 Nov '11

Note: I've changed the title of the email because this part of the discussion is not related to Boost for C++11 or C++03. On Wed, Nov 23, 2011 at 6:21 AM, Joel de Guzman <joel(a)boost-consulting.com> wrote: > On 11/23/2011 5:53 PM, Lorenzo Caminiti wrote: >>> we should do is push the C++ compiler writers to give us library writers >>> > more power to address the problems such as the often cited deluge of >>> > undecipherable error messages. TMP libraries are ubiquitous in modern C++. >>> > Avoiding them because of the problem of error messages is backwards thinking. >>> > What we should do instead is to find better solutions, not hide the problems. >>> > >>> > This is Boost! > >> How is a library like Boost.Algorithm pushing the limit? It's a very > > How did you arrive at that? I said: > > "what we should do is push the C++ compiler writers to give us library > writers more power to address the problems such as the often cited > deluge of undecipherable error messages." > > Please read that again. You've mixed that with what I said earlier: > > "Keep in mind that Boost has been at the forefront of C++ library > development. It is because of these libraries that push the limits > of C++ that we see the advancement in C++ that we enjoy now in C++11." > > I never said that all libraries in Boost push the limits of C++. I see, yes that is what you wrote for example here "what we should do is push the C++ compiler writers to give us library writers more power to address the problems such as the often cited deluge of undecipherable error messages". I miss read your email, I didn't understand that it was pushing the limits of compilers to give library programmers more control over error detection/reporting. Thanks for the clarification. > All the rest of your reply is irrelevant. Well, no. The following part of my reply is now even more relevant because it repeats that Local is not just about (2) better error messages (your point above about pushing the limit) but also about (1) usual statement syntax for the function body (which every programmer in your team will understand at once). >> the syntax presented there. Proponents of locals have cited error-messages >> generated by the compiler as a justification for Locals. Locals is probably >> a good workaround. But hear me out... > > Nope, not just a good workaround for error-messages. Proponents of > Locals mentioned two (2) main things as advantages. Please let's cite > both of them correctly: > 1) Use statement syntax for function definition. > 2) Compiler error retain their usual meaning for the function definition. > While these two things are related from an library implementation > prospective, they are two different advantages for the library > end-user. > > The politically correct sentence fro the docs: "[Local functions] can > be defined using C++ statement syntax plus eventual compiler errors > follow the usual format of C++ statement errors". > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… --Lorenzo

1 0

Re: [boost] [Boost.Local] Review
by Leo Goodstadt 23 Nov '11

23 Nov '11

> John Bytheway <jbytheway+boost <at> gmail.com> writes: > > > > On 19/11/11 20:39, Brent Spillner wrote: > > > On Fri, 18 Nov 2011 20:59:26 lorcaminiti wrote: > > >>> The title is spelt wrong (should be Acknowledgements) > > > Actually, "Acknowledgments" is the traditionally correct spelling. > > > There are some dictionaries that accept "Acknowledgement," but this > > > reads as faddish and less literate. A similar word is "judgment"--- > > > both are frequently misspelled even by native speakers. > > BTW, I grew up spelling both as "acknowledgement" and "judgement". Online > sources seem to indicate that in Britain those spellings are the norm while in > the US the 'e' after 'g' is usually dropped. But I was born and raised here in > the US so what gives? Given that my first name is "Geoff" (English spelling) and > not "Jeff" (American spelling) the confusion is readily apparent? This is where the Oxford English Dictionary with all its historical citations comes in handy. For "acknowledgment" / "acknowledgement": both spellings started out in the 16th c. but the first form historically was found more in the US. Citations from the 19th and 20th c show that both variants are found on both sides of the Atlantic (e.g. the short form in the UK in Dickens, Bronte, Macaulay) though the long form seems to predominate in the 20c only in U.K. newspapers. For "judgement" / "judgment": judgement seems slightly more consistent etymologically (with the Old French/Norman "iugement"?). This may be why it seems to be preferred by the OED. However, both forms are equally old, and >80% of the modern citations have the *short* form not the long form, on both sides of the Atlantic. Conclusion: Spell these words however you want! Hope that clears thing up. Leo

3 2

[local] Review
by John Bytheway 23 Nov '11

23 Nov '11

To begin with, my overall opinion: I say yes, Boost.Local should be accepted. > - What is your evaluation of the design? The design is clearly well thought-out. I admire Lorenzo's dedication to discussing his design decisions as thoroughly as possible on the mailing list. I've watched the development of the library with interest, and have been glad of the opportunity to comment along the way. On one specific pleasant surprise: thank you for providing the inline feature to offer your users the chance to choose their optimization trade-offs for themselves, and I'm glad you found a faster alternative to the virtual function trick. However, I still have a few concerns: I question the choice to bind const variables by const value by default, with (as far as I can see) no means to bind them by non-const value. This runs contrary to my instincts in regard to functions in C++ more generally (although I see C++11 lambdas have similar behaviour...). It's not a serious problem, but I would have chosen differently. On binding this: I vote that this_ is a better name than _this. The name is not a placeholder in the sense the term is used in libraries using the leading underscore convention for placeholders. Also, how do your various choices of syntax behave in the context of nested local functions? Consider: void BOOST_LOCAL_FUNCTION_PARAMS(bind this) { void BOOST_LOCAL_FUNCTION_PARAMS(bind this_) { this_->f(); } BOOST_LOCAL_FUNCTION_NAME(g) } BOOST_LOCAL_FUNCTION_NAME(h) If you change the syntax (as I think you were proposing) so that "this_" appears in the first line here in place of "this", then how would the second line behave? I would want it to bind the this pointer for the outer object, not the inner instance of the class that Boost.Local defines for me. You discuss exception specifications for the various objects that can be defined. If this includes noexcept in C++11 (which I imagine it does) then you should mention that. The ability to write noexcept local blocks (which can easily be made to work in C++03 too) might be another motivating feature for local blocks. Furthermore, you should seriously consider whether BOOST_LOCAL_EXIT's function should be declared noexcept by default where possible, since it is in many ways like a destructor. How feasible would it be to allow overload to be used without declaring all the function types. So, your example: boost::local::function::overload< void (const std::string&) , void (const double&) // Overload 1st param type. , void (const double&, const char*) // Overload giving default param. , int (int, int) // Overload giving 2 params (from function pointer). > print(print_string, print_double, print_double, print_add); might be written instead: auto print = make_overload(print_string, print_double, print_double, print_add); (with suitable use of BOOST_AUTO for C++03). I guess this only works if all the functors passed are monomorphic and expose (or could be made to expose) their argument types, but that covers function pointers, boost::function objects, and Boost.Local functions, which is a fairly wide applicability. Writing the above inspires me to ask: Do Boost.Local functions expose their argument types and return types at compile time? If there is a widely accepted way for monomorphic functors to do so, then they should. If there is no such widely accepted way, then one should be created, but that's probably not a job for you right now :). In a similar vein, as I was pondering potential uses of the overload feature, I wondered whether it could be used to write a visitor for Boost.Variant. I suspect that it could not, because such a visitor must declare its return type in a manner tat the overload object will not. It would be nice if that could be made to work. Can you think of a good way? > - What is your evaluation of the implementation? I have not looked at the implementation, but I have followed the discussions and examined some earlier versions of it. Any problems I noted before have, I think, as far as reasonable, been resolved. However, I would like to ask: on the overloading features: It looks like boost::local::function::overload could be written with variadic templates where available and thereby avoid the maximum arities in the configuration macros (and be much simpler and faster to compile). Have you done so? > - What is your evaluation of the documentation? The documentation is very good. Allow me to praise in particular the detailed rationales. A few niggles: * General You have various examples which write to stdout. I realise it's fairly clear, but it might be nice to drive the point home by explicitly showing what the expected output of these programs is. Alternatively, use asserts instead of writing to stdout. * Introduction "the object this can be bound (eventually by constant value" - I don't understand "eventually". * Tutorial The code "if (size && nums) delete[] nums;" perpetuates the myth that one should not delete NULL pointers. Please don't do that. Go ahead and delete[] nums even if it's NULL. "The maximum number of parameters that can be passed to a local function (excluding eventual bound variables)" - I don't understand "eventual". You have the "Important" warning about registering types with Boost.Typeof. I presume this applies only to compilers without typeof support. If so you should probably make this a little more clear. * Advanced Topics Does the existence of the recursive "keyword" mean that a local function cannot be named recursive? If so, you should mention that in passing. "Compilers have not been observed to be able to inline recursive local function calls (not even when the recursive local function is also declared inlined)." - do you mean "not only when"? "C++03 local classes cannot be templates." - this is also true in C++11, right? * Macro BOOST_LOCAL_FUNCTION_NAME "The local function name can be prefixed by the "keyword" inline to declare the local function inlined or by the "keyword" recursive to declare the local function recursive" - can both "keywords" be used? This wording suggests to me that they cannot. If they can, then I suggest changing "or" to "and/or". If not, this should be made clearer. * Macro BOOST_IDENTITY_TYPE I don't understand the "Warning" at the bottom; can you expand? * Macro BOOST_IDENTITY_VALUE The implementation provided on this page doesn't look like it could possibly work. Surely the type T cannot be deduced in a call to identity_value without template arguments? * Examples Should a chunk of the variadic macro version of the Emulating D's Scope Guards" example be commented out? Surely not... * Appendix: Alternatives In the benchmarking note, you say "For all tested compilers, this function pointer prevents the compiler optimization algorithms from inlining the local function calls.". You might want to mention that it is in theory possible for the compiler to inline it, and some other compilers or future versions may do so. (Or you may not, if you think it sounds too weasely or hypothetical) I don't see any of the benchmarking images. Should I? I'm experiencing some very odd symptoms from my graphics card since I first tried to view them, so it may well be a problem at my end. * Release Notes Why is there a "TODO" at the bottom? * Acknowledgments The title is spelt wrong (should be Acknowledgements) Thanks for the thanks :). > - What is your evaluation of the potential usefulness of the > library? Personally, my C++ development has mostly moved to C++11, and I do not expect to have reason to want this functionality, settling for lambdas instead. However, I might yet be in a situation where I am forced to use C++03, and I'm sure many others will be in just that situation for a while yet. In that context, I think this library has significant potential usefulness. Certainly there have been times when I have wanted something like it. Much as I admire Phoenix, I think there will always be circumstances where Boost.Local will be an easier, more useful and more readable alternative. As part of your struggle to motivate the utility of const binding in local blocks, you might want to mention in the documentation the possibility of using it to assure the behaviour of code received in macro parameters as (I imagine) you are doing in Boost.Contract. > - Did you try to use the library? With what compiler? Did you have > any problems? I did not try to use this version, but I have experimented briefly with previous versions, with gcc, clang, and icc (IIRC). I had no problems serious enough that I recall them. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? I read the documentation with moderate care. Also, I have been following the development on the list over recent months. > - Are you knowledgeable about the problem domain? I have faced problems that this library would have solved neatly, and I discussed some implementation details with Lorenzo at times. > Please also consider the following issues and proposals specific to > Boost.Local. Your opinion is welcome on any or all of these. > > - Boost.Local's local exits provide the same functionality (and then > some) as Boost.ScopeExit. Does this duplication of functionality > need to be dealt with, and if so, how? Since I think the Boost.Local version is strictly superior to the Boost.ScopeExit version, I would suggest that the ScopeExit version be deprecated (but not removed, unless it is proving a significant maintenance burden). On the other hand, ScopeExit is a good name for that functionality, and so it is well worth seriously considering upgrading that library and not including the functionality in this new place. Should that be possible to achieve smoothly, it might be a better choice. > - Lorenzo is proposing to add boost::local::function::overload to > Boost.Function as boost::function::overload. Indeed it sounds reasonable to put it there. If so, it should be implemented with due regard for the possibilities of C++11 features (variadic macros, perfect forwarding) as mentioned above. > - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. This seems reasonable. > - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to > boost/utility. I am struggling to see any situation where BOOST_IDENTITY_VALUE is necessary. Can you provide one? When will simply wrapping the expression in parentheses not suffice? Is it because you might be in a preprocessing context that requires an alphanumeric initial character? That's all for my review. Thanks to Lorenzo, Jeffrey, Gregory, and good luck! John Bytheway

2 2

[local] implementation using C++11 lambdas
by Lorenzo Caminiti 22 Nov '11

22 Nov '11

On Tue, Nov 22, 2011 at 3:32 PM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung(a)gmail.com> wrote: > On Tue, Nov 22, 2011 at 11:39 AM, Vicente J. Botet Escriba < >> I think that there is a difference between Boost.Local and Boost.Move. >> Boost.Move provides an emulation of a C++11 feature on compilers that don't >> provides this feature. >> >> Boost.Local provides an emulation of a feature that has not been accepted >> to c++11. >> Note that I'm not saying that Boost.Local should not be accepted, but I'm >> sure that things will be different if Boost.Local provided an emulation for >> c++11 lambdas, that is, if in c++11 compilers the macros could be able to >> generate C++11 lambdas. >> > > Well, named lambdas are basically the same as local functions, no? What I > really mean is, Local provides an imperfect emulation of C++11 lambdas, but > by the same token, Boost.Move provides an imperfect emulation of rvalue > references. > > The question I have for the Boosters that don't like the local function >> approach is if they will accept as a good approximation of the following >> use of a lambda expression >> >> std::sort(x, x + N, [](float a, float b) {return std::abs(a) < >> std::abs(b); }); >> >> the storage on a temporary as in >> >> auto cmp = [](float a, float b) {return std::abs(a) < std::abs(b); }; >> std::sort(x, x + N, cmp); >> >> If Lorenzo would be able to define a macro that could be used to replace >> the named lambda as in >> >> BOOST_AUTO_LAMBDA(cmp, float a, float b, bool, ({return std::abs(a) < >> std::abs(b); })); Yes, this should be trivial but what would be its value? Note that on C++11 compilers the existing Boost.Local local function implementation has compile and run time performance comparable to the ones of C++11 lambdas: https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… Therefore, why would you care if the local function is internally implemented using a C++11 lambda (macro above) or a local struct (macro below) given that there's no significant performance impact? bool BOOST_LOCAL_FUNCTION(float a, float b) { return std::abs(a) < std::abs(b); } BOOST_LOCAL_FUNCTIONS_END(cmp) (Also this has better error messages because the body is out of the macros so the compiler line numbers retain their usual meaning.) In summary, the current Boost.Local implementation already performs as well as C++11 lambdas on C++11 compilers and it also works on C++03 compilers. Therefore the current Boost.Local implementation already allows you to portably program named lambdas (but not lambdas because local functions cannot be defined within expressions) at no performance cost with respect to C++11 lambdas. >> std::sort(x, x + N, cmp); >> >> could you consider that this is promoting good usage of C++11 features on >> compilers that don't provide them and be a good candidate for a Boost >> library? >> > > This is drifting away from my intended thread topic a little bit. But, > nonetheless... Isn't this latter syntax trivial to implement with the > present macros provided by Local? And, as an aside, the significant Yes, it should be trivial. > disadvantage to the above versus splitting the declaration over 2 macro > instantiations is that compiler error messages from the body of the > function would be less informative (essentially missing line numbers). Oh, Yes, all compiler errors would have the same line number (significantly) reducing their informative value. > and I don't know if you can reliably do your BOOST_AUTO_LAMBDA syntax > without variadic macros. That said...it may be convenient to provide > something like that the BOOST_AUTO_LAMBDA macro for simple and small named > lambdas with no unparenthesized commas. HTH, --Lorenzo

1 0

Boost libraries for 'TR2'
by Vicente J. Botet Escriba 22 Nov '11

22 Nov '11

Hi, just out of curiosity, which Boost libraries could we expect to be proposed for the TR2 (or whatever the new C++ run for new libraries will be called)? Who is working on a concrete proposal? Which libraries would you like to be proposed? I would like myself to see between others: Accumulators, Any, Asio, DynamicBitset, Filesystem, Format, Fusion, Interprocess, Intrusive, Mpl, Optional, PointerContainer, ProgramOptions, Proto, Range, Signals, Thread (shared locks), Units and Variant. Best, Vicente

7 11

Re: [boost] [Boost.Local] Review
by Brent Spillner 22 Nov '11

22 Nov '11

On Fri, 18 Nov 2011 20:59:26 lorcaminiti wrote: >> "the object this can be bound (eventually by constant value" - I don't >> understand "eventually". > > It means that you can either "bind this" or "const bind this" (the > second binds the object as constant within the local functions even if > the object is non-const in the enclosing member function). I will make > this text more clear. The issue (both places) is the word "eventually." This is a false cognate with Spanish, Dutch, and probably other languages; in English, "eventually" means only "shall happen at some time in the future." In the rewrite, you probably want to use "optionally" or "possibly" instead. >> * Acknowledgments >> >> The title is spelt wrong (should be Acknowledgements) > > OK. Actually, "Acknowledgments" is the traditionally correct spelling. There are some dictionaries that accept "Acknowledgement," but this reads as faddish and less literate. A similar word is "judgment"--- both are frequently misspelled even by native speakers. Isn't English fun?

5 4

Ok to add new folder?
by Antony Polukhin 22 Nov '11

22 Nov '11

There is already a folder trunk/libs/conversion where lies Boost.Lexical_cast tests. I`d love to split lexical_cast.hpp onto multiple files (old deprecated version, modern version, common headers for two versions...) and put those files into trunk/boost/conversion. Ok to add folder trunk/boost/conversion ? Best regards, Antony Polukhin

2 1

[functional] [variant] Hash patch for variant
by Antony Polukhin 22 Nov '11

22 Nov '11

Header and tests in attachments. Passes tests on GCC-4.4 and VC10. OK to commit to trunk and include header file from boost/functional/hash/extensions.hpp ? Best regards, Antony Polukhin

2 3

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 22 Nov '11

22 Nov '11

> boost::optional can be used for many purposes. One of these (and I had to > use optional like that) is to make classes that provide RAII-like interface > (noncopyable, nonmoveable) usable in contexts where I need to use two-phase > initialization or to release the resource before the end of the scope > (subject to some runtime condition) -- all that in order to have a resource > acquired for as short span of time as possible. > I would be forced to do that for std::lock_guard if the library did not > provide a second template std::unique_lock. But not every library provides > two interfaces for almost the same thing, and this is arguably an > unnecessary redundancy for an interface. optional<RAII> as described above > is a generic tool for transforming types that implement 'scoped ownership' > into types that implement 'unique ownership' of a resource. I think I went too far with this story. Although you can implement a two-phase initialization and cleanup, you cannot provide a full 'unique ownership' semantics with boost::optional for 'scoped' types, because there is no way to implement a move constructor for types that do not support either a move constructor or swap. Regards, &rzej

1 0

[local] Review
by Thomas Heller 22 Nov '11

22 Nov '11

Hi all, Following is my Review of the upcoming Boost.Local library. I will as others split my review into the three parts that make up this library: local functions, local blocks, scoped exit. Let me first start with some general comments. I personally find the decision to support two syntaxes not a good path to follow. While I understand the rationale behind it, and the desire to have the variadic macro version, having both might become a maintenance nightmare. Also, reading through the documentation, most of the time is spent on explaining, the difference between the two syntaxes. Why not just stick with one and concentrate on the functionality? Additionally, despite the introductory motivating statement ("Local functions are a form of information hiding and are useful for dividing procedural tasks into subtasks which are only meaningful locally, avoiding cluttering other parts of the program with functions, variables, etc unrelated to those parts.") I can not see that this library solves this appropriately. I personally think that exposing macros as the interface to program with the library does not lead to a nice and clean design of ones code. Boost.Local is very different from other heavily macro based libraries like Boost.Parameter. It is different, because I would consider Boost.Local not as a infrastructure library but as a library for end users. This being said, i would not like to see application code cluttered with overly verbose calls to macros. As boost is trying to not only push the boundaries of C++ it should also try to set examples of best C++ practice. I would not consider Macro calls to interface with a library not good practice. Local Functions: From the tutorial section on Local Functions: "Local functions are defined using the following macros (see the Reference section) from within a declarative context (this is a limitation with respect to C++11 lambda functions which can instead be declared within expressions):" Right, to have the lambdas in a "declarative context" use auto f = [...](...){...} The default parameter syntax is confusing, it looks like it is a completely new parameter, and not belonging to the previous argument. This gets confusing once you have more than one parameter with a default parameter. The WITH_DEFAULT macro should be the default, as it clearly states the relationship of the default value to the parameter. I would consider binding variables from the enclosing scope one of the major weak points of Boost.Local. The need to binding those variables is obvious. However, how it is done clutters the arguments list of the BOOST_LOCAL_FUNCTION_PARAMS to an extend that it is not immediately clear what the arity of the local function is. It would make things clearer to have something like: BOOST_LOCAL_FUNCTION_PARAMS(...) BOOST_LOCAL_FUNCTION_CAPTURE(...) Additionally as binding is probably the right term to use here, it might confuse people with the already existing solutions of the various bind implementations. WRT to your note in the documentation that C++11 can not bind const reference. I suggest the following workaround: int i = 0; auto f = [&](){ auto const & icr = i; ... }; I agree that this and _this should be used always, instead of having both _this and this. On other notes, Lorenzo already clarified the defect in the library that it can't really be used as a closure. This would have been my next point. All in all the documentation is very accurate and in good shape. Additionally i played around with this specific part of the library a little bit in order to see how i can break it. TBH, I didn't (and still don't) trust the macros to do the right thing always, my knowledge of the PP isn't good enough to judge that particular part of the implementation. However, by deliberately trying to break the breaks (putting typos in the variables, omitting commas etc.) the error messages are of course very arcane, and you have to know exactly where and what part of the macros involved failed and why. Of course, these error message can be deciphered very easily once you have enough experience with that library. But i would argue that this is the case for any other (TMP based) library. Which brings me to my next point. I think that Boost.Local does not fulfill its own purpose. While it is of course true that errors in the function bodies are written in "usual C++" the surrounding macros are, IMHO, just cluttering the code. The points Lorenzo makes in the motivational section are not met. I would argue that most of the times, namespaces and classes are good enough, and such a macro syntax should be avoided. For everything else, there already exist a couple of solutions (Boost.Bind, Boost.Lambda and Boost.Phoenix). I would like to see improvements in ease of use in these libraries instead of advertising a completely macro based solutions. Local Blocks: I can't see the value in that one. The example in the documentation doesn't help either, as those things are easily detected by any modern compiler, with the appropriate warning levels (ok, not in the assert case, but for other boolean contexts at least gcc does). Local Exit: Why do we need two libraries doing the exact same thing with neither of the adding any functionality. I suggest to improve ScopedExit instead. In the alternatives section, which version of Phoenix do you use? Now to the usual questions: > - What is your evaluation of the design? I think the design is not what can be considered Modern C++. However, in the context of what the author tried to achieve, he did a good job. > - What is your evaluation of the implementation? The implementation looks solid! > - What is your evaluation of the documentation? The documentation is very good! > - What is your evaluation of the potential usefulness of the library? The potential usefulness of the library is out of question, that is why C++11 now has lambdas, and libraries like Bind, Lambda and Phoenix exist. However, I do not believe that Local adds any value to the existing solution of the described problems. > - Did you try to use the library? With what compiler? Did you have > any problems? Yes. gcc 4.6.2. no problems. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? Reading of the documentation. Looking briefly at the implementation. > - Are you knowledgeable about the problem domain? Yes. I am the author of Phoenix V3. I vote to not include the library into boost. Regards, Thomas

8 42

Re: [boost] BGL CSR Format (logarithmic edge search)
by Ryan Lichtenwalter 21 Nov '11

21 Nov '11

> Hello, > > According to: > > http://www.boost.org/doc/libs/1_48_0/libs/graph/doc/compressed_sparse_row.h… > > [Edge search] requires linear time in the number of edges outgoing from u. > > The purpose of the CSR format is to support highly efficient computation > with minimal memory requirements at the cost of mutability and additional > time in construction. Is there a reason, then, that the adjacencies are > stored unsorted within their vertex ranges? With minimal additional time > during construction, edge access could be reduced to logarithmic time in > the number of edges outgoing from u without sacrificing any functionality > elsewhere that I can determine. > > Can somebody explain this design decision to me? If there is no > explanation, does anybody have plans to adjust the representation? I would > probably be willing to contribute an adjusted representation if nobody else > has plans to do so. The edges from each vertex used to be sorted, but that was changed when linear-time graph construction was introduced. One problem is that the standard sorting routines cannot sort corresponding ranges of elements (such as edge targets and properties); also, sorting edges increases the time complexity of the graph construction algorithm. Note that the CSR constructors that do sorting, except for the in-place versions, apply stable sorts to the edges you input, so you could give it a sorted list of edges and then write a logarithmic-time search routine using out_edges(). -- Jeremiah Willcock Hi, Thanks for your response. I'm sorry to hear about the move away from sorted adjacencies. I'm not sure if this is open for discussion, but I'd like to offer my two cents. The construction cost (of sorting) is minimal, especially in sparse networks for which the compressed sparse row format is specifically targeted where it is essentially asymptotically constant-time unless the degree distribution is highly skewed. On the other hand, certain aspects of link prediction, subgraph counting, and any algorithm that requires neighbor set intersections will benefit greatly from the ordering. I actually rolled exactly the solution you suggested for my own needs. Thank you so much. Ryan Lichtenwalter

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> > Interesting. It looks like optional can be seen as a special container with > > the maximum size of 1, and then functions like clear() or empty() come as > > natural. On the other hand it can be seen as a pointer-like entity with > > value semantics, and then functions like reset() and literal nullptr come > > as natural. > > Ok, I have no strong preference between reset() or clear() for making the > optional empty. However, a explicit empty() member would be useful anyway. > class MyClass > { > optional< int > m_x; > public: > bool has_x() const { return !m_x.empty(); } > }; > With the current interface I should have written has_x() in a more obscure > way, like !!m_x or m_x.get_ptr() != NULL. > > I withdraw my suggestion to use nullptr. Function reset() would be a better > > choice. I also find reset() preferable to clear() because reset can be > > extended to accept parameters and the name does not become confusing; > > similarly to unique_ptr::reset(). > I think, providing the reset() member with construction semantic is not a good > idea because it would make imposible in-place default construction. There > should be another method that would handle construction. In another post I > suggested assign() but I'm happy if someone comes up with a better name. I managed to come up with the following interface for initializing and un-initializing. My goal was also to not introduce in-place factories. template< typename... Args > optional( tr2::in_place_t, Args &&... args ) noexcept( noexcept(T{std::forward<Args>(args)...}) ) the first parameter is a /tag/, much like std::piecewise_construct for pairs. We use it like this: tr2::optional<W> { tr2::in_place, i, str, 1, &g }; The tag indicates that we request an 'in place' initialization of W with remaining arguments.Next functions are more natural: template< typename... Args > void initialize( Args &&... args ) noexcept( noexcept(T{std::forward<Args>(args)...}) ) // for deferred initialization. void uninitialize() noexcept // so that it spells similar to 'initialize' bool is_initialized() const noexcept // as in boost Regards, &rzej

3 2

BGL CSR Format (logarithmic edge search)
by Ryan Lichtenwalter 21 Nov '11

21 Nov '11

Hello, According to: http://www.boost.org/doc/libs/1_48_0/libs/graph/doc/compressed_sparse_row.h… [Edge search] requires linear time in the number of edges outgoing from u. The purpose of the CSR format is to support highly efficient computation with minimal memory requirements at the cost of mutability and additional time in construction. Is there a reason, then, that the adjacencies are stored unsorted within their vertex ranges? With minimal additional time during construction, edge access could be reduced to logarithmic time in the number of edges outgoing from u without sacrificing any functionality elsewhere that I can determine. Can somebody explain this design decision to me? If there is no explanation, does anybody have plans to adjust the representation? I would probably be willing to contribute an adjusted representation if nobody else has plans to do so. Thanks! Ryan Lichtenwalter

2 1

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> > Also, if someone likes the assignment-of-"none" syntax, in C++11 there will > > be a similar syntax available: > > std::tr2::optional<T> op = {}; > > op = {}; > Wouldn't that be confusing with creating a filled optional with the value > constructed with empty initialization list? If there is assignment-of-none > syntax, it should probably be more explicit, pretty much like the current > "none" keyword. I see your point. But note that this confusing syntax will still be available (and is available today on compilers that support the new initialization syntax) even if we have "none" keyword. This is just the new way of requesting value-initialization (default constructor). Personally, I have doubts about introducing entity "none". There would be too many ways of indicating the null-state for different types. You could look at nullptr as a special pointer with special value; but you could also think of it as a keyword for indicating null-state: a stet of not having any meaningful value. Pointers represent addresses: they can either represent a valid address or not-an-address. Now for optionals we will have none for not-a-value, even though it is almost the same concept. I was thinking also about null_value or nullval. But they appear even more confusing than an already familiar "none". I am not English speaker, so I cannot be positive about it, but does "none" fit logically into the context? Is "nothing" or "naught" more suitable, gramatically? Regards, &rzej

1 0

Re: [boost] [local] Review (and resignation from review assistant)
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> > - What is your evaluation of the design? > The library is very well designed. The function declaration syntax looks a little foreign at first, but it is very easy to get used to. Furthermore, error messages are usually able to point you to what you did wrong. The fact that you can write the body of the function in plain C++ code is a major advantage of this library. Some have referred to Boost.Bind, Boost.Lambda and Boost.Phoenix as essentially being equivalent to this library, but in none of those libraries can you express the body of your function in plain C++; one advantage of this is that errors in your code result in normal C++ error messages rather than cryptic error messages. Lorenzo, given this comment by Greg, I do have one more suggestion for documentation (or did someone already say it?). Given the heated discussion of whether Boost.Bind, Boost.Lambda and Boost.Phoenix are sufficient to render Boost.Local unnecessary, perhaps it would be worth to provide a comparison of how my code (not too trivial, and not too complex) would look in either case. For instance: With C++11 lambdas: for_each( vec.begin(), vec.end(), []( std::string & n ){ if(n.empty()) n = "n/a";} ); With Boost.Lambda + Boost.Bind: for_each( vec.begin(), vec.end(), if_then(boost::bind(&std::string::empty, _1), _1 = "n/a") ); With Phoenix: using boost::phoenix::arg_names::arg1; using boost::phoenix::if_; using boost::phoenix::bind; // right? for_each( vec.begin(), vec.end(), if_(bind(&std::string::empty, arg1)) [ arg1 = "n/a" ] ); With Boost.Local (Boost.Closure): BOOST_CLOSURE_PARAMS( std::string & n ) { if( n.empty() ) n = "n/a"; }BOOST_CLOSURE_NAME(replace_empties); for_each( vec.begin(), vec.end(), replace_empties ); Ok, I am not sure if there are no better ways to write it in each variant, and I may be biased. I also didn't try to compile the examples. But it should give the potential users an overview of options they have. Regards, &rzej

4 4

Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 21 Nov '11

21 Nov '11

Hi, It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? No response to tickets from the past 3 years. What's the procedure in this case? https://svn.boost.org/trac/boost/ticket/2492 https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… Greetings, -- Olaf

1 3

Re: [boost] Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
by Andrzej Krzemienski 21 Nov '11

21 Nov '11

> Do you have any preference? > FUNCTION or CLOSURE? > And also a), b1), b2), c) or d)? > (Or something else...) Hi Lorenzo, Now that I have better understood your library, my personal preference goes towards "closure". The reason for that is: 1. "Closure" better reflects the nature of your library: you provide a tool for defining closures: something more than functions, and something less than lambda expressions. 2. This may make the learning of the library easier. If I know I am dealing with closures I already expect binding functionality; there will be less questions like "what is this 'bind' and what does it actually do?" 3. It may be a marketing bonus "closure" sounds (IMO) more attractive than "function". How about Boost.Closure library? "Local" may not even be necessary, because "closure" somehow implies locality. (you do not need a global closure, because global function will do). Regards, &rzej

3 6

Fw: [asio] multicast.
by John Maddock 21 Nov '11

21 Nov '11

Message forwarded from original sender: ~~~~~ Hi I am trying to join multicast group via _VPN_, this means that I cannot see listen-address in ipconfig actually Could I please me explain how should I connect in this case? I am using multicast-reciever sample. http://www.boost.org/doc/libs/1_41_0/doc/html/boost_asio/example/multicast/… with port 9023, listen 172.20.200.42, multicast 239.192.112.3 #include <iostream> #include <string> #include <boost/asio.hpp> #include "boost/bind.hpp" const short multicast_port = 9023; class receiver { public: receiver(boost::asio::io_service& io_service, const boost::asio::ip::address& listen_address, const boost::asio::ip::address& multicast_address) : socket_(io_service) { try{ // Create the socket so that multiple may be bound to the same address. boost::asio::ip::udp::endpoint listen_endpoint( boost::asio::ip::address::from_string("0.0.0.0"), multicast_port); //boost::asio::ip::udp::endpoint listen_endpoint( // listen_address, multicast_port);//if I use listen_address instead of 0.0.0.0, there is an error in socket_.bind(listen_endpoint); socket_.open(listen_endpoint.protocol()); socket_.set_option(boost::asio::ip::udp::socket::reuse_address(true)); socket_.bind(listen_endpoint); // Join the multicast group. socket_.set_option( boost::asio::ip::multicast::join_group(multicast_address)); socket_.async_receive_from( boost::asio::buffer(data_, max_length), sender_endpoint_, boost::bind(&receiver::handle_receive_from, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); } catch (std::exception& e) { std::cerr << "Exception: " << e.what() << "\n"; } } void handle_receive_from(const boost::system::error_code& error, size_t bytes_recvd) { if (!error) { std::cout.write(data_, bytes_recvd); std::cout << std::endl; socket_.async_receive_from( boost::asio::buffer(data_, max_length), sender_endpoint_, boost::bind(&receiver::handle_receive_from, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); } } private: boost::asio::ip::udp::socket socket_; boost::asio::ip::udp::endpoint sender_endpoint_; enum { max_length = 1024 }; char data_[max_length]; }; int main(int argc, char* argv[]) { try { std::string list = "172.20.200.42"; std::string mt = "239.192.112.3"; boost::asio::io_service io_service; receiver r(io_service, boost::asio::ip::address::from_string(list), boost::asio::ip::address::from_string(mt)); io_service.run(); } catch (std::exception& e) { std::cerr << "Exception: " << e.what() << "\n"; } return 0; } //===================================== But with native c++ I can obtain data: #include <winsock2.h> #include <Ws2tcpip.h> #include <mswsock.h> #include <stdio.h> #include <stdlib.h> #include <iostream> using namespace std; #pragma comment(lib, "Ws2_32.lib") int main(){ WSAData data; WSAStartup( MAKEWORD( 2, 2 ), &data ); int sd = socket(AF_INET,SOCK_DGRAM,IPPROTO_UDP); sockaddr_in Sender; int SenderAddrSize = sizeof( Sender ); struct sockaddr_in binda; char *arg1 = new char[100]; char *arg2 = new char[100]; char *arg3 = new char[100]; arg1 = "239.192.112.3"; arg2 = "172.20.200.42"; arg3 = "9023"; binda.sin_family = AF_INET; binda.sin_port = htons( atoi(arg3)); binda.sin_addr.s_addr = htonl(INADDR_ANY); bind(sd,(struct sockaddr*)&binda, sizeof(binda)); struct ip_mreq_source imr; imr.imr_multiaddr.s_addr = inet_addr(arg1); imr.imr_sourceaddr.s_addr = inet_addr(arg2); imr.imr_interface.s_addr = INADDR_ANY; setsockopt(sd, IPPROTO_IP, IP_ADD_SOURCE_MEMBERSHIP, (char *) &imr, sizeof(imr)); char buf[65536]; while(1) { int res=recvfrom(sd,(char*)buf,sizeof(buf),0, (SOCKADDR *)& Sender, &SenderAddrSize); printf(buf); } //WORKS } //===================================== I cannot realize what is the difference in these two samples, Could you please tell me in which way should I use boost library to obtain data in this case? Thanks in advance, -- С уважением, Василий.

1 0

[local] Review (and resignation from review assistant)
by Gregory Crosswhite 21 Nov '11

21 Nov '11

Hey everyone, The discussion on the mailing list has caused me to realize that I have sufficient passion for the Local library that it is difficult for me to stay neutral, so I will be recusing myself from my position as Review Assistant for this library. (I have learned that should I decide to help out again in the future in this role for another review, I will make sure that it is for a library that I don't feel strongly about either way!) On the other hand, this means that there is no longer any reason not to post a review of this library. I have been a fan of this library for a long time because for me it solved the problem of having a nice way to write (pseudo-)closures in C++03 without having to write and maintain a lot of pointless boilerplate code, and without having to use a completely foreign syntax that I could never seem to get to work. Here is my review of it. > - What is your evaluation of the design? The library is very well designed. The function declaration syntax looks a little foreign at first, but it is very easy to get used to. Furthermore, error messages are usually able to point you to what you did wrong. The fact that you can write the body of the function in plain C++ code is a major advantage of this library. Some have referred to Boost.Bind, Boost.Lambda and Boost.Phoenix as essentially being equivalent to this library, but in none of those libraries can you express the body of your function in plain C++; one advantage of this is that errors in your code result in normal C++ error messages rather than cryptic error messages. It is also clear reading through the documentation that Lorenzo has put a great deal of thought into possible use cases of his library; there are a great number of features which most users might never need to use but which are available for those times when they are completely necessary --- such as explicitly providing types of bound parameters, and marking functions inline --- and they are provided in such a way that when they aren't needed they introduce no additional overhead to the syntax. > - What is your evaluation of the implementation? I am not familiar enough with preprocessor programming to be able to make a fully qualified statement on this. However, it looks reasonable based on the Implementation appendix. The virtual function call is a shame as, if I recall correctly, it can make Boost.Local slower than Boost.Phoenix when the compiler is not smart enough to optimize it into a direct call, but Lorenzo has put so much time and expertise into the design of this library that I doubt it is possible to improve on this while maintaining compatibility with C++03. For me this part of the overhead is not a big deal because I primarily have been using Boost.Local in test suites where the difference in performance does not matter. > - What is your evaluation of the documentation? The documentation is some of the best well written I have seen for a Boost library. It does a good job both explaining how the library works, providing a reference for remembering how the syntax works, and explaining why the library was designed the way that it does. As I have told Lorenzo in a separate e-mail, I do have a minor criticism of the Tutorial section: the ordering of the first four sections is probably not what typical user reading it the first time would want because it puts the most important and essential feature, variable binding, after two features, default and empty argument features, which are nice to have but are not likely to be needed in typical usage, especially considering that a first-time user is most likely just looking for a convenient way to create a simple (pseudo-)closure in C++03. Thus, I suggest the following ordering: "Local Functions" "Variable Binding" "Default Parameters" "Empty Parameters" This way a typical user, who will only care about writing a function that binds a few local variables, will be able to get started immediately after reading the second section rather than first having to wade through two sections describing features that they are unlikely to care about right away. The rationale for putting "Default Parameters" before "Empty Parameters" is that a typical user is very unlikely to need to know how to call the macro with no arguments because there are few use cases where a typical user won't want to bind *anything* from the local environment (since most of the time this means that they won't be thinking in terms of local functions in the first place), so they are less likely to care about how to do this than they are about how to specify default parameters. > - What is your evaluation of the potential usefulness of the library? This library is very useful for people who want to use much of the functionality of C++11 lambdas on C++03 compilers, as I can say from personal experience in using it. As I have said before, the existence of Boost.Bind, Boost.Lambda and Boost.Phoenix do not reduce the utility of this library. They do have a large advantage over Boost.Local of being succinct, which is why I often prefer them over Boost.Local when it is easy to do so. However, because they require to you learn completely new syntax for *all* of the code in the function body, and because they make use of heavy metatemplate programming that results in absolutely horrendous error message that do not give you a clue where they are wrong, for anything non-trivial Boost.Local is hands-down *far* easier to use because you can use plain C++ statement syntax which results in plain C++ error message when you get something wrong. Put another way, Boost.Bind, Boost.Lambda and Boost.Phoenix are complementary to rather than competitors of Boost.Local. > - Did you try to use the library? With what compiler? Did you have any > problems? I have used the library extensively in my own codes, though most often in test suites. I have used them on OSX with GCC 4.2, and on Linux with (if I recall correctly) GCC 4.3 and 4.4. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I have become accustomed to using the library on a regular basis and hence my evaluation is written based on my personal experience with it. > Please state clearly whether you think this library should be accepted as a Boost library. Definite yes. Cheers, Greg

2 1

[interprocess] Named types ( mutexes, semaphores etc.) and Windows 7
by Edward Diener 20 Nov '11

20 Nov '11

Under Windows 7 fior named types to be global, the name of the type needs to be prefixed by the string "Global\" Is this being done in the interprocess library for Windows 7 ?

2 1

[fusion] view gcc 4.6
by Karsten Ahnert 20 Nov '11

20 Nov '11

Hi, the following code does not compile with gcc 4.6.1: #include <boost/fusion/view.hpp> int main( int argc , char ** argv ) { return 0; } It produces errors like this: $> g++-4.6 -I$BOOST_ROOT test_fusion_view.cpp ... ... In file included from /home/karsten/boost/boost_1_47_0/boost/preprocessor/iteration/detail/iter/forward1.hpp:92:0, from /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/detail/nview_impl.hpp:40, from /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/nview.hpp:105, from /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview.hpp:12, from /home/karsten/boost/boost_1_47_0/boost/fusion/view.hpp:13, from test_fusion_view.cpp:1: /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/detail/nview_impl.hpp:55:57: warning: overflow in implicit constant conversion [-Woverflow] /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/detail/nview_impl.hpp:55:57: error: overflow in constant expression [-fpermissive] /home/karsten/boost/boost_1_47_0/boost/fusion/view/nview/detail/nview_impl.hpp:55:57: note: in template argument for type ‘int’ Any Ideas? I think the code should compile sincde fusion/view.hpp is a forwarding for the views...

4 6

Reminder! Boost.Local Review officially ends Saturday, Nov 19, 2011
by Jeffrey Lee Hellrung, Jr. 20 Nov '11

20 Nov '11

Just a friendly reminder that the ongoing Boost.Local review is officially set to end tomorrow (Saturday), Nov 19, 2011. Please let me know if you plan on reviewing the library but need more time, possibly into early next week, and I'll either formally extend the review period (subject to the Review Wizards' approval) or simply informally allow late submissions. Copied below is the original review announcement: ---------------- Hi all, It is time! The review of Lorenzo Caminiti's proposed Boost.Local library begins tomorrow, ***November 10, 2011***, and ends on ***November 19, 2011***. Boost.Local implements local functions, local blocks, and local exits for the C++ programming language. It allows one to define a function at any declarative scope, including function scope; bind variables from the enclosing scope; and pass this function to templated STL-style algorithms. Please see the Introduction of the documentation for a longer but still brief overview. -------- The code and documentation are available from the Boost sandbox ( https://svn.boost.org/svn/boost/sandbox/) https://svn.boost.org/svn/boost/sandbox/local/ [everything] https://svn.boost.org/svn/boost/sandbox/local/boost/ [code] https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.htm… -------- Please state clearly whether you think this library should be accepted as a Boost library. Other questions you may want to consider: - 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? Please also consider the following issues and proposals specific to Boost.Local. Your opinion is welcome on any or all of these. - Boost.Local's local exits provide the same functionality (and then some) as Boost.ScopeExit. Does this duplication of functionality need to be dealt with, and if so, how? - Lorenzo is proposing to add boost::local::function:: overload to Boost.Function as boost::function::overload. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… -------- Lastly, please note that Boost.Local has included a copy of the Variadic Macro Data (VMD) library in boost/detail/preprocessor/variadic_macro_data. Since then, VMD has been modified and integrated into Boost.Preprocessor. After the review has concluded, Lorenzo will remove this local copy of the VMD library and replace its usage within Boost.Local with the Boost.Preprocessor variadic extensions. -------- Thanks in advance to all who participate in the review discussion; I'm looking forward to it! - Jeffrey Hellrung (Review Manager) - Gregory Crosswhite (Review Assistant)

3 2

Review of Local Exits
by Alexander Nasonov 20 Nov '11

20 Nov '11

This is not a full review of the proposed Boost.Local library, I've reviewed only Local Exits and a potential merge with Boost.ScopeExit. I vote NOT to merge Local Exits with Boost.ScopeExit for the following reasons: - Local Exits feature gives two different interfaces ("variadic" and "sequencing"). In my opinion, it should only document C++0X interface and have a section called something like "What if I don't have a C++0X compliant compiler?" where it will explain an alternative interface for a transitional period. Some compilers already support enough C++0X features to let you develop a "perfect" interface. - Binding of variables should be modeled after lambda captures. This means no this_ and no void. I really like void and I'd added it if Lorenzo came up with the idea at the time when Boost.ScopeExit was still in development. - For the same reason, const bind& and bind& should be removed from the interface. Regards, Alex

3 4

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 20 Nov '11

20 Nov '11

> > * Use nullptr instead of boost::none? - this will make some uses of > > optional pointers harder, but will make usage more clear in other cases. > > I don't think nullptr is a good choice here because of the complications you > mentioned. Actually, I would prefer traditional clear() and empty() methods > for clearing and testing for value presence. The operator safe_bool() and > operator!() may also be present in the interface for brevity in conditional > expressions. Interesting. It looks like optional can be seen as a special container with the maximum size of 1, and then functions like clear() or empty() come as natural. On the other hand it can be seen as a pointer-like entity with value semantics, and then functions like reset() and literal nullptr come as natural. I withdraw my suggestion to use nullptr. Function reset() would be a better choice. I also find reset() preferable to clear() because reset can be extended to accept parameters and the name does not become confusing; similarly to unique_ptr::reset(). Also, if someone likes the assignment-of-"none" syntax, in C++11 there will be a similar syntax available: std::tr2::optional<T> op = {}; op = {}; Interestingly, boost::optional did have a reset function (now deprecated) which was replaced with boost::none assignment. I wonder what was the reason for this replacement. Regards, &rzej

2 2

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 20 Nov '11

20 Nov '11

> > * Conversion explicit conversion to bool should be declared as explicit. > > Doesn't an explicit conversion disallows to use it in a conditional > expression as in > if(opt) {} I believe that the primary motivation for the explicit conversion operators was to provide a simpler alternative for safe-bool idiom, and address cases like this one. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf > > * Should exception safety guarantees for assignment operations be enforced? > > In boost::optional they only provide a basic guarantee. > > One option is to provide strong guarantee for types T which implement > > operator= with strong guarantee, and give basic guarantee for other cases > > Other option (not sure if it is possible) is to provide strong guarantee > > for all cases at the cost of run-time performance (heap allocation). > Provide the same exception guaranties as the T assignment seems the more > reasonable. My apologies, I wrote this in a hurry an didn't make myself clear. There are three cases to consider (leaving move assignment and no-throw copyable types aside): 1. Our stored type T provides a strong assignment - the choice is obvious: optional<T>'s assignment is also strong 2. T has "basic" assignment - the natural choice is to provide also a basic guarantee for optional<T>'s assignment. 3. T is neither copyable nor moveable -- it is like a scope guard, or boost::scoped_ptr. In this case optional<T> still provides assignment by making a "pseudo destructor call" followed by a call to placement new. -- but this gives only basic guarantee. The question is if for this third variant we should be happy with only basic guarantee or to use a trick boost::variant is using with auxiliary heap-allocated object? (I do not even know if this is applicable though). > > template< typename ... Args> > > optional( Args&& ...args ); > I like them. > > The constructor will clash with another optional constructor: > > optional<T>::optional( bool cond, const T& val ); > > I don't understand why. Currently boost::optional provides this constructor: optional<T>::optional( bool cond, const T& val ); If cond is true the optional is initialized with object val, otherwise it is uninitialized. Now suppose I have a following type: struct MyType { bool on; int m1; int m2; MyType( bool on, MyType const& rhs ) :on{on}, m1{rhs.m1}, m2{rhs.m2} {} }; MyType mt { true, 1, 2 }; boost::optional<MyType> o1{ true, mt }; // optional initialized with mt (copy ctor used) boost::optional<MyType> o2{ boost::in_place(true, mt) }; // uses 2-arg ctor But if std::tr2::optional has "variadic" constructor: std::tr2::optional<MyType> mt{ true, mt }; // uses 2-arg ctor Regards, &rzej

4 5

Boost 1.48.0 Release Notice
by Beman Dawes 19 Nov '11

19 Nov '11

Release 1.48.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 new libraries: Container, Locale, Move. Updated libraries include: Asio, Chrono, Config, Fusion, Geometry, Graph, Interprocess, Intrusive, Lexical cast, Math, MSM, Numeric Conversion, Proto, Regex, Spirit, TypeTraits, Unordered, Wave, and more. For details, including download links, see http://www.boost.org/users/news/version_1_48_0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.48.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 Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

5 5

[ScopeExit] C++0X support
by Alexander Nasonov 19 Nov '11

19 Nov '11

I committed lambda-based implementation of ScopeExit to trunk today. It should be backward compatible with the previous implementation. In addition, if you've fully switched to C++0x, you can use = and & from C++0x and use ; instead of BOOST_SCOPE_EXIT_END. For instance: BOOST_SCOPE_EXIT((&)) {}; Alex

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 19 Nov '11

19 Nov '11

> Do we even want the third variant? That is, do we want to support tr2::optional of something that is neither copyable nor movable? > My gut instinct says no, that's unintuitive. boost::optional can be used for many purposes. One of these (and I had to use optional like that) is to make classes that provide RAII-like interface (noncopyable, nonmoveable) usable in contexts where I need to use two-phase initialization or to release the resource before the end of the scope (subject to some runtime condition) -- all that in order to have a resource acquired for as short span of time as possible. I would be forced to do that for std::lock_guard if the library did not provide a second template std::unique_lock. But not every library provides two interfaces for almost the same thing, and this is arguably an unnecessary redundancy for an interface. optional<RAII> as described above is a generic tool for transforming types that implement 'scoped ownership' into types that implement 'unique ownership' of a resource. Given this optional<RAII> pattern I can already re-set my object to a different resource: template< typename ...Args > void reset( boost::optional<RAII> & o, Args &&... args ) { o = boost::none; o = in_place( std::forward<Args>(args)... ); } Or perhaps boost::optional already implements this 'strange' assignment. I didn't have a need to reset a handle to a different resource. But you can see how (arguably) natural it becomes for optional<RAII>. Regards, &rzej

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 19 Nov '11

19 Nov '11

> Do we even want the third variant? That is, do we want to support tr2::optional of something that is neither copyable nor movable? > My gut instinct says no, that's unintuitive. boost::optional can be used for many purposes. One of these (and I had to use optional like that) is to make classes that provide RAII-like interface (noncopyable, nonmoveable) usable in contexts where I need to use two-phase initialization or to release the resource before the end of the scope (subject to some runtime condition) -- all that in order to have a resource acquired for as short span of time as possible. I would be forced to do that for std::lock_guard if the library did not provide a second template std::unique_lock. But not every library provides two interfaces for almost the same thing, and this is arguably an unnecessary redundancy for an interface. optional<RAII> as described above is a generic tool for transforming types that implement 'scoped ownership' into types that implement 'unique ownership' of a resource. Given this optional<RAII> pattern I can already re-set my object to a different resource: template< typename ...Args > void reset( boost::optional<RAII> & o, Args &&... args ) { o = boost::none; o = in_place( std::forward<Args>(args)... ); } Or perhaps boost::optional already implements this 'strange' assignment. I didn't have a need to reset a handle to a different resource. But you can see how (arguably) natural it becomes for optional<RAII>. Regards, &rzej

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 19 Nov '11

19 Nov '11

> This is more of an addition to your list, but I think adding > the | operator for getting the optional value or a default value would be nice. > For example: > optional<double> safe_sqrt(double x) > { > if (x < 0) return none; > else return sqrt(x); > } > double x = safe_sqrt(4) | 0; //x = 4 > double y = safe_sqrt(-1) | 0; //y = 0 > I dont know if this is possible for tr2, but would be really nice > addition in the future. Especially, since a lot of times i just > want a default value if the optional value doesn't exist. Note, that boost::optional already provides a functionality for that, although with a slightly more verbose syntax: double x = safe_sqrt(4).get_value_or(0); std::tr2::optional would also provide this functionality. If this is only about shorthand notation, this item would be controversial. bitwise-or is a better choice that logical-or but it might turn out too confusing and disturbing for programmers that do not want to learn what overloaded operators mean for every type they use. What I mean to say is that liberal use of overloaded operators is a general controversy. Regards, &rzej

1 0

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 19 Nov '11

19 Nov '11

> > 3. T is neither copyable nor moveable -- it is like a scope guard, or > > boost::scoped_ptr. In this case optional<T> still provides assignment by > > making a "pseudo destructor call" followed by a call to placement new. -- > > but this gives only basic guarantee. > The guarantee is strong if the placement delete/new are marked > noexcept, isn't it? What I meant by "a >>pseudo destructor call<< followed by a call to placement new." is a call to destructor w/o releasing the memory and then a call to constructor w/o allocating memory: ob.~T(); new (&ob) T( std::forward<Args>(args)... ); This trick will provide a strong guarantee if destructor and the constructor are nothrow. While destructors usually are non-throwing, it is rather unlikely that constructors would not throw: it is the constructors that we often expect to throw in case of initialization failure. Regards, &rzej

1 0

[inteprocess] Using named_mutex on Windows 7
by Edward Diener 19 Nov '11

19 Nov '11

I wrote a program more than 3 years ago where I used boost::interprocess_named_mutex to protect more than one instance of the same process from running the same sequence of code at the same time. The program appears to run fine under Windows XP and Windows Vista but occasionally locks up waiting for the locked mutex to unlock on Windows 7. The code looks like this: ------------------------------------------------------------------- boost::interprocess::named_mutex cmutex(boost::interprocess::open_or_create_t(),"MyMutexName"); { boost::interprocess::scoped_lock<boost::interprocess::named_mutex> cscoped(cmutex); // Code here which must be run one at a time. } ------------------------------------------------------------------- Under Windows 7 the code occasionally hangs on the scoped_lock instantiation, which of course I can not have. I notice there is a file in the temporary directory ( TMP or TEMP environment variable ) which is being used by interprocess, and after that file is manually deleted, the program no longer hangs on the scoped_lock instantiation. Is there a reason for this problem on Windows 7 ? I know that Windows 7 has global and local named mutexes and only by prefacing a named mutex name with global\ is the mutex truly global. I do not know if this is causing the problem on Windows 7. It does seem as if something in the file in the temporary directory is telling inteprocess that "MyMutexName" is still locked when the hangup occurs, but I would have expected that when acoped_lock goes out of scope, it handles resetting that file to the correct state. I wonder if this has something to do with UAC/file permissions in Windows 7, where the process somehow can no longer write to the file in the temporary directory afte creating it. Is this a known interprocess problem, perhaps fixed in a later release ? I wrote my code before Windows 7 even came out, recompiled it for Windows 7, but did not update the version of Boost I was using for the program ( Boost 1.35 ). Maybe I need to do that ? I would certainly be willing to do that if I knew that this was a problem with interprocess in Boost 1.35 that has subsequently been fixed in a later version of Boost.

1 0

[signals] Compiler error
by "Claas H. Köhler" 18 Nov '11

18 Nov '11

Hi everybody! When compiling boost 1.48.0 using gcc-4.6 and the "--std=c+0x" option, I get the following error message: libs/signals/src/named_slot_map.cpp: In member function ‘void boost::signals::detail::named_slot_map::disconnect(const boost::signals::detail::stored_group&)’: libs/signals/src/named_slot_map.cpp:99:48: error: conversion from ‘std::list<boost::signals::detail::connection_slot_pair>::const_iterator {aka std::_List_const_iterator<boost::signals::detail::connection_slot_pair>}’ to non-scalar type ‘boost::signals::detail::slot_pair_iterator {aka std::_List_iterator<boost::signals::detail::connection_slot_pair>}’ requested The reason seems to be that std::map's erase function expects a std::map::iterator in the old standard (according to cplusplus.com) while c++11 seemingly requires a std::map::const_iterator as argument (see section 23.4.4.1). Thus replacing line 105 OLD groups.erase(group); NEW groups.erase( static_cast<const_group_iterator>(group) ); and line 128 OLD if (empty(g)) groups.erase(g++); NEW if (empty(g)) groups.erase( static_cast<const_group_iterator>(g++); solves the problem for me. Is it intended to have all boost libraries conforming with C++11? Regards Claas

1 0

date_time using CPU performance counter
by Kenneth Porter 18 Nov '11

18 Nov '11

I need high precision under Windows XP but don't need long-term date accuracy. To that end, I think it would be useful to have a microsec_clock implemented in terms of the Windows QueryPerformanceCounter API (which wraps a CPU register query) instead of the GetSystemTimeAsFileTime API (which is only good to 15 msecs and almost guarantees a context switch). Has anyone attempted this? How hard is it to code up a new clock source to fit into the Boost date_time design?

3 3

multi_array and concept check
by Ivan Sorokin 17 Nov '11

17 Nov '11

Hello! Currently it is not possible to pass shape() of one multi_array into constuctor of another: boost::multi_array<float, 2> a; boost::multi_array<float, 2> b(a.shape()); This is because shape() returns size_t const* and multi_array check in constructor that ExtendList satisfy CollectionConcept. size_t const* don't satisfy this concept. I'm going to allow constructor of multi_array to get both size_t const* and size_t const[]. So I'm going to replace extents.begin() with boost::begin(extents). What should I do with concept check?

1 0

Boost.Local Review
by Pierre Morcello 17 Nov '11

17 Nov '11

Hello Boost community, Here is my review of the local function library. - What is your evaluation of the design? The design is clear. Several iterations were done already to come to what it is today. Of course no one is particularly fond of macros, but a huge work was done to reduce the potential problems and on the other hand the library can really help a lot. - What is your evaluation of the implementation? I did not get too much into the current implementation. I dug it almost one year ago, but there were changes since then. The implementation is correct given the features of the library (use of 'this', functor,, name,...). If there were less features, then some optimisations would have been possible (example : not use a virtual function, not use a functor). But the library would in that case have fewer cases of use. I know how the first verion of Lorenzo worked but I did not check the latest. Given the current features, I don't see how to do even better than what Lorenzo did. So I am happy with the implementation. - What is your evaluation of the documentation? I really appreciate the detailled documentation. On a 'merchandising note', the first page is too big. I think this could 'afraid' some new readers. Introduction + an 8-line motivating example should be enough to appeal (or not) the new reader. I am happy to review a submitted library with a complete documentation (that does not always happen). - What is your evaluation of the potential usefulness of the library? This library is filling a few strong needs. Several users including myself needed local function and const block. I am lazy when it comes to functors, I also find this library is pretty nice to make them quick. C++11 will on that last part change it , but const block are a must have in my opinion which are not available in C++11. The local function can greatly reduce the presence of internal functions in ".h", and thus make the interfaces much better in some cases. - Did you try to use the library? With what compiler? Did you have any problems? I use regularly this library on VC9, but mostly for local function. As I don't try to push the limits, I did not come into problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have followed Lorenzo work since his proposition. At the beginning I followed it much more closely, but right now I dont' have the time to redo an in depth study. I use a previous version of Lorenzo library regularly. So for the review, I simply had a glance. But I already read the documentation in detail several month ago. - Are you knowledgeable about the problem domain? I implemented a my own version of local functions for boost almost 2 years ago I think. - Boost.Local's local exits provide the same functionality (and then some) as Boost.ScopeExit. Does this duplication of functionality need to be dealt with, and if so, how? I think it's important to check if the author are ok with merging or not. Obviously Lorenzo is very motivated and gives great feedback on his works with boost. Just make sure this won't hurt his motivation ? Because then there are the question of maintening the libraries which is not always the easiest. I am ok if one replace the other. - Do you vote for the library? Yes, I vote for its admission. I also want to add that I am amazed by the overall results in term of quality that Lorenzo was able to get with this library. Lorenzo is constently gathering the users needs and updating his library in that way. Like a marathonian. Very inspiring! Best regards, Pierre Morcello -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Local-Review-tp4078276p4078276.html Sent from the Boost - Dev mailing list archive at Nabble.com.

4 5

[context] update
by Oliver Kowalke 17 Nov '11

17 Nov '11

Hi, a new updated version is available. src: http://github.com/olk/boost.context docu: http://ok73.ok.funpic.de/boost/libs/context/doc/html/index.html next step mini-review? so long, Oliver

1 0

Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
by Jeffrey Lee Hellrung, Jr. 17 Nov '11

17 Nov '11

Hi all, It is time! The review of Lorenzo Caminiti's proposed Boost.Local library begins tomorrow, ***November 10, 2011***, and ends on ***November 19, 2011***. Boost.Local implements local functions, local blocks, and local exits for the C++ programming language. It allows one to define a function at any declarative scope, including function scope; bind variables from the enclosing scope; and pass this function to templated STL-style algorithms. Please see the Introduction of the documentation for a longer but still brief overview. -------- The code and documentation are available from the Boost sandbox ( https://svn.boost.org/svn/boost/sandbox/) https://svn.boost.org/svn/boost/sandbox/local/ [everything] https://svn.boost.org/svn/boost/sandbox/local/boost/ [code] https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.htm… -------- Please state clearly whether you think this library should be accepted as a Boost library. Other questions you may want to consider: - 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? Please also consider the following issues and proposals specific to Boost.Local. Your opinion is welcome on any or all of these. - Boost.Local's local exits provide the same functionality (and then some) as Boost.ScopeExit. Does this duplication of functionality need to be dealt with, and if so, how? - Lorenzo is proposing to add boost::local::function::overload to Boost.Function as boost::function::overload. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… -------- Lastly, please note that Boost.Local has included a copy of the Variadic Macro Data (VMD) library in boost/detail/preprocessor/variadic_macro_data. Since then, VMD has been modified and integrated into Boost.Preprocessor. After the review has concluded, Lorenzo will remove this local copy of the VMD library and replace its usage within Boost.Local with the Boost.Preprocessor variadic extensions. -------- Thanks in advance to all who participate in the review discussion; I'm looking forward to it! - Jeffrey Hellrung (Review Manager) - Gregory Crosswhite (Review Assistant)

7 21

Alternative implementation for BOOST_PP_VARIADIC_SIZE
by Gennadiy Rozental 17 Nov '11

17 Nov '11

Hi, Current implementation of subject macro have a very serious shortcoming - it does not work for empty __VA_ARGS__. After googling around a bit for some ideas I came up with the following alternative: #include <boost/preprocessor/arithmetic/mul.hpp> #include <boost/preprocessor/arithmetic/sub.hpp> #include <boost/preprocessor/punctuation/comma.hpp> #define MY_VA_ARG_N( \ _1, _2, _3, _4, _5, _6, _7, _8, _9,_10, \ _11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \ _21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \ _31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \ _41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \ _51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \ _61,_62,_63, N, ...) N #define MY_VA_RSEQ_N() \ 63,62,61,60, \ 59,58,57,56,55,54,53,52,51,50, \ 49,48,47,46,45,44,43,42,41,40, \ 39,38,37,36,35,34,33,32,31,30, \ 29,28,27,26,25,24,23,22,21,20, \ 19,18,17,16,15,14,13,12,11,10, \ 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 #define MY_DO_VA_NARG2(...) MY_VA_ARG_N __VA_ARGS__ #define MY_DO_VA_NARG(...) MY_DO_VA_NARG2(( __VA_ARGS__ )) // this version produces incorrect value (1) for empty __VA_ARGS__ #define MY_VA_NARG_(...) MY_DO_VA_NARG(__VA_ARGS__, MY_VA_RSEQ_N()) // this version fixes it #define MY_VA_NARG(...) BOOST_PP_SUB( BOOST_PP_MUL( MY_VA_NARG_( __VA_ARGS__ ), 2 ), MY_VA_NARG_( BOOST_PP_COMMA __VA_ARGS__ () ) ) This version work for zero sized __VA_ARGS__ and also works for MSVC-9,10 , gcc-4.1 gcc 3.2 (did not test with other compilers). Does it make sense to improve trunk version? Regards, Gennadiy

7 39

[1.48.0] Can't build any PDF docs
by John Maddock 16 Nov '11

16 Nov '11

I'm trying to build the PDF docs for 1.48 but all attempts to build PDF's on both Trunk and release branches fails with errors such as: bjam pdf M:/data/boost/trunk/tools/build/v2/tools\boostbook.jam:649: in object(boostbook-generator)(a)49.run from module object(boostbook-generator)@49 error: Cannot build documentation type 'pdf' M:/data/boost/trunk/tools/build/v2/build\generators.jam:1004: in try-one-generator-really from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1066: in try-one-generator from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1282: in construct-really from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1366: in generators.construct from module generators M:/data/boost/trunk/tools/build/v2/build\targets.jam:1495: in construct from module object(typed-target)@776 M:/data/boost/trunk/tools/build/v2/build\targets.jam:1297: in object(typed-target)(a)776.generate from module object(typed-target)@776 M:/data/boost/trunk/tools/build/v2/build\targets.jam:732: in generate-really from module object(main-target)@782 M:/data/boost/trunk/tools/build/v2/build\targets.jam:704: in object(main-target)(a)782.generate from module object(main-target)@782 M:/data/boost/trunk/tools/build/v2/build\targets.jam:258: in object(project-target)(a)772.generate from module object(project-target)@772 M:/data/boost/trunk/tools/build/v2\build-system.jam:736: in load from module build-system M:\data\boost\trunk\tools\build\v2/kernel\modules.jam:283: in import from module modules M:\data\boost\trunk\tools\build\v2\kernel\bootstrap.jam:142: in boost-build from module M:\data\boost\trunk\boost-build.jam:17: in module scope from module Nothing has changed in my user-config.jam, and I've updated to the latest bjam executable. Any ideas on what broke? Thanks, John.

2 3

Boost.Random.uniform_01 gives different number sequence in Boost 1.37 and Boost 1.45
by Martin.Sovik＠Emerson.com 16 Nov '11

16 Nov '11

Hi. It seems that uniform_01 generates different number sequences in version 1.37 and 1.45 Is this intentional, or is it a bug? This short program #include <iostream> #include "boost/random/mersenne_twister.hpp" #include "boost/random/uniform_01.hpp" int main() { boost::mt19937 random_generator(4315); boost::uniform_01< boost::mt19937, double > uniform_generator(random_generator); std::cout<<"Generating uniform distribution using Boost 1.45"<<std::endl; for (int i=0; i<10;++i) { std::cout<<uniform_generator()<<std::endl; } return 0; } Compiled with the two versions, gives the respective output: D:\dev\test_bed>uniform_dist_boost_1_37 Generating uniform distribution using Boost 1.37 0.239136 0.920749 0.889477 0.208172 0.169688 0.636659 0.78322 0.915117 0.25697 0.358218 D:\dev\\test_bed>uniform_dist_boost_1_45 Generating uniform distribution using Boost 1.45 0.306389 0.511291 0.496429 0.156168 0.910315 0.644836 0.331514 0.558632 0.723934 0.998796 As far as I can tell, Boost.mt19937 gives the same number sequence in both cases, but the output from Boost.uniform_01 differs. This topic has been briefly touched in the thread [boost] Random numbers question<154235.php> Anant Rao (2009-07-24 18:47:31) Where it seems like Rao got different numbers even between Boost 1.38 and Boost 1.39 We use Boost 1.37 in the previous release of our software, and Boost 1.45 in the current, and we have received a bug report from one of our clients that our current release has different behaviour. Is there any way to fix this, other than use the 1.37 version of Boost.uniform_01? Thanks, Martin Søvik

2 1

Re: [boost] [1.48.0] Release candidates available
by Tom Kent 16 Nov '11

16 Nov '11

> Release candidate files for 1.48.0 are available at http://boost.cowic.de/rc/ > > md5sum on the originals: > > 7dd95e71c43ddd35997d9f2346e7f567 *boost_1_48_0.7z > d1e9a7a7f532bb031a3c175d86688d95 *boost_1_48_0.tar.bz2 > 313a11e97eb56eb7efd18325354631be *boost_1_48_0.tar.gz > b08fda829eec96b4f1071ce2ea6831f5 *boost_1_48_0.zip > > 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. > > Thanks, > > --The release managers On a windows 7 - 32 bit VM, I built: msvc-8.0 msvc-8.0 - address-model=64 msvc-9.0 msvc-9.0 - address-model=64 msvc-10.0 msvc-10.0 - address-model=64 All builds were successful. I was able to smoothly link and run with the binaries on windows 7 32 or 64 (depending on the library build). Tom Kent

1 0

[program_options] Improving error text in exceptions
by Leo Goodstadt 16 Nov '11

16 Nov '11

On 15 November 2011 09:08, Vladimir Prus <vladimir(a)codesourcery.com wrote: > > Leo Goodstadt wrote: > > I would very much like to make the error messages in program_options > > exceptions more consistent and informative. > > I've looked over the error messages you have proposed, and I think it's > an overall improvement. I would appreciate patch to make this change. > Thanks! Cool. Will do that. The error messages meant for programmers I shall leave alone. This exercise is so tedious that I doubt anyone else is going to do more than tinker with the message text so I am keen to do an exhaustive job. As I mentioned, for command line messages, <option '--foo_bar' is ambiguous> seems much clearer than than <option 'foo_bar' is ambiguous>. However, it would be inappropriate to add "--" to config file and dos style options. The easiest thing would be to add a "prefix" parameter to the set_option_name() functions in errors.hpp These are called inside store() in variables_map.cpp. To add "--" or "/" prefixes as appropriate, is it sufficient to look at basic_option::original_tokens and basic_option::string_key? A) Use no prefix if original_tokens[0] is unprefixed, B) Use the parsed prefix (original_tokens[0]) if basic_option::string_key.length() = 1 C) Prefer "--" for long option names The same logic would apply to 1) exceptions thrown from cmdline::finish_option() in cmdline.cpp 2) options_description::find() (in options_description.cpp) called from store() (in variables_map.cpp) 3) options_description::find_nothrow() (in options_description.cpp) called from cmdline::run(), cmdline::finish_option(), parse_short_option(), and parse_disguised_long_option() (in cmdline.cpp) (Despite its name, find_nothrow() can throw()!) The difficult case is supporting the correct prefix for "required_option" in variables_map::notify() (variables_map.cpp). I propose that where missing options can be specified in both configuration file and on the command line, the command line should take precedence, and "--option_name" displayed in the error message. To support this, "basic_parsed_options" needs an extra prefix field, which would be set appropriately by basic_command_line_parser<charT>::run(). Does this make sense? Thanks, Leo -- Leo Goodstadt University of Oxford, UK

2 1

[1.48.0] Release candidates available
by Beman Dawes 16 Nov '11

16 Nov '11

Release candidate files for 1.48.0 are available at http://boost.cowic.de/rc/ md5sum on the originals: 7dd95e71c43ddd35997d9f2346e7f567 *boost_1_48_0.7z d1e9a7a7f532bb031a3c175d86688d95 *boost_1_48_0.tar.bz2 313a11e97eb56eb7efd18325354631be *boost_1_48_0.tar.gz b08fda829eec96b4f1071ce2ea6831f5 *boost_1_48_0.zip 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. Thanks, --The release managers

13 17

Re: [boost] Boost.Local Review - comments by Andrzej
by Andrzej Krzemienski 15 Nov '11

15 Nov '11

> > One suggestion for the future, although I am not sure how useful it would > > turn out in practice is to have something like local expression, or even > > not necessarily a local one. This would be a function whose body consists > > of a single expression. The benefit you get is that the programmer does not > > need to specify a return type for it (you can use BOOST_TYPEOF for that), > > or doesn't even have to type keyword 'return', but this may be too much off > > topic. > Can you clarify with an example? In C++11 lambdas do not require specifying the return type, provided that the body of the function is a single return statement: because it is easy to deduce the type from such single return statement. Similarly, for Boost.Local if a function body consists of a single return statement you could (I guess) provide a more simple syntax. Instead of BOOST_TYPEOF(sum) & BOOST_LOCAL_FUNCTION_PARAMS( double num, const bind factor, bind& sum ) { return sum += factor * num; } BOOST_LOCAL_FUNCTION_NAME(add); I could write: BOOST_LOCAL_EXPRESSION_PARAMS( double num, const bind factor, bind& sum ) BOOST_LOCAL_EXPRESSION_END( add, sum += factor * num ); You save me typing the return type and 'return' keyword. But now that I have written it down I do not think it is particularly useful. > I think in a nutshell the conclusion (which I will detail in the rest > of my comments below) was that Boost.Local is handy but on compilers > with C++11 lambdas you'd just use lambdas. At the same time, > Boost.Local allows you to write local functions that work also on > C++03 compilers and that have the same compile-time and run-time > performances of lambdas on C++11 compilers. So the /main/ audience > would be someone (like myself) that wants to do local function stuff > and expects lambda-like performances on C++11 but also has to deal > with C++03 compilers. There are other benefits like const& binding > which is not supported by C++11 lambdas (so how can I bind by const a > variable that has a very expensive copy constructor using C++11 > lambdas?) and improve scope exit (i.e., local exit) but these other > benefits are probably minor in the general domain (they can be very > important or even essential is a specific and narrow domain like > Contract Programming but not critical in the general case). OK Lorenzo, I am convinced. Can we trade? I will vote 'yes', and you will add a motivation section in the documentation which will stress that the primary motivation of the library is to provide a uniform (in terms of syntax) support for local functions: fast and 'native' for C++11 compilers, and acceptable (using tricks) in older compilers. The library can be used directly or be a foundation for higher level libraries like Boost.Concept. Review Managers, I am not really trading, I vote YES for the Boost.Local and just request the motivation section in the documentation. I think the situation of Boost.Local is similar to that of Boost.Move, and the latter was accepted into Boost. Also, having a library in Boost whose primary purpose is to serve as the foundation for other Boost libraries is not a precedent (I mean Boost.Proto and now Boost.Context). Regards, &rzej

3 2

Re: [boost] Boost.Local Review - comments by Andrzej
by Andrzej Krzemienski 15 Nov '11

15 Nov '11

Just one more thought. I was not participating in the design discussion for Boost.Local when it was probably a better time to mention this. So I am just mentioning it for reference. Functions that take parameters and bind existing objects are called closures: http://en.wikipedia.org/wiki/Closure_%28computer_science%29.<http://en.wikipedia.org/wiki/Closure_%28computer_science%29> This could have been an alternative name for BOOST_LOCAL_FUNCTION: BOOST_SCOPE_CLOSURE... Regards, &rzej

2 1

[1.48.0] Status?
by Beman Dawes 15 Nov '11

15 Nov '11

Are there any 1.48.0 showstoppers outstanding? We are scheduled to release right now. There are still a lot of release branch regression test failures. It is very uncomfortable to see failures for popular compilers such as VC++ 10 and GCC: accumulators (most or all compilers) assign flyweight (most or all compilers) graph ublas pool (all Windows compilers) ptr_container (most or all compilers) python spirit/repository (most or all compilers) tr1 (most or all compilers) wave (all Windows compilers) See http://beta.boost.org/development/tests/release/developer/summary.html Do we really want to release with this many failures? Worried, --Beman

12 33

[property_tree] Assign and Lua parser
by Renato Florentino Garcia 15 Nov '11

15 Nov '11

In my use of Boost Property Tree library I have coded some extensions, which are in a GitHub repository (http://github.com/renatoGarcia/boost-extensions) I would like to know if there are any interest in make any of then part of Boost Property Tree itself, probably after a suggest improvement. The more useful in my view is a Boost Assign Property Tree alike. Code: http://github.com/renatoGarcia/boost-extensions/blob/master/property_tree/i… For instance, to build in C++ code a ptree like: key1 value1 key2 { key3 12345 { key4 "value4 with spaces" } key5 value5 "" 10 "" 11 "" 12 } Instead the current: ptree pt; pt.add("key1", "value1"); ptree tmpPt1; tmpPt1.add("key3", 12345); ptree tmpPt2; tmpPt2.add("key4", "value4 with spaces"); tmpPt1.push_back(std::make_pair("", tmpPt2)); tmpPt1.add("key5", "value5"); ptree tmpPt3; tmpPt3.put_value(10); tmpPt1.push_back(std::make_pair("", tmpPt3)); ptree tmpPt4; tmpPt4.put_value(11); tmpPt1.push_back(std::make_pair("", tmpPt4)); ptree tmpPt5; tmpPt5.put_value(12); tmpPt1.push_back(std::make_pair("", tmpPt5)); pt.add_child("key2", tmpPt1); Would be a code like: ptree pt = tree() ("key1", "value1") ("key2", tree() ("key3", 12345) (tree() ("key4", "value4 with spaces")) ("key5", "value5") (10)(11)(12)); Another extension is a Lua parser, like the XML or JSON. But in this case I don't think that is desirable include it in the Boost, because of the needed of Lua libraries (at least not in a mandatory way). Code: http://github.com/renatoGarcia/boost-extensions/blob/master/property_tree/i… Regards, Renato Garcia

2 1

Boost.Local Review - comments by Andrzej
by Andrzej Krzemienski 15 Nov '11

15 Nov '11

Hi Lorenzo, I would like to provide some comments on Boost.Local. > Please state clearly whether you think this library should be accepted > as a Boost library. I am unable to give a yes/no answer. This is mostly because I am not clear who is the intended audience of the library. I explain this in detail below. I am impressed with the library documentation. It is very informative with lots of examples, benchmarks, comparisons, rationale, and layered design (overview, and then details). This is how a Boost library's documentation (and every documentation, IMO) should look like. Yet, one thing that I am missing is what practical problems (that are not already solved) this library is trying to solve. I am not saying that it doesn't solve any. I am just saying I cannot figure it out. A typical story for a Boost library is that there is a common problem that many developers face fairly often, and at some point someone decides to fix this problem comprehensively and ultimately. This is the impression that I had, for example, with Boost.Optional. When I read about it I thought "Yes! This is what I was missing for a long time". I cannot see this in Boost.Local. Perhaps I am not the intended audience of the library, but it would help me if it was clear who the audience is. (I provide examples of what I mean below.) Documentation clearly separates three parts: local functions, local scopes and local exits. Also my impression is different on the three parts. This suggests to me that they could be three separate libraries. What do they have in common? The syntax, I guess. And the fact that you declare them inside functions. But is that enough to bundle them together? Consequently, I divide my comments into three parts. LOCAL FUNCTIONS Why would I want to use it? Personally, I have one compiler that does support local classes as template parameters. All my other compilers support lambdas. So I guess local functions are not for me. So who will use them? Someone that does not have too new compiler (because they have superior - in terms of performance - alternatives: lambdas, local classes). Someone that does not have a too old compiler, because we read in the documentation that "The implementation of this library uses preprocessor and template metaprogramming (as supported by Boost.Preprocessor<http://www.boost.org/doc/libs/release/libs/preprocessor/doc/index.html>and Boost.MPL <http://www.boost.org/doc/libs/release/libs/mpl/doc/index.html>), templates with partial specializations and function pointers (similarly to Boost.Function<http://www.boost.org/doc/libs/release/doc/html/function.html>). As a consequence, this library is fairly demanding on compilers' compliance with the C++03 <http://www.open-std.org/JTC1/SC22/WG21/docs/standards>standard." Further someone who does not mind compile-time and run-time performance overhead. And someone,who prefers the new syntax to creating a functor class non-locally. I am not sure how many users that would be? The documentation mentions proposal N2511<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2511.html>, which says that even though with lambdas and local classes we already have a good tool, we still want to have a normal function syntax for local functions. Boost.LocalFunction does not enable a normal function syntax either, so it is no better an alternative than lambdas or local classes. Except for "const binding" which I find hard to appreciate. And except for compilers that don't support C++11 features, but than again, working only with the new compilers I may not be the right person to review the library. Is this supposed to provide a seamless migration of the code from compilers w/o lambdas to those that do support lambdas? I am not comfortable with the syntax: we first specify parameters, then function body and last, we specify the function name. I am not comfortable that the other Lorenzo's library (that I await impatiently) - Boost.Contract - will provide a different function syntax than Local Functions. This will render the situation where every library will require of me to learn different function declaration syntax. On the other hand, the documentation clearly says why this syntax is necessary, so I am not saying "change the syntax". I am suspicious about the local function overloading. While I can imagine writing a local function; writing a bunch of them inside another function would be likely be some error in my design. LOCAL BLOCKS Again, why would I need them? The example with assertion does not convince me. That is, I face the practical tradeoff: additional enforcement on assertions at the cost of slower build, slower execution time and less readable syntax. I will choose not to use the blocks. The only application that I can think of is a "temporary usage" while refactoring. If I work with the code where functions are 1000-line-long, I would like to divide them into blocks and check which parts reference what variables. In this case, as one of the footnotes in documentation suggests, allowing "return;" inside blocks would be a dangerous thing. But again, if I had a luxury of lambdas, I would choose lambdas for that purpose, because they allow specifying the default binding ( [&], [=] ). It looks like local blocks are only a syntax sugar over local functions. Am I right? LOCAL EXITS While exception specifications for locals blocks seam strange, I find allowing exception specifications for local exits an error. Local exits should be subject to the same restrictions as destructors (they are implemented as destructor calls anyways): you must not throw from them. And I expect the library documentation to say it explicitly. I find this "warning" missing from Boost.ScopeExit. So I suggest to disallow (if possible) specifying exceptions in local exit, and adding a section in documentation that warns against potential throws from an exit. I do not see anything against having two libraries for the same purpose. This is pretty much the same what we already have in Boost in case of state machines. But since we have two, it is useful to ask why I would choose local exit over scope exit. My answer is: 1. Local Exit allows me to specify an empty parameter list (I cannot do it with ScopeExit). - this is a practical problem I faced 2. I can bind to "this". I do not find const binding a practical advantage. Typically for short functions it is hardly a real problem that I confuse = with ==. And exits would typically be one-liners in my code. On the other hand there are reasons why I would prefer ScopeExit to LocalExit: it spells shorter. In LocalExit I have to type word 'bind' for every single parameter even though it is obvious I need to bind them all (because scope guards do not accept normal parameters). The same argument goes for blocks, obviously. I also like ScopeExit's potential to be implemented with lambdas, which might result in performance benefits, and allow the 'default binding'. On the other hand LocalExit cannot be implemented with a lambda, if not for any other reason, then due to the const binding. It is really nice that i can bind to variable of the name 'bind'; although I cannot use type 'bind' in local functions. GENERAL THOUGHTS I am really impressed with the usage of macros. It looks like thanks to Lorenzo we are reaching a new level of preprocessor programming. Who knows how far we can go. I do not think they are overused, given the difficult task. On the other hand, error messages that I encountered give me no clue on what I have typed wrong. Decsriptions in the documentation, and the rationale clearly indicates the very detailed knowledge of many C++ aspects. One suggestion for the future, although I am not sure how useful it would turn out in practice is to have something like local expression, or even not necessarily a local one. This would be a function whose body consists of a single expression. The benefit you get is that the programmer does not need to specify a return type for it (you can use BOOST_TYPEOF for that), or doesn't even have to type keyword 'return', but this may be too much off topic. Term 'C99 <http://www.open-std.org/jtc1/sc22/wg14/www/projects#9899> and later compilers' may be a bit of an overuse for C++ compilers. I suggest 'compilers supporting variadic macros'. Also, in reply to particular review questions: > What is your evaluation of the design? It is clear. Some macros are difficult to read, e.g. Function arguments first, function name second, but I guess this is a necessity given the domain. > What is your evaluation of the implementation? The impressive macro magic is beyond my cognitive capabilities > What is your evaluation of the documentation? It is very good. It meets Boost's and my personal criteria for a good documentation. > What is your evaluation of the potential usefulness of the library? > Are you knowledgeable about the problem domain? This is the part where I have problems. I am not sure about the scope and intended audience of the library. > Did you try to use the library? With what compiler? Did you have any problems? I tried to use the library (basic examples) with VC++8 and VC++10 and Boost 1.42. I found that it does not compile if I use compiler option /ZI (Debug Information Format: Program Database for Edit & Continue) on either compiler. > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent one evening on reading the documentation and playing with the basic examples. For the last remark, I believe that the criterion for accepting or rejecting a library is that if it addresses a real-life problems and if it is well designed. Boost.Local is well designed, but the intended audience and primary motivation is not clearly stated, so I find it hard to assess if the first criterion is met. All in all, Boost.Local is an impressive piece of work. Regards, &rzej

2 1

Determining interest: C++11 parser generator library
by Gene Bushuyev 15 Nov '11

15 Nov '11

Sorry if it turns out to be a duplicate, it looks my original post was lost in cyberspace, so I'm re-posting this request. I'm trying to determine if there is a sufficient interest for including AXE C++11 recursive descent parser generator library in Boost. The zipped sources and documentation are here: http://www.gbresearch.com/axe/axe.zip - Gene Bushuyev

4 7

[program_options] Improving error text in exceptions
by Leo Goodstadt 15 Nov '11

15 Nov '11

As a long time fan of boost::program_options, I would very much like to make the error messages in program_options exceptions more consistent and informative. Exception text is usually aimed at the developer as a diagnostic for rare errors. If the exception needs to be propagated to the end-user, it can be caught, and a more appropriate message substituted. This is not true for program_options: Exceptions from invalid program arguments are the common (and normal) reason for early program termination. It would be nice if, out of the box, exception text could be clear enough to present to the end user more or less as is. This would allow a single try/catch(exception) in main() cerr << "Error: " << e.what() << "\n"; return 1; >From the attached list of error messages, there are many, many different exception types which are thrown. The usual practice of repackaging / reformatting exceptions to be more user-friendly would be tedious or impractical. I grep-ed "boost::throw_exception" to get a list of all the exceptions and messages. I suggested revisions for all but 5. These I have set them aside at the end. I have modelled some of the proposed text on GNU genparse examples (i.e. the behaviour of "ls" and "cat" etc.). These, by dint of their frequent use / hammering by the huge linux user base, are probably good examples of the sort of friendlier clarity I would hope for. In some cases, I have tried to understand the exception text from the code but might have misunderstood the original intent. If this is useful, I shall painstaking go through the code and submit a patch. Leo Goodstadt P.S. I realise there are pitfalls to do with option prefix styles "--" and "/" but the addition of option prefixes to the exception text makes the message a lot clearer. P.P.S. I have kept the current style of starting the text in lower case even though my own preference would be for a capitalised sentence ending in a full stop. ======================================================= Original (CURRENT) and revised (CHANGED) text resulting from exception.what() ======================================================= CURRENT: <ambiguous option option_name> CHANGED: <option '--option_name' is ambiguous and matches options "--aa"," --b" and "--c".> // abbreviated instead of long/short because // length might imply too many/few letters CURRENT: <style disallows parameters for long options> CHANGED: <arguments are not allowed for unabbreviated option names> CURRENT: <style disallows parameters for short options> CHANGED: <arguments are not allowed for abbreviated option names> CURRENT: <style disallows all characters for short options> CHANGED: <abbreviated option names are not valid> CURRENT: <adjacent parameter is empty> CHANGED: <Invalid command line syntax: each option with an equal sign must be followed immediately by its argument.> CURRENT: <parameters adjacent to long options not allowed> CHANGED: <arguments are not allowed for unabbreviated options> CURRENT: <required parameter is missing in 'option_name'> CHANGED: <option '--option_name' requires an argument> CURRENT: <in option 'option_name': invalid option value> CHANGED: <invalid argument for option '--option_name'> CURRENT: <unrecognised line in 'DODGY LINE'> CHANGED: <options configuration file contained an invalid line: 'DODGY LINE'> CURRENT: <multiple occurrences> CHANGED: <option '--option_name' cannot be specified more than once> CURRENT: <can not read file NON_EXISTENT_FILE_NAME> CHANGED: <cannot read options configuration file 'FILE_NAME'> CURRENT: <missing required option required_option> CHANGED: <option '--option_name' is required> CURRENT: <too many positional options> CHANGED: <too many positional arguments have been specified> CURRENT: <unknown option unknown_option> CHANGED: <unrecognised option 'option_name'> CURRENT: <in option 'invalid_option': invalid bool value> CHANGED: <at least one argument is required for option '--option_name> CURRENT: <in option 'option_name': invalid bool value> CHANGED: <invalid argument for option '--option_name'. Valid arguments are 'on|off', 'yes|no', '1|0' and 'true|false'> CURRENT: <in option 'option_name': multiple values not allowed> CHANGED: <option '--option_name' only takes a single argument> Not sure what these mean and have left them alone. libs/program_options/src/parsers.cpp:112: boost::throw_exception(error("long name required for config file")); libs/program_options/src/config_file.cpp:60: boost::throw_exception(error("bad prefixes")); libs/program_options/src/value_semantic.cpp:102: boost::throw_exception(multiple_values()); libs/program_options/src/convert.cpp:66: boost::throw_exception(std::logic_error("character conversion failed")); libs/program_options/src/convert.cpp:74: boost::throw_exception(std::logic_error("character conversion failed")); libs/program_options/src/value_semantic.cpp:33: boost::throw_exception(std::runtime_error("UTF-8 conversion not supported.")); -- Dr. Leo Goodstadt University of Oxford United Kingdom

2 1

[Serialization] Proposal for TR2
by Ruediger Berlich 15 Nov '11

15 Nov '11

Dear Robert, dear all. from what I understand, Boost.ASIO has been proposed for TR2 quite a while ago. Since I use ASIO and Boost.Serialization quite a bit and feel that both strongly benefit from each other (and not only ASIO -- see e.g. Boost.MPI), are there any efforts to make Boost.Serialization part of TR2 ? We live in the era of cloud computing and networked execution. Without this facility, C++ will have a hard time to compete. And Boost.Serialization is established and mature (thanks, Robert!). Best, Ruediger

3 2

[context] ready
by Oliver Kowalke 14 Nov '11

14 Nov '11

Hi, https://github.com/olk/boost.context.git contains the new version of boost.context (docu at http://ok73.ok.funpic.de/boost/libs/context/doc/html/index.html) Any comments are welcome - in the meantime I'm awaiting Giovanni's OK for the mini-review. regards, Oliver

8 15

Boost.Local Review (Nov 10, 2011 to Nov 19, 2011) by Krzysztof Czaiński
by Krzysztof Czainski 14 Nov '11

14 Nov '11

Hello, About me: I write C++ apps and RTS, mostly for embedded devices. I often use complicated C++ structures, and of course boost. Boost.Local caught my interest, so I decided to review it. I intend to try to use this library on MinGW-4.5, and on a Texas Instruments/DSP compiler, however I can't do that this week, so I won't make it until the end of this review. I studied the docs in depth. I state my comments below. Each of my comments is numbered in the style (0), so they can be referenced. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… : Variable Binding: [quote] programmers might want to bind variables of complex types by (constant) reference instead than by value [/qoute] (1) s/instead than/instead of/ Binding the Object this: [quote] It is also possible to bind the object this when it is in scope (e.g., from an enclosing non-static member function). This is done by using this as the name of the variable to bind in the local function declaration and by using the special symbol this_ (instead of this) to access the object within the local function body. [/qoute] (2) Why not use this_ in both places? Local Blocks: (3) How is a Local Block better then just an ordinary C++ block: {}? So far, I have an idea of what such a Local Block is for, but a reference to a rationale at this point in the tutorial would be nice. Local Exits: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. [16] [/qoute] (4) To me this note requires more explanation. Consider three examples: (4a) [code] int main() { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } // Local exit executed here. [/code] (4b) [code] int main() { try { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } catch ( ... ) {} } // Local exit executed here. [/code] (4c) [code] int main() { try { throw 0; BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END } catch ( ... ) {} } // Local exit executed here. [/code] I which of the abouve examples is printing "hello" guaranteed? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… : Assigning Local Functions: (5) In the example, variables named "l" (lowercase L) are used, which is easy to confuse with "1" (one), and therefore the example is hard to read. I suggest renaming that variable. Deducing Bound Types (concepts, etc): [qoute] it will also be a reference is the variable is bound by reference [/qoute] (6) typo: is -> if Inlining Local Functions [qoute]On C++03 compliant compilers, inlined local functions always have a run-time comparable to their equivalent implementation that uses local functors (see the Alternatives section). However, inlined local functions have the limitation that they cannot be assigned to other functors (like boost::function) and they cannot be passed as template parameters. [21] On C++11 compilers, inline has no effect because this library will automatically generate code that usesC++11 specific features to inline the local function calls whenever possible even if the local function is not declared inlined (unless the BOOST_LOCAL_CONFIG_COMPLIANT configuration macro is defined). Furthermore, non C++11local functions can always be passes as template parameters even when they are declared inlined.[/quote] (7) I read this paragraph four time, and still don't get it. Please rephrase is somehow ;-) (8) After reading the Introduction, Getting started, Tutorial and Advanced topics I still don't have an overview of the overhead, memory allocations, and exceptions that Local constructs can cause. Please add this information. Right now, I can deduce this information from the Implementation section. However, could things like lack of memory allocations or not emitting exceptions be promised in the public interface? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics). [/quote] (9)What are: the overhead, possible memory allocations, and exceptions, that Local constructs can cause? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [quote]If programmers leave this configuration macro undefined, its default value is to be left not defined.[/qoute] (10) What does it mean "its default value is to be left not defined"? Does it mean, that whether it's defined or not depends on the library, which tries to guess if the compiler supports variadic macros? [quote]If this macro is defined, variadic macros and empty macro parameters are not used by this library. Using variadic macros and empty macro parameters allows this library to provide the variadic macro and empty macro syntaxes which some programmers might find more readable than the sequencing macro syntax (see the Tutorial section, BOOST_LOCAL_FUNCTION_PARAMS, BOOST_LOCAL_BLOCK, and BOOST_LOCAL_EXIT). If this configuration macro is defined then only the sequencing macro syntax is allowed (regardless of whether the compiler supports variadic and empty macros or not).[/quote] (11)This paragraph is a bit unclear: first it says what happens if this macro is defined, then it says why variadic macros are useful, and lastly is says again what happens when this macro is defined. I suggest to make two paragraphs: first: state clearly what this macro does - disables the use of variadic macros, and second: comment on why variadic macros are useful. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics).[/qoute] (12) Notes (4) and (9) apply here as well. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics).[/quote] (13) Note (9) applies here as well. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: (14) What about the typename keyword inside templates? I think i remember from the previous sections, that typename is not required, but that information is missing here. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… Description: [qoute]For example, if the expression type is know (and contains no commas)[/quote] (15) typo: know -> known This concludes my study of the docs, and I won't be able to try to use this library before the end of this review, so I state my conclusions now. 2011/11/10 Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung(a)gmail.com> > Please state clearly whether you think this library should be accepted as a > Boost library. > Yes. Other questions you may want to consider: > > - What is your evaluation of the design? > I like it. > - What is your evaluation of the documentation? > I enjoyed reading it, and I think it gave me a pretty good idea about the library. > - What is your evaluation of the implementation? > >From what I read in the Implementation section of the docs, looks reasonable. > - What is your evaluation of the potential usefulness of the library? > I can imagine it would improve readability of some of my code. > - Did you try to use the library? With what compiler? Did you have any > problems? > No. I intend to, but not until the end of this review. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > In-depth study of the docs. > - Are you knowledgeable about the problem domain? > Hmm... I'll just say, I miss something like this for most of my 3-year experience of C++ programming. Please also consider the following issues and proposals specific to > Boost.Local. Your opinion is welcome on any or all of these. > > - Boost.Local's local exits provide the same functionality (and then some) > as Boost.ScopeExit. Does this duplication of functionality need to be > dealt with, and if so, how? I haven't used ScopeExit, so I don't have an opinion on this. - Lorenzo is proposing to add boost::local::function::overload to > Boost.Function as boost::function::overload. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… I don't remember missing such a utility in my experience, but it seems reasonable to add it to boost function. However, I don't understand, how can it be added as boost::function::overload, when boost::function is a class template? > - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… > - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to > boost/utility. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… > I don't remember missing any of the above in my experience. One of "more readable alternatives" described in the docs have sufficed. Thanks in advance to all who participate in the review discussion; I'm > looking forward to it! > > - Jeffrey Hellrung (Review Manager) > - Gregory Crosswhite (Review Assistant) This was my first review, and I hope it's useful ;-) Regards, Kris

3 3

Need for BOOST_PP_VARIADIC_POP_FRONT
by Gennadiy Rozental 14 Nov '11

14 Nov '11

Hi, I consider using Boost.PP variadic macros support, but I seems to be missing subject macro (with support for zero arguments). Any chance we can one? I'd hate to reinvent the wheel. Regards, Gennadiy

4 16

1.48 is another release without the logger
by Jeff Graham 14 Nov '11

14 Nov '11

Hello, Any progress on the logger?

2 1

Re: [boost] Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
by Lorenzo Caminiti 14 Nov '11

14 Nov '11

Hello all, I have received a couple of questions on Boost.Local and I will answer them on the ML. On Mon, Nov 14, 2011 at 4:20 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > 1. Can Boost.Local be used to create global functions? No, Boost.Local macros need to be used at local scope. If it were important to use the functionality of Boost.Local at global scope, it _might_ be possible to do so but another set of macros (BOOST_GLOBAL_?) will have to be defined for that. Does anyone see a need to use LOCAL_EXIT, LOCAL_BLOCK, or LOCAL_FUNCTION at global scope? If so, why? > 2. For Local Exits, is it possible not to bind any variable (because I will > only be calling global functions): > > int runCommand() { > ::DisplayWaitCursor(); > BOOST_LOCAL_EXIT( /*nothing*/ ) { > ::DisplayNormalCursor(); > } BOOST_LOCAL_EXIT_END; > > DoALongLastingOperation(); > } Yes, you can do this. However, the most portable syntax is to use void for the empty parameter list: https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… For example: #include <boost/local/exit.hpp> #include <iostream> void f() { std::cout << "f" << std::endl; } int main() { ::f(); BOOST_LOCAL_EXIT(void) { ::f(); } BOOST_LOCAL_EXIT_END return 0; }; This compiles and it prints "f" twice (at main entry and exit). HTH, --Lorenzo

1 0

[1.48][flyweight] regression in release branch
by JOAQUIN M. LOPEZ MUÑOZ 13 Nov '11

13 Nov '11

Hi, Sorry for not having tracked this before. There's a trivial regression in Boost.Flyweight due to a change of namespace name in Boost.Interprocess: https://svn.boost.org/trac/boost/changeset/75464 OK to commit to branch? Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx

2 2

[iostreams][io_state_savers] Request for interest in some ios_base basic utilities
by Vicente J. Botet Escriba 12 Nov '11

12 Nov '11

Hi, I'm a beginner of the standard IOStream library. While restructuring Boost.Chrono I/O I have find some classes that could be of general use (if the design is correct, of course). The first one is quite simple, is used to define manipulators with parameters. Instead of defining a class and the correspondent stream inserters and extractors the manip template class do all this at once. It can be used as follows class mendl: public manip<mendl> { public: explicit mendl(size_t how_many) : count(how_many) {} template <typename out_stream> void operator()(out_stream &out) const { for (size_t line = 0; line < count; ++line) { out.put(out.widen('\n')); } out.flush(); } private: size_t count; }; Now mendl can be use to insert n new lines at once as follows cout << mendl(3); The second one is an ios specific smart pointer ios_base_state_ptr (based on the use of ios_base::pword and ios_base::xalloc). The class ios_base_state is a ios_base_state_ptr that can not be null. It can be used like struct MyData { std::string time_fmt; std::string duration_fmt; }; std::string get_time_fmt(std::ios_base & ios) { return ios_base_state<MyData>(ios)->time_fmt; } ios_base_state stores a new MyData in the ios if not already stored and provides an smart pointer interface to it. The 3rd one (ios_base_flags) uses the ios_base::iword and xalloc to provide access to specific ios flags. It can be used as follows: class fmt_masks : ios_base_flags<fmt_masks> { typedef ios_base_flags<fmt_masks> base_type; public: fmt_masks(std::ios_base& ios): base_type(ios) {} enum type { uses_symbol = 1 << 0, uses_local = 1 << 1 }; }; Usage of this class can be duration_style::type get_duration_style(std::ios_base& ios) { return (fmt_masks(ios).flags() & fmt_masks::uses_symbol) ? duration_style::symbol : duration_style::prefix; } The interface and the implementation of these classes is attached. Do you see a design flag on these classes? If not, do you think these kind of utilities could be added to boost? If yes, could these be merged with Boost.io_state_savers or Boost.IOStreams to form a larger io utilities libraries? Best, Vicente

3 14

Are some of the trunk regression tests running in C++0x mode when they shouldn't be?
by Richard Webb 11 Nov '11

11 Nov '11

Looking at the Trunk regression tests, it appears that some of the GCC tests are running in C++0x mode when they shouldn't be. for example: Large numbers of the Sandia-gcc-3.4.6 tests are failing with the error: unrecognized command line option "-std=c++0x" If you look at the test results for assign, there are rvalue-reference related errors in toolsets which shouldn't have them. Looks like -std=c++0x is being specified when it shouldn't for some reason? Is something broken, or am i imagining it? Thanks, Richard Webb

7 10

leak in win32 detail::basic_condition_variable
by Kenneth Porter 10 Nov '11

10 Nov '11

I'm finding that an element in the CV's generation_list is left orphaned sometimes when the CV is destroyed. I'm running Visual Leak Detector and it gives this stack dump of the allocation point of the leaked object: c:\devel\boost\boost_1_46_1\boost\thread\win32\condition_variable.hpp (172): boost::detail::basic_condition_variable::get_wait_entry c:\devel\boost\boost_1_46_1\boost\thread\win32\condition_variable.hpp (211): boost::detail::basic_condition_variable::do_wait<boost::unique_lock <boost::mutex> > + 0xC bytes c:\devel\boost\boost_1_46_1\boost\thread\win32\condition_variable.hpp (369): boost::condition_variable_any::wait<boost::unique_lock<boost::mutex> > c:\devel\boost\boost_1_46_1\boost\thread\win32\condition_variable.hpp (374): boost::condition_variable_any::wait<boost::unique_lock <boost::mutex>,boost::_bi::bind_t<bool,boost::_mfi::cmf0 <bool,bounded_buffer<Axis::Report> >,boost::_bi::list1<boost::_bi::value <bounded_buffer<Axis: + 0x1B bytes I compared the source file against trunk and it hasn't changed.

1 0

asio ipv6 anycast
by Julian Faude 10 Nov '11

10 Nov '11

Hi, I am working on a project which depends on IPv6 anycast. In linux IPv6 anycast is available through a socket options called IPV6_JOIN_ANYCAST and IPV6_LEAVE_ANYCAST. Like the multicast option it's based on the ipv6_mreq struct. If I'm not mistaken there is no ipv6 anycast socket option in asio. Am I right? Is anybody working on it? Best, Julian

2 1

[Test] Darwin Intel 11.1
by Belcourt, K. Noel 09 Nov '11

09 Nov '11

Hi, I've attached a patch that appears to fix problems with about 20 Boost libraries on trunk that depend on Boost.Test. This patch simply removes an argument to format_report(). The trunk tests (http://www.boost.org/development/tests/trunk/developer/summary.html ) currently reflect this patch. I've added this patch to the nightly trunk testing patch script until such time as we get this committed to trunk. -- Noel

1 0

Fw: [atomic] review results
by Peter Dimov 08 Nov '11

08 Nov '11

-----Original Message----- From: Peter Dimov Sent: Monday, November 07, 2011 22:38 To: Helge Bahmann Subject: Re: [boost] [atomic] review results Helge Bahmann wrote: > yes makes sense -- there was a concern raised by Andrey Semashev that the > spinlock pool as implemented and used by shared_ptr presently may fail on > Windows due to the pool being non-unique (not had a chance to test this > yet), > and I have found a way to produce a similar failure using dlopen, atomics > private to shared libraries and RTLD_LOCAL -- currently I am therefore > leaning on creating a shared library just for the spinlock pool, but since > you wrote the initial implementation maybe you could comment as well? This is a problem in principle, but requiring all users of shared_ptr to link to a shared library is a non-starter. I wouldn't use such a shared_ptr, and I doubt many others will. And I wouldn't be surprised if this sentiment applies to Boost.Atomic as well.

5 35

[parameter] type requirement compiler error
by lcaminiti 08 Nov '11

08 Nov '11

Hello all, The following parameter type requirement: (required (graph, *) ) (optional (root_vertex, (typename boost::graph_traits<graph_type>::vertex_descriptor), *boost::vertices(graph).first) ) Generates a GCC error: dfs.05.cpp:40: error: ‘graph_type’ was not declared in this scope Detailed code and error below. In fact, if I look at the code after pp, I can see that graph_type is define only after the type requirement is checked... why? What am I doing wrong? Thanks a lot! --Lorenzo #include <boost/graph/adjacency_list.hpp> #include <boost/graph/depth_first_search.hpp> #include <boost/range/irange.hpp> #include <boost/pending/indirect_cmp.hpp> #include <boost/parameter.hpp> #include <iostream> namespace graphs { BOOST_PARAMETER_NAME(graph) BOOST_PARAMETER_NAME(visitor) BOOST_PARAMETER_NAME(root_vertex) BOOST_PARAMETER_NAME(index_map) BOOST_PARAMETER_NAME(color_map) template< typename Size, typename IndexMap > boost::iterator_property_map<boost::default_color_type*, IndexMap, boost::default_color_type, boost::default_color_type&> default_color_map ( Size const& num_vertices, IndexMap const& index_map ) { std::vector<boost::default_color_type> colors(num_vertices); return &colors[0]; } BOOST_PARAMETER_FUNCTION( (void), depth_first_search, tag, (required (graph, *)) (optional (visitor, *, boost::dfs_visitor<>()) (root_vertex, (typename boost::graph_traits<graph_type>::vertex_descriptor), *boost::vertices(graph).first) (index_map, *, boost::get(boost::vertex_index, graph)) (in_out(color_map), *, default_color_map(boost::num_vertices(graph), index_map)) ) ) { std::cout << "here\n"; boost::depth_first_search(graph, boost::visitor(visitor). color_map(color_map).root_vertex(root_vertex). vertex_index_map(index_map)); } } // namespace graphs template< typename TimeMap > class dfs_time_visitor : public boost::default_dfs_visitor { typedef typename boost::property_traits< TimeMap >::value_type T; public: dfs_time_visitor(TimeMap dmap, TimeMap fmap, T& t) : dmap_(dmap), fmap_(fmap), time_(t) {} template< typename V, typename G > void discover_vertex ( V u, G const& g ) const { put(dmap_, u, time_++); } template< typename V, typename G > void finish_vertex ( V u, G const& g ) const { put(fmap_, u, time_++); } TimeMap dmap_; TimeMap fmap_; T& time_; }; using namespace boost; int main ( ) { typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS> G; typedef boost::graph_traits<G>::vertices_size_type size_type; enum {u, v, w, x, y, z, N}; char names[] = {'u', 'v', 'w', 'x', 'y', 'z'}; typedef std::pair<int, int> E; E edges[] = {E(u, v), E(u, x), E(x, v), E(y, x), E(v, y), E(w, y), E(w, z), E(z, z)}; G g(edges, edges + sizeof(edges) / sizeof(E), N); std::vector<size_type> dtime(boost::num_vertices(g)); std::vector<size_type> ftime(boost::num_vertices(g)); size_type t = 0; dfs_time_visitor<size_type*> vis(&dtime[0], &ftime[0], t); graphs::depth_first_search(g, vis); std::vector<size_type> dorder(N); boost::integer_range<size_type> r(0, N); std::copy(r.begin(), r.end(), dorder.begin()); std::sort(dorder.begin(), dorder.end(), boost::indirect_cmp<size_type*, std::less<size_type> >(&dtime[0])); std::cout << "order of discovery: "; for(int i = 0; i < N; ++i) std::cout << names[dorder[i]] << " "; std::cout << std::endl; std::vector<size_type> forder(N); std::copy(r.begin(), r.end(), forder.begin()); std::sort(forder.begin(), forder.end(), boost::indirect_cmp<size_type*, std::less<size_type> >(&ftime[0])); std::cout << "order of finish: "; for(int i = 0; i < N; ++i) std::cout << names[forder[i]] << " "; std::cout << std::endl; return 0; } $ g++ -Wall -I../../../../../boost-trunk.cygwin dfs.05.cpp dfs.05.cpp:40: error: ‘graph_type’ was not declared in this scope dfs.05.cpp:40: error: template argument 1 is invalid dfs.05.cpp:40: error: expected `::' before ‘,’ token dfs.05.cpp:40: error: expected identifier before ‘,’ token dfs.05.cpp:40: error: template argument 3 is invalid dfs.05.cpp:40: error: expected `::' before ‘{’ token dfs.05.cpp:40: error: expected class-name before ‘{’ token ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp: In instantiation of ‘boost::parameter::aux::argument_pack<graphs::boost_param_params_40depth_first_search<int>, const boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>, const dfs_time_visitor<main::size_type*>, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>’: dfs.05.cpp:88: instantiated from here ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:157: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:158: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp: In instantiation of ‘boost::parameter::aux::argument_pack<graphs::boost_param_params_40depth_first_search<int>, const boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>’: dfs.05.cpp:88: instantiated from here ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:157: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:158: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ dfs.05.cpp: In function ‘int main()’: dfs.05.cpp:88: error: no matching function for call to ‘depth_first_search(main()::G&, dfs_time_visitor<size_type*>&)’ -- View this message in context: http://boost.2283326.n4.nabble.com/boost-parameter-type-requirement-compile… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 14

[1.48 lexical_cast] Illegal Derefence
by Olaf van der Spek 08 Nov '11

08 Nov '11

Hi, This does an illegal dereference in boost\lexical_cast.hpp(1357): if ( Traits::eq(minus,*start) ) #include <boost/lexical_cast.hpp> #include <boost/range/iterator_range.hpp> int main() { boost::iterator_range<const char*> v; boost::lexical_cast<int>(v); } -- Olaf

3 10

Boost interprocess: Segmentation fault
by thuannv 08 Nov '11

08 Nov '11

Hi everybody, I am beginner to develop with boost library. I am working with shared memory (boost.interprocess). So, I got error in executing and could anyone help me solve this problem? My problem is: - I wrote 2 process named SHMWriter and SHMReader. + SHMWwriter: write a map (int, int) into the SHM. + SHMReader: read the map value from SHM. - I executed the SHMWriter then SHMReader. - SHMWriter successfully executed. But, SHMWriter always executed failed (error: Segmentation fault). - The sources code are listed below: //SHMWriter: -------------------------------------------- typedef std::pair<int, int> MapValue; typedef allocator<MapValue, managed_shared_memory::segment_manager> MapAllocator; typedef map<int, int, std::less&lt;int>, MapAllocator> IntegerMap; const char* segName = "MAPSEGMENT"; const char* mapName = "MAPNAME"; int main() { shared_memory_object::remove(segName); managed_shared_memory segment(create_only, segName, 1000); MapAllocator allocator(segment.get_segment_manager()); IntegerMap* pOffsetMap = segment.construct<IntegerMap>(mapName)(std::less<int>(), allocator ); int key = 1; int ivalue = 10; MapValue value(key, ivalue); pOffsetMap->insert(value); return 0; } //SHMReader ----------------------------- typedef std::pair<int, int> MapValue; typedef allocator<MapValue, managed_shared_memory::segment_manager> MapAllocator; typedef map<int, int, std::less&lt;int>, MapAllocator> IntegerMap; const char* segName = "MAPSEGMENT"; const char* mapName = "MAPNAME"; int main() { try { managed_shared_memory segment(open_only, "MAPSEGMENT"); IntegerMap* pMap = segment.find_no_lock<IntegerMap>(mapName).first; int key = 1; int value = pMap->at(key); std::cout << value << std::endl; } catch(interprocess_exception& ie) { std::cout << ie.what() << std::endl; } catch(std::exception& stde) { std::cout << stde.what() << std::endl; } return 0; } -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-interprocess-Segmentation-fault-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[Range] Confusing result of iterator_range::size()
by Sergey Voropaev 08 Nov '11

08 Nov '11

Hi, I try use boost::iterator_range as replacement for some standard container in my code. The function iterator_range::size() has non standart declaration: difference_type size() const; but not: size_type size() const When I compile code in VC++ 2010 I have a some warning and error. For example: #include <boost/range.hpp> #include <vector> #include <algorithm> int main() { int aaa[10] ={1,2,3,4,5,6,7,8,9,10}; std::vector<int> bbb(20); boost::iterator_range<int*> arr(aaa); if(bbb.size() > arr.size()) //warning C4018: '>' : signed/unsigned mismatch { } const size_t lng = std::min(bbb.size(), arr.size()); //error C2780: 'const _Ty &std::min(const _Ty &,const _Ty &,_Pr)' : expects 3 arguments - 2 provided //error C2782: 'const _Ty &std::min(const _Ty &,const _Ty &)' : template parameter '_Ty' is ambiguous // const size_t lng = std::min(bbb.size(), (size_t)arr.size()); //OK for(size_t i = 0; i < lng; ++i) { bbb[i] = arr[i]; } return 0; } I think declaration of boost::iterator_range must be fixed. Or there was some reason for this non standard declaration?

8 29

Boost.Build is broken?
by Gennadiy Rozental 08 Nov '11

08 Nov '11

Hi, Frankly I do not know who supports Boost.Build, but how long it'll stay broken? I can't say when it started, but ever since I started working on Boost.Test changes I experience constant problems. I can't believe I am the only one. 1. When you take boost trunk and go into Boost.Test build or test directory and try building using any toolset it immediately fails with: ..\..\..\libs\test\build\Jamfile.v2:110: in modules.load rule boost-install unknown in module Jamfile</.../trunk/libs/test/build>. .../trunk/tools/build/v2/build\project.jam:314: in load-jamfile .../trunk/tools/build/v2/build\project.jam:62: in project.load .../trunk/tools/build/v2/build\project.jam:766: in project.use .../trunk/tools/build/v2/build\project.jam:89: in load-used-projects .../trunk/tools/build/v2/build\project.jam:73: in load .../trunk/tools/build/v2/build\project.jam:115: in load-parent .../trunk/tools/build/v2/build\project.jam:464: in initialize .../trunk/tools/build/v2/build\project.jam:309: in load-jamfile .../trunk/tools/build/v2/build\project.jam:62: in load .../trunk/tools/build/v2/build\project.jam:115: in load-parent .../trunk/tools/build/v2/build\project.jam:464: in initialize .../trunk/tools/build/v2/build\project.jam:309: in load-jamfile .../trunk/tools/build/v2/build\project.jam:62: in load .../trunk/tools/build/v2/build\project.jam:168: in project.find .../trunk/tools/build/v2\build-system.jam:570: in load .../trunk\tools\build\v2/kernel\modules.jam:283: in import .../trunk\tools\build\v2\kernel\bootstrap.jam:142: in boost-build .../trunk\boost-build.jam:17: in module scope 2. Once I remove boost-install from Boost.Test Jamfile, I get bun of errors like this: ..\..\..\libs\test\src\compiler_log_formatter.cpp(16) : fatal error C1083: Cannot open include file: 'boost/test/impl/compiler_log_formatter.ipp': No such file or directory Essentially boost home directory is missing from include path. How come? 3. Once I add "<include>../../.." into requirements section I can build with msvc toolsets. Now I am trying to use gcc toolset on Windows. I have latest cygwin installation and I am getting these errors (lots of them): gcc.compile.c++ ..\..\..\libs\test\build\bin\gcc\debug\link-static\compiler_log_formatter.o "g++" ... # compilation line here Access is denied. Apparently g++ is not an executable anymore with cygwin. I am able to workaround this by adding using gcc : 4.5.3 : g++-4.exe ; into user-config.jam, but why Boost.Build can't figure this out and do I need to support this file now myself? 4. After the fix I am able to build dll based tests, but when I attempt to use static library version of Boost.Test I am getting: gcc.archive ..\..\..\libs\test\build\bin\gcc-4.5.3\ debug\link-static\libboost_unit_test_framework.a "/usr/i686-pc-cygwin/bin/ar.exe" rc .... # list of object files here "/usr/i686-pc-cygwin/bin/ranlib.exe" ... # lib here The system cannot find the path specified. The system cannot find the path specified. This one I do not know how to fix. So the situation is that I cannot test any static library based unit tests (as a side note, this inability was the cause of crashes which interrupted trunk testing month ago). I addition whenever I want to check in my local changes to Jamfile (excluding hacks which I actually do not want to check in) it is rather annoying process. Any help would be appreciated, Gennadiy

3 4

[atomic] review results
by Tim Blechmann 07 Nov '11

07 Nov '11

hi all, unfortunately only few reviews of boost.atomic arrived in time, however i count 3 YES and no NO, so i am happy to say: Helge Bahmann's boost.atomic library is ACCEPTED. since the library is an implementation of a c++11 feature for c++03, design, API and semantics are mostly fixed. many comments are going into details of the implementation, so i won't sum them all up ... iac, helge already said he wants to address the raised issues, the main points are summarized below. full implementation of the c++11 interface: the library currently only implements a subset of the c++11 library. it lacks the functional interface for integral atomic types and the ATOMIC_VAR_INIT / ATOMIC_FLAG_INIT macro. quickly consulting the latest draft that i currently have at hand the following two functions are missing as well: template <class T> T kill_dependency(T y); void atomic_signal_fence(memory_order); i encourage helge to provide a full implementation of the interface. documentation: the documentation is currently lacking a good API reference. i would therefore encourage helge to provide a doxygen-generated reference section. there were some concerns that it assumes that readers will have to be familiar with concurrency. maybe it is a good idea to point to some literature/tutorials about concurrent programming and/or to c++11 atomics. the section of real-world examples could probably include a link to shavit/herlihy's book `the art of multiprocessor programming'. it would also be helpful to have a detailed specification, if a platform/compiler combination supports a specific type natively (with run-time dispatching or specific compiler flags) ... maybe in form of a table. shared memory support/multi-module support: in multi-module applications and when using shared memory, the blocking emulation of atomics can cause troubles. for multi-module applications this can be resolved by placing the spinlock pool inside a shared library. shared- memory support could be realized by associating a (spin)lock with each blocking atomic<> instead of using a pool of spinlocks. boost should definitely provide atomics which support shared memory, either by default or by an additional implementation which is placed in the boost::interprocess namespace. i would like to thank helge for implementing boost.atomic and submitting it to boost and everyone who participated in the review. cheers, tim review manager

4 4

[smart_ptr] Please merge 5327
by Steve M. Robbins 07 Nov '11

07 Nov '11

Peter Dimov, When you have a moment, could you merge the patch in ticket https://svn.boost.org/trac/boost/ticket/5327 It should be safe enough; Debian has been using this since August 2009. Thanks, -Steve

2 1

[parameter] named template parameters
by Lorenzo Caminiti 07 Nov '11

07 Nov '11

Hello all (and especially Boost.Parameter's authors), The Boost.Parameter docs suggest to implement parameter-enabled class templates using a series of typedes for the argument pack and the actual argument types. I think it is best to define extra template parameters with default values to old the argument pack Args and named template parameters ClassType, etc as shown below. This allows to use the named template parameters within the class declaration for example in a base class (boost::python::class_<ClassType, ...>) instead that just in the class definition. Do you see any problem in using extra template parameter to define the argument pack and named template parameters? #include <boost/parameter.hpp>#include <boost/python/class.hpp>#include <boost/type_traits/is_class.hpp>#include <boost/type_traits/is_base_and_derived.hpp>#include <boost/mpl/is_sequence.hpp>#include <boost/mpl/placeholders.hpp>#include <boost/mpl/not.hpp>#include <boost/mpl/and.hpp>#include <boost/noncopyable.hpp>#include <boost/shared_ptr.hpp> namespace py { namespace detail { struct bases_tag {}; } template< class B0 = void, class B1 = void, class B2 = void >struct bases : detail::bases_tag {}; BOOST_PARAMETER_TEMPLATE_KEYWORD(ClassType) BOOST_PARAMETER_TEMPLATE_KEYWORD(BaseList)BOOST_PARAMETER_TEMPLATE_KEYWORD(HeldType)BOOST_PARAMETER_TEMPLATE_KEYWORD(Copyable) template< typename Arg123X0 , typename Arg123X1 = boost::parameter::void_ , typename Arg123X2 = boost::parameter::void_ , typename Arg123X3 = boost::parameter::void_ , typename Args123 = typename boost::parameter::parameters< // IF(IS_EMPTY(DEFAULT(p)), required, optional) boost::parameter::required< tag::ClassType , boost::is_class<boost::mpl::_> > , boost::parameter::optional< // IF(IS_DEDUCED(p), deduced<tag::NAME(p)>, tag::NAME(p)) boost::parameter::deduced<tag::BaseList> // COMMA_IF(COMPL(IS_EMPTY(REQUIRES(p)))) REQUIRES(p) , boost::is_base_and_derived<detail::bases_tag, boost::mpl::_> > , boost::parameter::optional< boost::parameter::deduced<tag::HeldType> , boost::mpl::not_< boost::mpl::or_< boost::is_base_and_derived<detail::bases_tag, boost::mpl::_> , boost::is_same<boost::noncopyable, boost::mpl::_> > > > , boost::parameter::optional< boost::parameter::deduced<tag::Copyable> , boost::is_same<boost::noncopyable, boost::mpl::_> > >::bind<Arg123X0, Arg123X1, Arg123X2, Arg123X3>::type , typename ClassType = typename boost::parameter::value_type< Args123, tag::ClassType >::type , typename BaseList = typename boost::parameter::value_type< // ... COMMA_IF(COMPL(IS_EMPTY(DEFAULT(p)))) DEFAULT(p) >::type Args123, tag::BaseList, bases<> >::type , typename HeldType = typename boost::parameter::value_type< Args123, tag::HeldType, ClassType >::type , typename Copyable = typename boost::parameter::value_type< Args123, tag::Copyable, void >::type>struct class_ : boost::python::class_<ClassType, BaseList, HeldType, Copyable>{ typedef ClassType class_type; typedef BaseList base_list; typedef HeldType held_type; typedef Copyable copyable;}; } // namespace py struct b { virtual ~b() = 0; }; struct d : b { ~d() {} }; // Named parameters.typedef py::class_< py::ClassType<b>, py::Copyable<boost::noncopyable> > x1;typedef py::class_< d, py::HeldType< boost::shared_ptr<d> >, py::BaseList< py::bases<b> > > x2;// Deduced parameters.typedef py::class_< b, boost::noncopyable > y1;typedef py::class_< d, boost::shared_ptr<d>, py::bases<b> > y2; A couple more things: 1) I thing that BOOST_PARAMETER_TEMPLATE_KEYWORD(ClassType) macro should define a symbol _ClassType to be used for the named parameter so to be consistent with the BOOST_PARAMETER_NAME(x) which defined _x to be used for the named function parameter. However, ClassType is defined without the leading _. What is the reason for this asymmetry? 2) I'd expect a macro that allows to specify tag and passing argument name for template parameters BOOST_PARAMETER_TEMPLATE_KEYWORD((PassClassType, mytag) ClassType) as for BOOST_PARAMETER_NAME((pass_x, mytag) x) does for function parameters. Why is such a usage of BOOST_PARAMETER_TEMPLATE_KEYWORD not supported? Thanks a lot. --Lorenzo

4 10

[smart_ptr] scoped_array / shared_array (size_t) constructor
by Olaf van der Spek 07 Nov '11

07 Nov '11

Hi, Currently, one has to manually allocate the array and pass the ptr to the constructor of scoped_array / shared_array. boost::scoped_array<unsigned char> A(new unsigned char[100]); boost::shared_array<unsigned char> B(new unsigned char[100]); This requires one to repeat the type and shared_array requires two allocations (one extra for the control block). std::vector has a constructor from size_t and one can write: std::vector<unsigned char> V(100); This avoids the type duplication and it'd allow shared_array to do only a single allocation. A few choices have to be made: 1. Should "new T[sz]" or "new T[sz]()" be used? 2. What should happen when size = 0? Should it call new T[0] or should it just use NULL? https://svn.boost.org/trac/boost/ticket/4637 -- Olaf

10 46

[python] Please apply and merge 2208
by Steve M. Robbins 07 Nov '11

07 Nov '11

Hi, The patch has been used in Debian since August 2008 so it should be safe to apply. Thanks, -Steve

1 0

[units] spatial coordinates, vectors, x, y, z, something like that
by Janek Kozicki 06 Nov '11

06 Nov '11

Hi, I want to use boost::units to calculate diffraction & interference patterns and wave propagation in 3D. I need some way to represent points in spatial 3D space with 'length' dimension. What do you guys use for that? I need them to work with 'frequency' & 'speed' dimensions also. Don't tell me that I need to write my own 'vector' class ? best regards -- Janek Kozicki http://janek.kozicki.pl/ |

2 2

Interest in bounded (Top-Bounded) Range adaptor.
by Fernando Pelliccioni 06 Nov '11

06 Nov '11

Is there interest in adding a Top-Bounded adaptor into Boost.Range ? Example: using namespace boost::adaptors; using namespace boost::assign; std::vector<int> input; input += 1,2,3,4,5,6,7,8,9; boost::copy( input | bounded(0), std::ostream_iterator<int>(std::cout, ",")); // prints nothing boost::copy( input | bounded(1), std::ostream_iterator<int>(std::cout, ",")); // prints 1, boost::copy( input | bounded(2), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2, boost::copy( input | bounded(8), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2,3,4,5,7,8, The above example is similar in behavior to ... boost::copy_n( input, 0, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 1, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 2, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 8, std::ostream_iterator<int>(std::cout, ",")); The difference is that *copy_n* algorithm doesn't check for begin(range) != end(range) In the following line, an error occurs at runtime... boost::copy_n( input, 9, std::ostream_iterator<int>(std::cout, ",")); Unlike the following that runs ok... boost::copy( input | bounded(9), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2,3,4,5,7,8,9, This behavior could be equated using *sliced(0, X)*, but sliced requires *RandomAccessRange*, unlike bounded that requires *SinglePassRange*. *bounded* code is based on *indexed* adaptor code, I think it is more efficient than *sliced* ( that uses *make_iterator_range* --> std::advance ). I don't know if this behavior can be achieved using other adapters, if so, please let me know. Is there interest in this for Boost? Regards, Fernando.

5 12

[parameter] aux_/void.hpp: potential undefined behavior
by Krzysztof Czainski 05 Nov '11

05 Nov '11

Hello, Here's boost/aux_/void.hpp contents, without include quards and license note, where I marked a line with a comment to refer to it below. [code] namespace boost { namespace parameter { // A placemarker for "no argument passed." // MAINTAINER NOTE: Do not make this into a metafunction struct void_ {}; namespace aux { inline void_& void_reference() { static void_ instance; // (1) return instance; } } // namespace aux }} // namespace boost::parameter [/code] My question is: is it allowed to use an instance of an uninitialized empty struct? The struct void_ is empty. On line (1) a static uninitialized instance of struct void_ is defined, and it is then returned. Does the standard allow this? I can't imagine any real problems with this, but I'm curious if this has defined behavior according to the standard. A natural and simple solution to my concern is of course to change the line (1) to: static void_ instance = {}; I'd be happy to create a ticket with a patch, if my concern is valid. Regards, Kris

3 5

[lockfree] review
by Gordon Woodhull 05 Nov '11

05 Nov '11

Hi Tim, Hopefully I'll have at least a partial review. I only know enough about the subject to be a little dangerous. (One course in concurrent data structures, one successfully implemented lockfree hash table - except for the memory reclamation. Unspecified barriers and ABA problems. :p ) Considering the difficulty of the subject, you seem to have carefully chosen a small set of algorithms where at least there is consensus that the sources you are using have solved the problem correctly. I apologize if this has already been covered, but I don't see anything in the documentation about which platforms and compilers this has been tested on. These algorithms are extremely susceptible to compiler and processor optimizations. Anyway, I thought I would try to run the tests, and maybe try changing the testing methodology a little, but I got a few compiler errors, below. Defining uint fixed most of these, but bench_1.cpp also appears to be out of date? Of course I also have my lack of understanding of boost build library linking to contend with. Hope to try again later. Cheers, Gordon ~/lib/boost_lockfree/libs/lockfree/test ~/src/boost-trunk grodo-mcwoohu:test gordon$ bjam ...found 141 targets... ...updating 21 targets... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o g++: unrecognized option '-no-cpp-precomp' bench_1.cpp: In function 'void test_fifo_pop()': bench_1.cpp:67:23: error: no matching function for call to 'boost::lockfree::fifo<long int>::dequeue(long int*)' ../../../boost/lockfree/fifo.hpp:214:10: note: candidate is: bool boost::lockfree::detail::fifo<T, freelist_t, Alloc>::dequeue(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_fifo_pop_unsafe()': bench_1.cpp:77:30: error: no matching function for call to 'boost::lockfree::fifo<long int>::dequeue_unsafe(long int*)' ../../../boost/lockfree/fifo.hpp:255:10: note: candidate is: bool boost::lockfree::detail::fifo<T, freelist_t, Alloc>::dequeue_unsafe(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_stack_pop()': bench_1.cpp:87:19: error: no matching function for call to 'boost::lockfree::stack<long int>::pop(long int*)' ../../../boost/lockfree/stack.hpp:179:10: note: candidate is: bool boost::lockfree::stack<T, freelist_t, Alloc>::pop(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_stack_pop_unsafe()': bench_1.cpp:97:26: error: no matching function for call to 'boost::lockfree::stack<long int>::pop_unsafe(long int*)' ../../../boost/lockfree/stack.hpp:207:10: note: candidate is: bool boost::lockfree::stack<T, freelist_t, Alloc>::pop_unsafe(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -dynamic -no-cpp-precomp -gdwarf-2 -fexceptions -fPIC -I"../../.." -c -o "../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o" "bench_1.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o... ...skipped <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1 for lack of <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1.o... ...skipped <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1.run for lack of <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o g++: unrecognized option '-no-cpp-precomp' fifo_test.cpp:103:18: error: 'uint' does not name a type fifo_test.cpp: In member function 'void fifo_tester<freelist_t>::add()': fifo_test.cpp:116:14: error: 'uint' was not declared in this scope fifo_test.cpp:116:19: error: expected ';' before 'i' fifo_test.cpp:116:26: error: 'i' was not declared in this scope fifo_test.cpp:116:31: error: 'nodes_per_thread' was not declared in this scope fifo_test.cpp: In member function 'void fifo_tester<freelist_t>::run()': fifo_test.cpp:187:1: error: 'nodes_per_thread' was not declared in this scope "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -dynamic -no-cpp-precomp -gdwarf-2 -fexceptions -fPIC -I"../../.." -c -o "../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o" "fifo_test.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o... ...skipped <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test for lack of <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test.o... ...skipped <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test.run for lack of <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test... darwin.link ../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test ld: library not found for -lboost_thread collect2: ld returned 1 exit status "g++" -o "../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test" "../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test.o" -lboost_thread -lboost_unit_test_framework -g ...failed darwin.link ../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test... ...skipped <p../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi>freelist_test.run for lack of <p../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi>freelist_test... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/ringbuffer_test.test/darwin-4.5.3/debug/threading-multi/ringbuffer_test.o g++: unrecognized option '-no-cpp-precomp' ringbuffer_test.cpp:209:14: error: 'uint' does not name a type ringbuffer_test.cpp: In member function 'void ringbuffer_tester::add()': ringbuffer_test.cpp:225:14: error: 'uint' was not declared in this scope ringbuffer_test.cpp:225:19: error: expected ';' before 'i' ringbuffer_test.cpp:225:26: error: 'i' was not declared in this scope ringbuffer_test.cpp:225:31: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester::run()': ringbuffer_test.cpp:284:1: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester_buffering::add()': ringbuffer_test.cpp:315:14: error: 'uint' was not declared in this scope ringbuffer_test.cpp:315:19: error: expected ';' before 'i' ringbuffer_test.cpp:315:26: error: 'i' was not declared in this scope ringbuffer_test.cpp:315:31: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester_buffering::run()': ringbuffer_test.cpp:386:1: error: 'nodes_per_thread' was not declared in this scope

8 63

Re: [boost] [lockfree] review
by Boehm, Hans 05 Nov '11

05 Nov '11

[Dave Abrahams pointed me at this thread.] Alexander Terekhov <terekhov <at> web.de> writes: > > Dave Abrahams wrote: > > > > on Thu Aug 25 2011, Alexander Terekhov <terekhov-AT-web.de> wrote: > > > > > Ilya Sokolov wrote: > > >> > > >> > > >> AFAIK, in the example above another thread can't observe reordering > > >> without introducing UB. > > > > > > I meant "observed" as in "check the sequence of writes in the generated > > > code". > > > > Do we care about what the generated code looks like? IIUC what counts > > is the sequence of memory states that another another thread can see. > > > > > But int can be simply changed to relaxed atomic<int> so that another > > > thread can observe reordering without UB. > > > > Sure. > > I meant that for the example upthread, with an int instead of relaxed > atomic<int>, another thread's code triggering UB does not prevent us > from observing reordered writes in the writing thread's code (in > generated code), by looking at it. > > Changing int to relaxed atomic<int> simply removes UB but does not > change the relevant code in the writing thread. > > regards, > alexander. > I agree with Alexander and most of the recent postings. If I write mx.lock(); x = 1; mx.unlock(); my.lock(); y = 1; my.unlock(); There is nothing to prevent the stores to x and y from becoming visible out of order at the hardware level. Enforcing ordering here would add needless and substantial cost. But a data-race-free program cannot observe such reordering. (One reference for that is Sarita Adve's and my PLDI 08 paper. Unofficial TR version at http://www.hpl.hp.com/techreports/2008/HPL-2008- 56.html. I believe Mark Batty et al have a much more complete and formal proof.) If we change x and y to be atomic variables, and the stores to be memory_order_relaxed, then an observer can tell the difference. I.e. if x and y are initially zero, and another thread does r1 = y; r2 = x; (or the acquire versions), it can see r1 = 1 and r2 = 0, since there are no synchronizes-with relationships between threads, and thus nothing to enforce ordering. If you use memory_order_relaxed, or even the acquire/release forms, things do get MUCH more complicated. The equivalent rules for other languages are an interesting story. I believe Posix implentors assume the above rules. I have a PPoPP 2007 paper that explains why that's not exactly what Posix actually states. OpenMP 3.0 has stricter rules which are also not consistently obeyed, and are somewhat fixed in OpenMP 3.1. (See my MSPC 11 paper for some details.) Java has arguably the same rules as C++ in this respect. In my mind, the main way in which sequential consistency differs from the cheaper acquire/release semantics that Alexander wants is that a) Dekker's algorithm (which by itself isn't that practically interesting), plus a number of real lock-free algorithms (which do matter) don't work. b) In my mind, acquire/release is a far more difficult model to explain to non- experts than the model for C++ with only sequentially consistent atomics. You can no longer reason about interleaving thread actions, either for purposes of determining the existence of a data-race, nor when defining what data-race- free programs mean. This was extensively discussed in C++ meetings starting in about 2005. The current solution with default-sequentially-consistent atomics, but explicit support for weaker ordering, was the resulting committee compromise. Hans

6 19

Determining interest in Delegates submission
by Jared McKee 05 Nov '11

05 Nov '11

I would like to determine interest in a possible library submission. I have written some code which converts a member function and object pointer combination to a free function for use in C style callbacks. It has some limitations which I will describe shortly. The basic idea is to be able to convert: R (B::*)(T0,T1,…) and B* to R (*)(T0,T1,…) Here's an example usage: class foo { int x; int test(int v) {return x + v;} }; foo* a = new foo; a->x = 3; int (*f)(int) = delegate(a, &foo::inc); cout << f(4) << endl; // outputs "7" When I first attempted this I used a technique where I allocated some executable memory in the heap and dynamically created a free function to call the member function for the instance. It was fun attempting that but, as you can imagine, as soon as I used the optimizer flags on my compiler I would get segment faults :) My second approach was to use templates and the Boost Preprocessor library to create appropriate static arrays of pointers to free functions matching the required signatures and then hand those pointers out each time the delegate() function is called. The two downsides to this are: you can only call delegate() for a certain function signature a limited number of times, and it adds a lot of potentially unused code to your executable. Here's the code (I've stripped out error checking for the sake of illustration): #include <boost/preprocessor.hpp> #ifndef _delegate_h_ #define _delegate_h_ #define MAX_DELEGATES 256 #define DELEGATE_PARAMS 0 #include "delegate_template.hpp" #undef DELEGATE_PARAMS #define DELEGATE_PARAMS 1 #include "delegate_template.hpp" #undef DELEGATE_PARAMS // … #endif // delegate_template.hpp #define DELEGATE_STORE BOOST_PP_CAT(DELEGATE_STORE,**DELEGATE_PARAMS) template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > struct DELEGATE_STORE { typedef B* objectPointer; typedef R (B::*memberFunction)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ); typedef R (*freeFunction)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ); static int delegateCount; static int delegateMax; static objectPointer delegateObjectPointer[MAX_**DELEGATES]; static memberFunction delegateMemberFunction[MAX_**DELEGATES]; template <int i> static R func( BOOST_PP_ENUM_BINARY_PARAMS(**DELEGATE_PARAMS, T, v) ) { return (delegateObjectPointer[i]->***delegateMemberFunction[i])( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, v) ); } static const freeFunction delegateFreeFunction[MAX_**DELEGATES]; static freeFunction getDelegate(objectPointer o, memberFunction m) { int delegateIndex = delegateCount++; delegateObjectPointer[**delegateIndex] = o; delegateMemberFunction[**delegateIndex] = m; return delegateFreeFunction[**delegateIndex]; } }; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > int DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::delegateCount = 0; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > int DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::delegateMax = MAX_DELEGATES; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::memberFunction DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateMemberFunction[MAX_**DELEGATES] = {0}; > template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::objectPointer DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateObjectPointer[MAX_**DELEGATES] = {0}; > #define FUNC_POINTER(z, n, params) &DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::template func< n >, template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > const typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::freeFunction DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateFreeFunction[MAX_**DELEGATES] = { > BOOST_PP_REPEAT(MAX_DELEGATES, FUNC_POINTER,) }; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > R (*delegate( B* b, R (B::*f)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ) ))( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ) { return DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::getDelegate(b, f); } // end Thankyou very much if you managed to read all the way to here! By the way, this is my first active participation in any open source project :) Jared

3 5

[BGL] map_as_graph.hpp
by Shaun Jackman 04 Nov '11

04 Nov '11

Hi, In the spirit of vector_as_graph.hpp, I created map_as_graph.hpp. One useful feature is that the vertex_descriptor can be any user-defined type, such as a string or an arbitrary object. It's not in a form that's ready to be included in Boost, but I have found it occasionally useful. I though I'd post it in the case that someone else found it useful. If someone found it useful enough that he or she where interested in further developing to the point where it could be included in Boost, please be my guest. Cheers, Shaun #ifndef MAP_AS_GRAPH_HPP #define MAP_AS_GRAPH_HPP 1 #include <boost/graph/graph_traits.hpp> #include <cassert> #include <map> #include <utility> // for make_pair namespace boost { /** * A std::map is a model of a directed graph. * @author Shaun Jackman <sjackman(a)gmail.com> */ template <typename V, typename T> struct graph_traits<std::map<V, T> > { // Graph typedef V vertex_descriptor; typedef boost::directed_tag directed_category; struct traversal_category : boost::adjacency_graph_tag, boost::vertex_list_graph_tag { }; typedef boost::disallow_parallel_edge_tag edge_parallel_category; // IncidenceGraph typedef std::pair<vertex_descriptor, vertex_descriptor> edge_descriptor; typedef size_t degree_size_type; /** Iterate through the out edges of a vertex. */ struct out_edge_iterator : std::map<V, typename T::mapped_type>::const_iterator { typedef typename std::map<V, typename T::mapped_type>::const_iterator It; out_edge_iterator(const It& it, vertex_descriptor src) : It(it), m_src(src) { } edge_descriptor operator*() const { return edge_descriptor(m_src, It::operator*().first); } private: vertex_descriptor m_src; }; // BidirectionalGraph typedef void in_edge_iterator; // AdjacencyGraph /** Iterate through the adjacent vertices of a vertex. */ struct adjacency_iterator : std::map<V, typename T::mapped_type>::const_iterator { typedef typename std::map<V, typename T::mapped_type>::const_iterator It; adjacency_iterator(const It& it) : It(it) { } const vertex_descriptor& operator*() const { return It::operator*().first; } }; // VertexListGraph /** Iterate through the vertices of this graph. */ struct vertex_iterator : std::map<V, T>::const_iterator { typedef typename std::map<V, T>::const_iterator It; vertex_iterator(const It& it) : It(it) { } const vertex_descriptor& operator*() const { return It::operator*().first; } }; typedef size_t vertices_size_type; // EdgeListGraph typedef void edge_iterator; typedef void edges_size_type; }; // graph_traits<std::map> // IncidenceGraph template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::out_edge_iterator, typename graph_traits<std::map<V, T> >::out_edge_iterator> out_edges( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typedef typename graph_traits<std::map<V, T> >::out_edge_iterator out_edge_iterator; typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return make_pair( out_edge_iterator(it->second.begin(), u), out_edge_iterator(it->second.end(), u)); } template <typename V, typename T> typename graph_traits<std::map<V, T> >::degree_size_type out_degree( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return it->second.size(); } // AdjacencyGraph template <typename V, typename T> std::pair<typename graph_traits<std::map<V, T> >::adjacency_iterator, typename graph_traits<std::map<V, T> >::adjacency_iterator> adjacent_vertices( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return make_pair(it->second.begin(), it->second.end()); } // VertexListGraph template <typename V, typename T> std::pair<typename graph_traits<std::map<V, T> >::vertex_iterator, typename graph_traits<std::map<V, T> >::vertex_iterator> vertices(const std::map<V, T>& g) { return make_pair(g.begin(), g.end()); } // AdjacencyMatrix template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); return std::make_pair(make_pair(u, v), it == g.end() ? false : it->second.count(v) > 0); } // VertexMutableGraph template <typename V, typename T> void remove_vertex( typename graph_traits<std::map<V, T> >::vertex_descriptor u, std::map<V, T>& g) { size_t n = g.erase(u); assert(n == 1); (void)n; } // EdgeMutableGraph template <typename V, typename T> void clear_out_edges( typename graph_traits<std::map<V, T> >::vertex_descriptor u, std::map<V, T>& g) { typename std::map<V, T>::iterator it = g.find(u); assert(it != g.end()); it->second.clear(); } template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> add_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { typename edge_property<std::map<V, T> >::type ep; return make_pair(std::make_pair(u, v), g[u].insert(make_pair(v, ep)).second); } template <typename V, typename T> void remove_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { size_t n = g[u].erase(v); assert(n == 1); (void)n; } // PropertyGraph template <typename V, typename T> no_property get(vertex_bundle_t, const std::map<V, T>&, typename graph_traits<std::map<V, T> >::vertex_descriptor) { return no_property(); } template <typename V, typename T> const typename T::mapped_type& get(edge_bundle_t, const std::map<V, T>& g, typename graph_traits<std::map<V, T> >::edge_descriptor e) { typename std::map<V, T>::const_iterator u = g.find(source(e, g)); assert(u != g.end()); typename T::const_iterator v = u->second.find(target(e, g)); assert(v != u->second.end()); return v->second; } // MutablePropertyGraph namespace boost { template <typename V, typename T> class vertex_property<std::map<V, T> > { public: typedef no_property type; }; template <typename V, typename T> class edge_property<std::map<V, T> > { public: typedef typename T::mapped_type type; }; } template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> add_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, typename edge_property<std::map<V, T> >::type ep, std::map<V, T>& g) { return make_pair(std::make_pair(u, v), g[u].insert(std::make_pair(v, ep)).second); } } // namespace boost #endif

1 0

Remembering that T(a) can cause dangerous conversion like a C-style cast
by Kazutoshi Satoda 04 Nov '11

04 Nov '11

An essential question: Should boost::lambda::constructor<int>()("") compiles? It does compile with Boost 1.47.0 . But I think it shouldn't. I have crafted a general replacement of T(a) as a workaround for dangerous conversions caused by T(a) which may happen in some kinds of templates. http://ideone.com/iZE1Z unary_initialized<T>(a).value And I thought of that the above workaround (or something similar) may be suitable to be provided within boost::initialized . Now I want to share the idea and to hear interests or evaluations in the community about such extension and underlying issues, before starting further acts. Here is the background story: A while ago, I had a conversation about dangerous conversion that can be caused by the following expression with variadic templates in C++11. T(std::forward<Args>(args)...) This expression is meant to obtain a prvalue of type T which is direct initialized from any given argument list. But if a single argument was given, this becomes T(std::forward<Arg>(arg)) and further, for example, may become int("") and compiles as reinterpret_cast which is likely unexpected. Here is a relevant quote from the standard 5.2.3 p1: > ... If the expression list is a single expression, the type conversion > expression is equivalent (in definedness, and if defined in meaning) to > the corresponding cast expression (5.4). ... (Note: 5.2.3 describes the behavior of T(a), and 5.4 describes the behavior of (T)a.) To avoid the unexpected conversion, I first proposed use of T{...} . But it is not a perfect solution because it changes the meaning in some cases like std::vector<int> . After that, I crafted a tricky workaround. http://ideone.com/FLoDk pack_initialized<T>(std::forward<Args>(args)...).value The above story was about C++11. But it revealed that similar dangerous conversion can be also formed in C++98, C++03 as T(a) in some kinds of templates. Searching in the boost directory (trunk r75213), I found some occurrences of the problem: boost/lambda/construct.hpp:37: http://www.boost.org/doc/libs/1_47_0/boost/lambda/construct.hpp return T(a1); boost/xpressive/regex_actions.hpp:632: http://www.boost.org/doc/libs/1_47_0/boost/xpressive/regex_actions.hpp return T(a0); As shown in the top of this message, I picked boost::lambda::constructor as a concrete example, and verified that the problem really exists in the wild. Thinking more, I wonder why such dangerous conversion was explicitly injected to T(a) in the first place. I first thought of some C-compatibility issues. But now I think it cannot be, because T(a) is a new construct in C++. Is it possible to remove this dangerous conversion path in a future revision of the standard? Perhaps I should go to comp.std.c++ about the last question. -- k_satoda

2 2

[release][1.48] Several merge requests
by Daniel James 04 Nov '11

04 Nov '11

Hi, Please can I merge the following changes: This prevents standard containers from being forward declared for gcc's 'profile' mode: https://svn.boost.org/trac/boost/changeset/75016 Trivial change to improve a couple of quickbook warnings (obviously not vital, but simple enough): https://svn.boost.org/trac/boost/changeset/75088 In unordered, avoid using a name that clashes with a macro defined by a header included from ASIO: https://svn.boost.org/trac/boost/changeset/75123 Missing html redirect, fixes some links to Boost.Move (documentation change): https://svn.boost.org/trac/boost/changeset/75141 Unordered wasn't working on gcc 4.7 in c++0x mode because of changes to std::pair's constructor. Unfortunately, the gcc 4.7 tester hasn't run since this change and I don't have access to it, so I haven't verified that it fixes the problem. But it does work fine on everything it has been tested with. https://svn.boost.org/trac/boost/changeset/75158 This stops using a hack on Visual C++ which was breaking for certain versions (although it didn't show up on any tester). But this is moving from a hacky implementation to a slightly less capable but more reliable implementation, so I think it's a good change regardless. https://svn.boost.org/trac/boost/changeset/75167 thanks, Daniel

2 1

"Best so far" for C level i/o of Unicode text with Windows console
by Alf P. Steinbach 03 Nov '11

03 Nov '11

This may be of interest to developers of Boost libraries that deal with text. I found that the Visual C++ implementation of the C library i/o generally does not support console input of international characters. It can deal with narrow character input from the current codepage, if that codepage is not UTF-8. For example: <code> #include <stdio.h> int main() { printf( "? " ); char buffer[80]; scanf( "%s", buffer ); printf( "%s\n", buffer ); } </code> <result> d:\dev\test> chcp 1252 Active code page: 1252 d:\dev\test> utf8test ? abcæøå abcæøå d:\dev\test> chcp 65001 Active code page: 65001 d:\dev\test> utf8test ? abcæøå ��, d:\dev\test> _ </result> I placed a comment about this at the blog of Microsoft's Unicode guru Michael Kaplan, http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx In particular, with active codepage 65001 (UTF-8), functions such as wscanf just fail outright on non-ASCII characters. The IMO best compromise that I have managed to come up with is a kind of hybrid, where the active input codepage is set to 1252, Windows ANSI Western, because that's a superset of Latin 1 which is a subset of Unicode. Output is converted to UTF-8. Input from e.g. a file accepts UTF-8. This means that e.g. Norwegian text can be input interactively (restricted to Latin 1 character set) or from a pipe or file (as UTF-8) without problems, and can be automatically translated (by the C i/o level) to UTF-16 encoding inside the program. However, I'm guessing that the C level input will garble e.g. Russian text no matter what one does, if one desires some Unicode based encoding inside the program. The Windows and Visual C++ support is just full of bugs -- e.g. as the crash of `more` showed in an earlier thread. Initialization of streams for the compromize scheme: static void msvcCompatibleInit() { struct Fix { static void mode( FILE* f, char const errorText[] ) { int const fileNo = _fileno( f ); bool const isConsoleInput = (f == stdin && _isatty( fileNo )); if( isConsoleInput ) { // Bytes are received as per the active codepage in the console. // Except if that active codepage is 65001, in which case non-ASCII // characters fail. Also, _setmode just causes non-ASCII fail. // // Setting the console codepage to 1252 might be practically helpful, // since cp 1252, Windows ANSI Western, is a superset of Latin 1 // which is a subset of Unicode. However, non-Latin 1 characters will // then be incorrect, just as with web pages in the old days. } else { int const newMode = _setmode( fileNo, _O_U8TEXT ); hopefully( newMode != -1 ) || throwX( errorText ); } } }; Fix::mode( stdin, "_setmode stdin failed" ); Fix::mode( stdout, "_setmode stdout failed" ); Fix::mode( stderr, "_setmode stderr failed" ); } Cheers & hth., - Alf

3 3

[interprocess] message_queue hangs when another process dies
by Sergei Politov 03 Nov '11

03 Nov '11

Hi, I have found the following problem with message_queue on win32 (MSVC 2008 + Windows Vista). Suppose we have 2 processes, one sends messages to queue, another reads them. When reading process dies (for instance using End process) during message_queue.receive the another process hangs in send. As I found during investigation, it tries to lock interprocess mutex, but it is already locked by dead process. So this message queue instance becomes unusable. I attached the example. Steps to reproduce: 1) Start "mq.exe s" (i.e. with argument s) It outs: sender: $PID 2) Start mq.exe without arguments. It outs: receiver: $PID 0 1 2 3 4 This time sender outs: send done: 3) At this point the message queue is empty and receiver waits for messages. End it with Task Manager. 4) Enter some number in sender console and press Enter. 5) The sender hangs in message_queue.send Best Regards, Sergei

6 13

[Boost.Endian] Review Results
by joel falcou 03 Nov '11

03 Nov '11

Hi everyone, after some delay, here is the result of the review of Beman Dawes' Boost.Endian library. First, I want to thanks all participants of the review that lead to very deep and interesting discussions on the matter. 5 votes were cast : 2 unconditionally in favor, 3 conditionally in favor after changes made and there is a mini-review. The verdict is that Boost.Endian is **CONDITIONNALY ACCEPTED** Here is what needs to be done to get the library ready for a mini-review: * Common use case scenarios should be developed. * Example programs should be developed for the common use case scenarios. * Documentation should illuminate the differences between endian integer/float type and endian conversion approaches to the common use case scenarios, and provide guidelines for choosing the most appropriate approach in user's applications. * Conversion functions supplying results via return should be provided. * Platform specific performance enhancements such as use of compiler intrinsics or relaxed alignment requirements should be supported. * Endian integer (and floating) types should be implemented via the conversion functions. If that can't be done efficiently, consideration should be given to expanding the conversion function signatures to resolve the inefficiencies. * Benchmarks that measure performance should be provided. It should be possible to compare platform specific performance enhancements against portable base implementations, and to compare endian integer approaches against endian conversion approaches for the common use case scenarios. * Float (32-bits) and double (64-bits) should be supported. IEEE 754 is the primary use case. * Support for user defined types (UDTs) is desirable, and should be provided where there would be no conflict with the other concerns. * There is some concern that endian integer/float arithmetic operations might used inadvertently or inappropriately. The impact of adding an endian_buffer class without arithmetic operations should be investigated. * Stream insertion and extraction of the endian integer/float types should be documented and included in the test coverage. * Binary I/O support that was investigated during development of the Endian library should be put up for mini-review for inclusion in the Boost I/O library. From this point, I will let Beman prepare Endian for the mini-review and I already volunteer to manage the mini-review so informations are not scattered around. Regards

1 0

[tree] more questions (was: [tree] associative containers)
by Cromwell Enage 03 Nov '11

03 Nov '11

From: Erik Erlandson > I'm not entirely sure about the relative merits of that versus defining > a parallel zoology of Hierarchical Containers that is basically > isomorphic to the traditional Container hierarchy, and leaving the > cursor definition more lightweight: perhaps just "iterator plus > parent(), begin() and end()", or alternatively not having a separate > cursor type, and simply having traditional iterators over children at > any given node. I'm curious as to what tree algorithms can take better advantage of the cursor interface as-is. Also: * What are the primary differences between a plain hierarchy and a multiway hierarchy? * Why shouldn't one assume that an on-top cursor is dereferenceable? TIA, Cromwell D. Enage

1 0

[tree] associative containers
by Cromwell Enage 03 Nov '11

03 Nov '11

I've been studying the tree proposal to see how I could write adaptors in my tree_node library (now at version 0.2 in the sandbox) that conform to the current concepts. Is there anything in the proposal that is analogous to a PairAssociativeContainer? My tree_node library defines an AssociativeTreeNode concept and a couple of models that I've found to be useful, e.g. for implementing decision tree learning algorithms. Cromwell D. Enage

2 2

[1.48][math] Permission to merge to release branch
by John Maddock 03 Nov '11

03 Nov '11

I'd like to merge this Clang fix to release if possible: https://svn.boost.org/trac/boost/changeset/75152 The change basically just moves code from one header to another, so it's defined at the point of first use. Thanks, John.

2 2

[BGL] How to provide a vertex_index property for my graph
by ShNaYkHs ShNaYkHs 03 Nov '11

03 Nov '11

Hello, Since my graph use setS as a VertexList, I have to either provide a vertex_index property map for my graph to be able to use some functions requiring a vertex_index (e.g. write_graphviz). My graph is defined as: typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> Graph; Where NodeData and EdgeData are structures. Can you please give me a very simple example of how to provide a vertex_index property map for my graph ? I mean, since an adjacency_list that uses listS or setS as the vertex container does not automatically provide this vertex_id property, how can I add it to the code bellow ? I tried to use an associative_property_map to include index for vertices, but it doesn't work (errors): #include <boost/graph/iteration_macros.hpp> #include <boost/graph/adjacency_list.hpp> using namespace std; using namespace boost; struct NodeData { int label; float influance; /* etc ... */ }; struct EdgeData { int age; /* etc ... */ }; typedef map<vecS, size_t> IndexMap; IndexMap mapIndex; associative_property_map<IndexMap> propmapIndex(mapIndex); typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> Graph; typedef Graph::vertex_descriptor NodeID; typedef Graph::edge_descriptor EdgeID; int main() { Graph g; NodeID n0 = add_vertex(g); g[n0].label = -1; NodeID n1 = add_vertex(g); g[n1].label = -1; EdgeID edge; bool ok; tie(edge, ok) = boost::add_edge(n0, n1, g); if (ok) g[edge].age = 10; int i=0; BGL_FORALL_VERTICES(v, g, Graph) { put(propmapIndex, v, i++); } return 0; } Thanks for answer.

2 3

Boost.Algorithm design question
by Marshall Clow 03 Nov '11

03 Nov '11

So, what do people prefer (and why?): template<typename InputIterator, typename V> bool none_of_equal ( InputIterator first, InputIterator last, V const &val ) { for ( ; first != last; ++first ) if ( val == *first ) return false; return true; } or template<typename InputIterator, > bool none_of_equal ( InputIterator first, InputIterator last, iterator_traits<InputIterator>::value_type const &val ) { for ( ; first != last; ++first ) if ( val == *first ) return false; return true; } In the first case, I think there's (possible) conversion from V to iterator_traits<InputIterator>::value_type each time through the loop. In the second case, there is not. Of course, the (mythical?) smart compiler would do the conversion once and save the result for reuse. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

17 79

[1.48.0 Beta 1][fusion] MacTypes.h conflict with nil
by Jeff Flinn 03 Nov '11

03 Nov '11

reposted from "[1.48.0] Beta 1 is now available from SourceForge" thread for better visibilty. Mac 10.6 Xcode 3.2.6 gcc 4.2: In compiling our application, upgrading from boost_1_44_0 I get conflicts with MacTypes.h define of nil when compiling cons_fwd.hpp from fusion. Any thoughts? Jeff

3 3

Interest in boost.deepcopy
by Allan Johns 02 Nov '11

02 Nov '11

Just gauging initial interest in a boost.deepcopy library, analogous to deepcopy in python. Each type would register deepcopy behaviour with the library (there are similarities to boost.serialize). Boost.deepcopy would supply out-of-the-box registration for pod types, pointer types, arrays, stl containers and common boost containers. Example: template<typename T> void deepcopy(deepcopycontext& ctxt, const T& obj) { ...; } Why not use boost::serialize and serialize into memory then out again I hear you say? That's a great approach, but only when every object requires the same deepcopy behaviour (also, it's not too optimal). The problem is, I need specific behaviour in some types. Specifically, I need copy-on-write behaviour for a Buffer class that I'm using. For example: void deepcopy(deepcopycontext& ctxt, const Buf& b) { if(!ctxt.contains(&b)) { Buf b2(b); // doesn't copy the buf data, just holds a shared ptr internally. Data is only cloned when b/b2 is written to ctxt.insert(&b, b2); } } I attempted to model this a while ago using boost.serialize, but it turned out pretty clunky, I started needing a few decorator classes for special cases, etc. Apologies for the oversimplified examples above, just wanting to get interest in the jist of it. Please let me know if this overlaps with existing boost functionality also (I'm not aware of anything atm). Feedback appreciated. Thx, Allan

9 18

[ratio] Request for permission to merge to release branch
by Vicente J. Botet Escriba 02 Nov '11

02 Nov '11

Hi, I want to merge https://svn.boost.org/trac/boost/changeset/75240 to the release branch. The modifications are minor and correct to tickets: https://svn.boost.org/trac/boost/ticket/5724 and https://svn.boost.org/trac/boost/ticket/6082. Best, Vicente

3 3

[multi_array] Ticket#4874 "multi_array compile errors using Visual C++ 2010 in debug mode"
by Stephan T. Lavavej 02 Nov '11

02 Nov '11

Hi Boost devs, VC10 users are occasionally encountering https://svn.boost.org/trac/boost/ticket/4874 and reporting it to MS. For example, see http://connect.microsoft.com/VisualStudio/feedback/details/687655/compilati… where I've explained what's going on (I wrote this analysis back in Feb 2010 and I believe it's still correct): The problem is that multi_array iterators report themselves as input iterators, which can't be written to (e.g. as the destination of a copy()). Under IDL=0, copy() doesn't actually care how its destination iterator is marked with an iterator category tag, it just tries to write to the destination iterator, and that works. Under IDL > 0, copy() wants to know whether its source and destination iterators are both random-access, in which case it can perform a range check and unwrap the destination iterator for increased performance. It does this by overloading foo(input_iterator_tag, output_iterator_tag) and foo(random_access_iterator_tag, random_access_iterator_tag) and calling foo(category(source), category(destination)). If both source and destination are random-access, both overloads are viable (i.e. callable) and the second overload is preferred, so it's actually called. Otherwise, source is required to be at least an input iterator (maybe stronger) and destination is required to be at least an output iterator (maybe stronger) so the first overload must be viable and the second overload will be non-viable, so the first overload wins by default. However, if the destination is not marked as an output iterator or stronger, then the first overload is non-viable as well as the second, so overload resolution fails and boom. Thanks, Stephan T. Lavavej Visual C++ Libraries Developer

2 1

boost mapped_file issue
by dophine 02 Nov '11

02 Nov '11

Hi all, I try to use memory map file. However, I don't know why the readsome return 0. It is fine if I use getline. int main(int argc,char *argv[]) { boost::iostreams::mapped_file_source source(argv[1]); boost::iostreams::stream<boost::iostreams::mapped_file_source> input(source); while(!input.eof()) { char b[1]; streamsize iRet = input.readsome(b, 1); cout << iRet << endl; cout << b[iRet]; } //std::string line; //while(std::getline(input, line)) { // std::cout << "Line: " << line << std::endl; //} return 1; } -- View this message in context: http://boost.2283326.n4.nabble.com/boost-mapped-file-issue-tp3971495p397149… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[locale] Premission to merge clang bugfix changeset to release tree
by Artyom Beilis 02 Nov '11

02 Nov '11

Hello, I'd like to ask a permission to merge a changeset 75174 from trunk to release tree. It is a fix of build issue under clang-2.9 and clang-3.0. See: https://svn.boost.org/trac/boost/changeset/75174 The changeset itself: ------------------------- Index: /trunk/libs/locale/src/posix/codecvt.cpp =================================================================== --- /trunk/libs/locale/src/posix/codecvt.cpp (revision 73382) +++ /trunk/libs/locale/src/posix/codecvt.cpp (revision 75174) @@ -135,5 +135,5 @@ // maybe illegal or may be double byte - char inseq[3] = {seq0 , begin[1], 0}; + char inseq[3] = { static_cast<char>(seq0) , begin[1], 0}; char *inbuf = inseq; size_t insize = 3; ------------------------- It solves build issues as I can see at trunk tests. Thanks, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

3 2

[atomic] comments
by Tim Blechmann 01 Nov '11

01 Nov '11

hi helge and others, ... has been rather quiet about the boost.atomic review, so i want to raise a view issues: shared memory support: the fallback implementation relies on the spinlock pool that also used by the smart pointers. however this pool is per-process, so the fallback implementation won't work in shared memory. can this be changed/fixed? atomic::is_lock_free(): is_lock_free is set to either `true' or `false'. however in some cases, there are alignment constraints (iirc, 64bit atomics on ia32/x86_64 require a 64bit alignment). afaict there are not precautions to take care of this, are there? compile-time vs run-time dispatching: some instructions are not available on every CPU of a specific architecture. e.g. cmpxchg8b or cmpxchg16b are not available on all ia32/x86_64 cpus. i would appreciate if these instructions would not be used before performing a CPUID check, whether these instructions are really available (at least in a legacy mode) cmpxchg16b: currently cmpxchg16b doesn't seem to be supported. this instruction is required for some lock-free data structures (e.g. there is a dequeue algorithm, that requires a pair of tagged pointers). maybe this can be a starting point to discuss boost.atomic ... cheers, tim

6 38

Re: [boost] [atomic] comments
by Helge Bahmann 01 Nov '11

01 Nov '11

> > > > > e.g. i would not trust on accessing sockets from a > > > > > real-time thread. > > > > > > > > what makes you believe that message channels in real-time systems > > > > were > > > > designed so dumb as to make them unusable for real-time purposes? > > > > > > life would be so much easier for me, if the users of my software would > > > not run on off-the-shelf operating systems ;) > > > > and what makes you believe that the performance characteristics of > > sockets in off-the-shelf operating systems is unsuitable for real-time, > > while the process scheduling characteristics of process scheduling in > > off-the-shelf operating systems is suitable for real-time? > > i cannot comment on windows, but both osx and linux provide ways to > schedule a thread at a priority that it won't be preempted by any other > thread, so the process scheduler won't interfere. that answers the second part but not the first (and is getting off-topic from atomic operations) > > > > right, but the standard implementation for gcc does not use a > > > > spinlock > > > > per object (see __atomic_flag_for_address) which turns all of this > > > > moot - there is NO guarantee for std::atomic to be safe > > > > interprocess, period> > > > > > > well, i'd say this is a problem of gcc's implementation of std::atomic. > > > this doesn't justify that boost.atomic does not follow the suggestion > > > of the standard. > > > > the standard says "should" not "must" -- the gcc guys have not made this > > decision without good reasons, and I agree with these reasons > > > > note that there is also trouble lurking with run-time selection of > > whether something like atomic<uint64_t> is atomic via cmpxchg8b: do you > > really want to make this at minimum 12 bytes in size (though effectively > > occupying 16 due to alignment) just to save the room for the > > rarely-if-ever used per-object spinlock? same with atomic<128> and > > cmpxchg16b ? > > i don't really care about the size of an atomic<>. but I *do* care and believe it or not there are people writing applications that are memory-bound (doubling the overhead of the reference count in each of several millions of objects is *not* funny) > one other point for > runtime selection is compatibility. e.g. you may have two binaries, one is > compiled with support for double-width CAS, the other one without. with > compile-time dispatching the behavior would be undefined, with run-time > selection, it would be handled gracefully ... I don't quite understand the point -- quite obviously nothing good will happen if the applications do not agree on a protocol, and there is nothing that can be salvaged if they do agree on the objects being lock-free, fine if they do agree on the objects not being lock-free, well then explicit locking is faster anyways and you should use your "locked" reference implementation of the data structure that you surely wrote to run suitable regression tests of your lock-free data structure > > 2. What is wrong with implementing boost::interprocess::atomic<T> that > > specializes to boost::atomic<T> when possible and uses an interprocess > > lock otherwise? > > will you provide an implementation? people were asking for > boost::interprocess support during the boost.lockfree review. the only > missing feature is the atomic<> implementation. no problem Best regards Helge

1 0

[config] clang.hpp is not up-to-date
by Michel Morin 01 Nov '11

01 Nov '11

boost/config/compiler/clang.hpp is not up-to-date. For example, BOOST_NO_AUTO_DECLARATIONS is *always* defined (even if clang supports this feature). Is it worth fixing this on the release branch? P.S. I can make a patch, but before doing that I'd like to confirm whether __has_feature(cxx_auto_type) means that multi-declarator auto is supported or not. The following page says nothing about multi-declarator auto. http://clang.llvm.org/docs/LanguageExtensions.html Doug? Regards, Michel

3 4

Silly Boost.Locale default narrow string encoding in Windows
by Alf P. Steinbach 01 Nov '11

01 Nov '11

When I engage the compiler-in-my-mind to the example given at http://cppcms.sourceforge.net/boost_locale/html/ namely <code> #include <boost/locale.hpp> #include <boost/filesystem/path.hpp> #include <boost/filesystem/fstream.hpp> int main() { // Create and install global locale std::locale::global(boost::locale::generator().generate("")); // Make boost.filesystem use it boost::filesystem::path::imbue(std::locale()); // Now Works perfectly fine with UTF-8! boost::filesystem::ofstream hello("שלום.txt"); } </code> then it fails to work when the literal string is replaced with a `main` argument. A conversion is then necessary and must be added. It breaks the principle of least surprise. It breaks the principle of not paying for what you don't (want to) use. I understand, from discussions elsewhere, that the author(s) have chosen a narrow string encoding that requires inefficient & awkward conversions in all directions, for political/religious reasons. Maybe my understanding of that is faulty, that it's no longer politics & religion but outright war (and maybe that war is even over, with even Luke Skywalker dead or deadly wounded). However, I still ask: why FORCE INEFFICIENCY & AWKWARDNESS on Boost users -- why not just do it right, using the platforms' native encodings. Cheers, - Alf

9 43

[unordered] 1.48 beta1 fails to compile with MSVC 2010 SP 1, error C2027: use of undefined type 'boost::type'
by Johan Lindvall 01 Nov '11

01 Nov '11

After trying out beta 1, I am seeing some failures with unordered containers, see attached file. Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64 The code compiles without problems under 1.47.0. Unfortunately, I cannot yet publish the source code that triggers this problem. Any hints where to start investigating this? -- /Johan.

2 5

[multi_array] typed subarray from raw memory
by Maxim Yanchenko 01 Nov '11

01 Nov '11

Hi, While using multi_array, I found I frequently need a way to view some memory which is a multi-dimensional array and I don't know the type of the element, but I know its size and I know that this element has a member of the type I need (and I know the offset). So I need to be able to write something like struct A { double x, y; }; void* p = mmap(...); size_t el_size = size_of_element_in_p; size_t offset = offset_of_A_inside_element; boost::multi_array_typed_view<A, NumDims> my_view(p, extents, el_size, offset ); and have a standard multi_array-compatible interface. Also, with existing multi_arrays of known types, this feature will give a way to create views of element's members (the closest we have now is a strided view but it only works if the element size is a multiple of the member size). I filed a Feature Request for multi_array (https://svn.boost.org/trac/boost/ticket/6073) but I wonder if there are any other possibilities around, and I'd also like to know what the community think of necessity of this feature. Thanks, Maxim

1 0

Re: [boost] [Tokenizer] Compile error with lots of missing binary operator statments
by Collin Day 31 Oct '11

31 Oct '11

Previously, I had posted what I thought was a bug. I did not think to do this originally, but I just tried a simple Hello World program that included boost/tokenizer.hpp. It compiled fine. I then looked at where the sample code was pulling headers from, and it appears that the download included old boost headers it was including instead of 1.47.0. I completley missed this. I apologize - and take back the error - there is none :) Thanks!

1 0

[Tokenizer] Compile error with lots of missing binary operator statments
by Collin Day 31 Oct '11

31 Oct '11

Hi all, make[1]: Entering directory `/home/collin/projects/Cpp/plugins/PluginFramework/projects/plugin_framework' mkdir -p build/Debug/GNU-Linux-x86 g++ -c -g -DPF_PLATFORM_LINUX -DAPR_DECLARE_STATIC -DAPU_DECLARE_STATIC -I../../include/ -I../../include/darwin86 -I.. -o build/Debug/GNU-Linux-x86/Path.o Path.cpp In file included from ../../include/boost/mpl/apply.hpp:23:0, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token "(" ../../include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token "(" In file included from ../../include/boost/mpl/bind.hpp:27:0, from ../../include/boost/mpl/lambda.hpp:18, from ../../include/boost/mpl/apply.hpp:25, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token "(" ../../include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token "(" In file included from ../../include/boost/mpl/lambda.hpp:18:0, from ../../include/boost/mpl/apply.hpp:25, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/bind.hpp:364:31: error: missing binary operator before token "(" ../../include/boost/mpl/bind.hpp:531:31: error: missing binary operator before token "(" In file included from ../../include/boost/mpl/lambda.hpp:22:0, from ../../include/boost/mpl/apply.hpp:25, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/aux_/full_lambda.hpp:230:31: error: missing binary operator before token "(" In file included from ../../include/boost/iterator/iterator_facade.hpp:34:0, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/apply.hpp:138:31: error: missing binary operator before token "(" make[1]: *** [build/Debug/GNU-Linux-x86/Path.o] Error 1 make[1]: Leaving directory `/home/collin/projects/Cpp/plugins/PluginFramework/projects/plugin_framework' make: *** [.build-impl] Error 2 I looked on the web, and everything that looks remotley like this said it was a problem with GCC > 4.4, but was fixed in boost 1.37. I have tried with both gcc 4.4.6 and 4.5.3. I don't think I am missing anything since it is just an include file, but I could be wrong. any help would be appreciated. I tried the boost users mailing list with no luck after a couple of days. This is a more detailed example - it looks as though the same problem repeats for many files. Would it be appropriate to file a bug if I can't find any answers here? Thanks!

1 1

[math][distributions] superfluous checking of parameters?
by Thijs (M.A.) van den Berg 31 Oct '11

31 Oct '11

The boost math distributions check validity of distribution the same parameters multiple times. E.g. in normal.hpp, class normal_distribution, the constructor, normal_distribution(RealType mean = 0, RealType sd = 1) : m_mean(mean), m_sd(sd) { // Default is a 'standard' normal distribution N01. static const char* function = "boost::math::normal_distribution<%1%>::normal_distribution"; RealType result; detail::check_scale(function, sd, &result, Policy()); detail::check_location(function, mean, &result, Policy()); } however, those are *again* checked in e.g. the pdf() non member function inline RealType pdf(const normal_distribution<RealType, Policy>& dist, const RealType& x) { ... if(false == detail::check_scale(function, sd, &result, Policy())) { return result; } ... } Why is that? It's done in a consistent way across all distributions. Can we remove the check inside the non member functions that are already checked in the constructor?

3 7

[proto] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Joel de Guzman 31 Oct '11

31 Oct '11

Hi, This code: #include <boost/spirit/include/qi.hpp> int main() { namespace qi = boost::spirit::qi; qi::rule<char const*> r; r %= (+qi::char_); return 0; } no longer works as expected. r %= (+qi::char_) becomes a no-op. Before it calls either: template <typename Expr> friend rule& operator%=(rule& r, Expr const& expr); // non-const version needed to suppress proto's %= kicking in template <typename Expr> friend rule& operator%=(rule& r, Expr& expr); Both defined in the rule class. Correct me if I'm wrong, but it seems the changes in proto forces us to support rvalue refs, but we are not ready for that yet and it's too late in the release cycle. Thoughts? Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com

4 4

[c++1] BOOST_NOEXCEPT macros?
by Beman Dawes 31 Oct '11

31 Oct '11

Since Boost already has BOOST_NO_NOEXCEPT and at least one compiler (GCC) supports C++11 noexcept, I'd like to start using it in Boost code. So how about a <boost/detail/noexcept.hpp> header with the usual boilerplate and this: #ifndef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT # define BOOST_NOEXCEPT_IF(Predicate) #else # define BOOST_NOEXCEPT no_except # define BOOST_NOEXCEPT_IF(Predicate) no_except(Predicate) #endif As was pointed out in a previous thread, there isn't any reliable C++03 alternative for either of these two, so nothing is attempted, and that's OK in C++03 code. We could also define BOOST_NOEXCEPT_OPERATOR(Predicate), and have it fall back to true in C++03 code. I'm not expert enough to know if that is reliable or even useful, so am not proposing it. Comments? --Beman

12 37

[interprocess] native Windows cond_var + mutex
by Dan Brown 31 Oct '11

31 Oct '11

Hi, Attached is a patch to implement interprocess_condition and interprocess_mutex natively on Windows. Following are some detailed notes. I hope this isn't too awkward of a time for a submission like this - I realize there's a lot of 1.48 activity going on. One more note about the patch - IIRC, some patch utils won't create directories. This patch is intended to be applied to boost/interprocess and relies on a new directory boost/interprocess/sync/win32. Background I started out by looking at http://www.cs.wustl.edu/~schmidt/win32-cv-1.html. This appears to be from the late '90s and is the basis for ACE's cond_var implementation. The solution in section 3.4 is arguably the most correct implementation. However, this solution relies on the atomicity of SignalObjectAndWait(). SOAW() may have been atomic for unicore systems common at the time but from what I've read is not atomic for multicore (it prevents context switches on a single core but ignores concurrent threads on other cores), and win32 documentation backs this up. While the paper argues that this leads to unfairness, I don't think the solution is correct without this atomicity. Wait/signal/wait problem One problem that I came across is what I'll call the wait/signal/wait problem. Setting the state, thread 1 is waiting on a condition and thread 2 has just completed cond_signal. Without an atomic SOAW(), thread 1 may release the external mutex without obtaining the associated semaphore. Another thread, thread 3, may obtain the external lock and find the cond_var signaled and behave correspondingly. This I believe is incorrect - a waiter which obtains the external mutex after the signaler has exited signal()should not find cond_var signaled. This situation is unlikely but it makes assumptions about the scheduler that I am not comfortable with. If there's a flaw in my reasoning hopefully someone will point that out. This solution This solution is structurally somewhat similarly to the paper's solution. One point to note is that notify_one()/signal() blocks on an event in the same manner as notify_all()/broadcast(). There may be a solution which does not block the signaler while wake-processing is occurring, but I saw additional complexity on that path and decided to forgo it for the time being. I hope the solution is correct but have only testing to validate. I haven't used any formal methods to back it up. Maybe I'll construct a Petri net sometime. That's always .. fun. I throw this solution on the mercy of the court. External mutex I have yet to see production examples of cond_var use where signalers do not hold the external mutex while they signal, but this use case is allowed by POSIX. My original solution (if it is in fact a solution) relies on some particular external mutex being held by all waiters and signalers for some particular condition variable. I recently added two mutexes to solve that situation but I have only minimal testing experience with that recent addition. Use of these new locks is demarcated with WIN32_POSIX_SEMANTICS. Interprocess vs. Intraprocess I'm not sure if there is support for process-specific synchronization objects in boost.interprocess, but if support is present or was added at some future time this could help optimize things for win32. At the moment win32 interprocess mutexes rely on assigning random names to mutexes (only named mutexes can cross platform boundaries in win32), and all mutex operations have to look up the mutex by this name. Interprocess seems to have been designed primarily with pthreads in mind, and things get a little awkward on Windows in this regard. Similarly, it would be nice to be able to use the native condition variables that win32 added for Vista+, but these can't be used across processes according to the documentation, and so can't be used AFAICT for inteprocess_condition. Correspondingly, an intraprocess_mutex would be able to forgo the win32 mutex name lookups. Miscellaneous Not all interprocess tests currently pass. There are some additional variations of mutex like the upgradable/sharable, etc., that I haven't looked at in detail. I'm hoping that this patch goes far enough that it'll have some momentum. I'm happy to either complete this work in the future or help whoever undertakes the task, but I may not be able to justify much of my time to the task in the short term to my employer. I realized a little too late that I didn't keep formatting entirely consistent with the existing code. Apologies. Hopefully it's only the opening block curlies. Thanks. Dan

3 13

[C++ Now! 2012] Call for Submissions
by Brian Wood 30 Oct '11

30 Oct '11

Hartmut Kaiser: > The C++ Now! Conference is dedicated to discussion and education > about C++, an open and free language and standard. It costs a lot to buy a copy of the standard now! Hope conference goes well and maybe I can attend someday. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

[BGL] How to provide a vertex_index property for my graph
by ShNaYkHs ShNaYkHs 30 Oct '11

30 Oct '11

Hello, Since my graph use setS as a VertexList, I have to either provide a vertex_index property map for my graph to be able to use some functions requiring a vertex_index (e.g. write_graphviz). My graph is defined as: typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> Graph; Where NodeData and EdgeData are structures. Can you please give me a very simple example of how to provide a vertex_index property map for my graph ? I mean, since an adjacency_list that uses listS or setS as the vertex container does not automatically provide this vertex_id property, how can I add it to the code bellow ? I tried to use an associative_property_map to include index for vertices, but it doesn't work (errors): #include <boost/graph/iteration_macros. hpp> #include <boost/graph/adjacency_list.hpp> using namespace std; using namespace boost; struct NodeData { int label; float influance; /* etc ... */ }; struct EdgeData { int age; /* etc ... */ }; typedef map<vecS, size_t> IndexMap; IndexMap mapIndex; associative_property_map<IndexMap> propmapIndex(mapIndex); typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> Graph; typedef Graph::vertex_descriptor NodeID; typedef Graph::edge_descriptor EdgeID; int main() { Graph g; NodeID n0 = add_vertex(g); g[n0].label = -1; NodeID n1 = add_vertex(g); g[n1].label = -1; EdgeID edge; bool ok; tie(edge, ok) = boost::add_edge(n0, n1, g); if (ok) g[edge].age = 10; int i=0; BGL_FORALL_VERTICES(v, g, Graph) { put(propmapIndex, v, i++); } return 0; } Thanks for answer.

1 0

[C++ Now! 2012] Call for Submissions
by Hartmut Kaiser 30 Oct '11

30 Oct '11

INAUGURAL C++ NOW! CONFERENCE 2012 Aspen CO, USA, May 14-18, 2012, www.cppnow.org CALL FOR SUBMISSIONS We invite you to submit session proposals to the Inaugural C++ Now! Conference: C++Now! 2012 (Aspen CO, USA, May 14 - 18, 2012). Based on the successful traditions of 5 years of BoostCon, which was the main face-to-face event for all things C++ and Boost (www.boost.org) C++Now! 2012 will present leading speakers from the whole C++ community. The conference name is changing to C++ Now! to reflect the current value of the language, the focus on its new state (from the new Standard), and the need to continually look to the future so the language remains useful to the C++ community. The focus of this conference will be the new C++11 language Standard and as usual Boost: what's new in C++, its Standard library, and in the Boost libraries, how to write and maintain them, how to evangelize or to deploy Boost within your organization. The new C++ Standard, but also the infrastructure and process of Boost, its vision and mission - no matter what you are interested in, it all comes together in the C++Now! sessions. Meet the colleagues, and feel the inspiration to support your work with C++ and Boost for the next year. The C++ Now! Conference is dedicated to discussion and education about C++, an open and free language and standard. Our Conference will focus on discussion and education about open source software usage and developments in the C++ developer and user community. To reflect the breadth of the C++ and Boost communities, the conference includes sessions aimed at three constituencies: C++ and Boost end-users, hard-core Boost library and tool developers, and researchers pushing the boundaries of computation. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. As a multi-paradigm language, C++ is a melting pot where the most compelling ideas from other programming communities are blended in powerful ways. Historically, some of the most popular sessions at C++Now! have highlighted these concepts, from DSLs to functional programming to transactional memory and more. Bring your C#, Python, Ruby or Haskell influences to bear in an environment that will broaden their exposure. IMPORTANT DATES New proposal submissions due: January 10th, 2012. Proposals decisions sent (tentative program available): February 17th, 2012. Fully scheduled program available: February 25th, 2012. Session materials due: April 15th, 2012. BEST PRESENTATION AWARDS We know how much effort it takes to prepare talks for our conference. For this reason we will award the best presentations in the following categories: Best Presentation, Best Short Presentation, Best Tutorial, and Best Workshop. The awards will be given based on the audience's voting. Each award will include the author's name listed on the cover of the C++Now! website for that year and a plaque containing all the C++Now! conference information. SESSION TOPICS Topics of interest include, but are not restricted to, the following: * C++11 and how it changes life for users and library writers * General tutorial sessions on C++11, the C++11 Standardslibrary, and one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to C++11, Boost and users. Panels Panels feature three or four people presenting their ideas and experiences relating to C++11 and Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific skills relevant to C++11 and Boost. Workshops Workshops provide an active arena for advancements in Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner These were introduced at BoostCon 2008, and were a great Presentations success They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors We actively encourage tool vendors and ISP's to submit Presentations proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL Standard Sessions are 60 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 60 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10- 20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). SUBMISSION DETAILS All submissions should be made through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=cppnow2012. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the C++Now! website and will be available to attendees. For general information on the C++Now! 2012 paper submission or the scope of technical papers solicited, please refer to the conference website at www.cppnow.org. For any other questions about the submission process or paper format, please contact the Program Committee at cppnow2012(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to C++ Now!. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) Dave Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0