November 2011 - Boost - lists.boost.org

[concept_check] Some issues
by Robert Kawulak 23 Dec '11

23 Dec '11

Hi, I've spotted some problems when playing with BCCL: - The implementation of assignable_archetype defines private default and copy constructors, so for example assignable_archetype<copy_constructible_archetype<>> will not actually be copy constructible. The same for convertible_to_archetype and convertible_from_archetype, but additionally with copy assignment. Is this by purpose? - copy_constructible_archetype defines public default constructor - again, am I overlooking something or it should not be there? - Function and predicate archetypes also seem to provide too wide interface (they are copy constructible and assignable). Additionally, they don't allow for archetypes chaining since they lack the Base parameter (with the only exception of binary_predicate_archetype - why the inconsistency?) - Apart from the provided function object concepts and archetypes it seems it would be useful to have a general Callable concept and the corresponding callable_archetype, parameterised with the types of arguments and return value. Wouldn't it be valuable to add them? - There's boost/concept_check directory in the trunk - are the files in it actually used anywhere? I've found no reference to them in Boost headers, documentation doesn't mention them too. Best regards, Robert

3 10

boost and google search
by Edward Rankin 23 Dec '11

23 Dec '11

Hi, I am sure it is pretty common for users of boost to use google to search for documentation/tutorials on their favorite library in boost. I have found that the top hits are typically not the latest documents. For example I just searched for boost,foreach and a documentation from 1.35 was the first hit. It would be great if there is a way to tell google to update their links to the latest version. Anyone knows whether this is possible, and how to make it happen? This problem probably applies to any search engine but I can only comment on google search. Thanks, Edward

11 23

[1.48.0] Beta 1 release candidates available
by Beman Dawes 20 Dec '11

20 Dec '11

Release candidate files for 1.48.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers

21 44

Boost Iterator Library - small extension proposal
by Detlef Wilkening 18 Dec '11

18 Dec '11

Hello Boostler, at first, excuse my english - I am not a native speaker. I used sometimes the Boost.Iterator library - especially the filter iterators. I like them much, but I don't like the work to create the iterator objects. --- Example: struct IsEven { inline bool operator()(int n) const { return n%2==0; } }; vector<int> v; IsEven iseven; filter_iterator<IsEven, vector<int>::iterator> filter_iter_begin(iseven, v.begin(), v.end()); filter_iterator<IsEven, vector<int>::iterator> filter_iter_end(iseven, v.end(), v.end()); --- My first problem is, that I need 3 times "v.end()" and 2 times "iseven". And the type is very long. I don't think, that the "make" functions makes it much better. I use "auto" from C++11 in this example, to make it a little bit shorter. --- Example: struct IsEven { inline bool operator()(int n) const { return n%2==0; } }; vector<int> v; IsEven iseven; auto filter_iter_begin2 = make_filter_iterator<IsEven>(v.begin(), v.end()); auto filter_iter_end2 = make_filter_iterator<IsEven>(v.end(), v.end()); --- Again I need 3 times "v.end()" and 2 times the type "IsEven". And the type is again very long - thanks to "auto" in C++11. My second problem is, that both use cases don't work well with lambda expressions in C++11. For "make" I need the type of the lambda, which I don't have - and I need it 2 times. And in the first solution I must write the lambda expression 2 times, which is not good. Perhaps there are some other solutions, wich I don't see - than please explain them to mee. ----- My proposal is a new "make" function, which is easer to use (only 1 time "v.end()") and works well with lambda expressions, but has furthermore a stupid type - but in C++11 with "auto" that doen't matter. --- template<class Iter, class Fct> pair<filter_iterator<Fct, Iter>, filter_iterator<Fct, Iter>> make_filter_iterators(Iter begin, Iter end, Fct fct) { filter_iterator<Fct, Iter> filter_iter_begin(fct, begin, end); filter_iterator<Fct, Iter> filter_iter_end(fct, end, end); return pair<filter_iterator<Fct, Iter>, filter_iterator<Fct, Iter>> (filter_iter_begin, filter_iter_end); } Usage: vector<int> v; auto iters = make_filter_iterators( v.begin(), v.end(), [](int n){ return n%2==0; }); copy(iters.first, iters.second, ostream_iterator<int>(cout, " ")); --- You see, with "auto" easy to use, and work well with lambda expressions. My proposal is to add such a "make" function to all iterator adaptors in Boost.Iterator. Thank you for reading my idea. Greetings Detlef Wilkening

3 3

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

18 Dec '11

On 24 Nov 2011 09:11:19 Joel de Guzman wrote: >Man! Of course you should use the examples in 1.45. Those examples >are for 1.48 and uses new features implemented in 1.48! Sheesh! I fully understand that. The point is that the Phoenix interface is evolving much more quickly than that of probably any other Boost library. Even apart from the fact that there already have been two bottom-up rewrites, there are enough significant changes between point releases that even small example programs are tied to a particular version of the library. Why is the optimal way to write a small calculator example today so different from the optimal way to write it six months ago? I'm not disputing that you're making forward progress, just highlighting this as another barrier to entry that Local likely won't have. >Double Sheesh! If you've spent even a few seconds looking into the >error (beyond fault-finding), you will see that a simple textual >search of "error" will reveal this: Yes, it's possible to wade through the error messages and figure out what went wrong. And Qi is clearly trying to help out with traceable assertions; that may well be the best we can do. But no reasonable person would claim that hundreds of lines of error message, mostly filled with types that the user never directly constructed, are the most desirable way to report a simple syntax error. This problem is endemic to all ET libraries and compilers, and it would be very, very hard to do much better. Again, though, I think you're underselling this as a barrier to entry. How many people would ever learn C++ if all libraries did this? >Now having said that, and before I leave this thread, let me remind >everyone that **you can also have statement syntax in Phoenix** if you >have a complex statement and you fear writing complex phoenix lambda >expressions. It's called phoenix::functions. The important issue here isn't just statement /syntax/, it's that we have options available that don't turn what looks like an ordinary C++ statement into a massive AST with its own mini-compiler behind the scenes.

18 38

Standard library Technical Report 2 proposals for Boost libraries
by Beman Dawes 17 Dec '11

17 Dec '11

The C++ committee hasn't decided whether to do a TR2 or to move directly on to the next standard. Either way, there will be a call for library proposals, but the details will be up in the air at least until the next meeting, which will be in Kona, Hawaii, in February. For the moment, the term "TR2" is being used as a surrogate for moving the standard library forward regardless of exact details. In discussions, library working group (LWG) members have made it clear they want a filesystem library based on Boost.Filesystem, and a networking library based on Boost Asio. Individual members of the committee have voiced interest in other Boost libraries, large and small. If you are a Boost developer (or user), and there is a Boost library you would like to see proposed for TR2, now is a good time to start thinking about writing a preliminary proposal to the committee. The point of such a proposal is to gauge interest before putting in a lot of work on a full-blown proposal only to find the LWG isn't interested. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html for the original TR2 call for proposals. While the details will change, it is still a reasonable introduction to what is required. A preliminary proposal would just say "To be supplied" for the "Proposed Text for the Standard" section. It is very helpful to do at least the initial presentation of such a proposal in person. That said, John Maddock and Peter Dimov had many proposals accepted for TR1 without ever attending a standards committee meeting. If you don't plan to present a proposal in person, the best bet is to ask someone who is familiar with the library to present it. Feel free to contact me publicly or privately with questions about proposals or information about attending committee meetings, --Beman

7 18

[local] "true" lambdas without C++11 but only on GCC
by Lorenzo Caminiti 17 Dec '11

17 Dec '11

Hello all, A curiosity: On GCC compilers (but _only_ on GCC compilers) it is possible to combine Boost.Local and the non-standard GCC "expression statements" feature to implement lambda functions. In other words, it is possible to define a Boost.Local closure within a GCC expression statement: std::vector<int> v(3); v[0] = 1; v[1] = 2; v[2] = 3; int factor = 10; std::for_each(v.begin(), v.end(), LAMBDA(int x, const bind& factor) { std::cout << x * factor << std::endl; } LAMBDA_END ); This is just a curiosity because it is NOT standard C++03 and it will ONLY work with GCC compilers. #include <boost/local/function.hpp> #include <vector> #include <algorithm> #include <iostream> // WARNING: This macros only work on GCC!!! #define LAMBDA_WITH_RESULT(result_type, ...) \ ({ /* open GCC statement expression */ \ result_type BOOST_LOCAL_FUNCTION_PARAMS(__VA_ARGS__) #define LAMBDA(...) \ LAMBDA_WITH_RESULT(void, __VA_ARGS__) #define LAMBDA_END \ BOOST_LOCAL_FUNCTION_NAME(BOOST_PP_CAT(lambda, __LINE__)) \ BOOST_PP_CAT(lambda, __LINE__); \ }) /* close GCC statement expression */ int main() { std::vector<int> v(3); v[0] = 1; v[1] = 2; v[2] = 3; int factor = 10; std::for_each(v.begin(), v.end(), LAMBDA(int x, const bind& factor) { std::cout << x * factor << std::endl; } LAMBDA_END ); return 0; } I might mention this code example as a curiosity in Boost.Local docs, currently it's not mentioned there. Thanks. --Lorenzo

2 3

New libraries implementing C++11 features in C++03
by Jeffrey Lee Hellrung, Jr. 17 Dec '11

17 Dec '11

Within the discussion for the review of the proposed Boost.Local library, Hartmut Kaiser raised a concern that I think should be addressed more broadly by the community, if possible. I quote Hartmut: > Ok. However this raises a more serious question. Should we as the > Boost community still encourage solutions and libraries solely for > portability with ancient compilers? I'd say no, but YMMV. Boost will > be still around 2, 5, or 10 years from now. What's the utility of > adding such a _solely_ backwards oriented library from this POV? Indeed, I ask the community, do such libraries belong in Boost? If so, is the bar for acceptance of such libraries automatically and necessarily higher than libraries that introduce genuinely new capabilities in C++11? If so, what additional criteria must such a library meet? I add two additional notes to help put the discussion in context: - Within the proposed Boost.Local review discussion, several individuals pointed out that they will likely have to work professionally on C++03 compilers for at least a few more years. - Recall that Boost has several (recent) libraries that could easily be labelled as "transitional" libraries: Move, Atomic (at least proposed, not sure if accepted), Container. Further, several older libraries are now part of the C++11 standard (e.g., Thread (right?)). - Jeff

20 45

[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

[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

[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

[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

[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

[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

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

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

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