- Boost - lists.boost.org

Is it time for another bug sprint? (Post 1.45 release, I mean)
by Marshall Clow 30 Oct '10

30 Oct '10

What do people think? -- Marshall

11 17

[regex] Disabling ICU check when building with bjam, 1.44
by Cliff Green 30 Oct '10

30 Oct '10

This is on Boost 1.44, g++ 4.1.2 on Linux (RHEL 5.x, can't remember the x at the moment), although it applies generally to building regex. I can't find a way to easily "disable" the "ICU installed" check and resulting functionality / build. I chatted on IRC, and the only way some (experienced Boost) developers could come up with was to change: alias icu_options : : : : [ check-target-builds has_icu : $(ICU_OPTS) : ] ; to alias icu_options : : : : ; in Jamfile.v2. My situation / use case: Our build system has ICU installed. Our deployment system has exactly the same OS and runtime environment, except that the ICU package is not installed. I would like to build regex without the "check that ICU is installed to determine whether the enable ICU" logic in the jamfiles. The regex documentation has an: "-sHAVE_ICU=1" example, but "-sHAVE_ICU=0" doesn't work, and tracing through the jamfiles / boost build I couldn't find where that option is honored / processed. There's also a BOOST_HAS_ICU macro that is defined or undefined in various ways, but adding define=BOOST_HAS_ICU 0 to bjam also didn't appear to do anything (and I tried some other ways to undefine BOOST_HAS_ICU, including in the jamfile, but nothing seemed to work). The docs also mention that the default is to not enable / build with ICU, but that doesn't seem to be the case (with 1.44). (From the first line of ICU build section: "A default build of this library does not enable Unicode support via ICU. There is no need to enable ... ".) So I'm confused (as well as some other regulars on IRC), and either the documentation needs updating, jamfiles need updating, or my understanding needs updating. For now, the workaround mentioned above works fine, and the resulting regex.so file does not have any ICU external library dependencies (which is what is desired for our deployment environment). Thanks! Cliff

2 2

[assign] list_inserter regression test failure on VC10 / release branch
by Richard Webb 30 Oct '10

30 Oct '10

Another minor regression test fix: The list_inserter regression test (libs\assign\test\list_inserter.cpp) was fixed for VC10 on the Trunk in revision 62737, but hasn't yet been merged to the release branch. (the change also fixes one of the errors from GCC/C++0x, but the test still fails for other reasons).

1 0

[1.45] Beta next week?
by Beman Dawes 30 Oct '10

30 Oct '10

I've been too busy to do much on 1.45, but don't see any reason we can't get a beta out next week more or less as scheduled. If anyone know of any showstoppers, please let us know what the problem is. Thanks, --Beman

11 35

[mpl] anyone fancy merging the for_each test to the release branch?
by Richard Webb 29 Oct '10

29 Oct '10

Does anyone feel like merging libs/mpl/test/for_each.cpp (revision 65167) to the release branch? It's only a minor change to the test itself, but it clears a failure on VC10 and various C++0x GCCs.

3 2

[quickbook] Code links not working
by Edward Diener 29 Oct '10

29 Oct '10

I can not seem to get the quickbook code links to work. Nothing is being generated from the code link. As an example, to test them out I have in quickbook: This is a test of a macro reference - [macroref VMD_DATA_SIZE Test Macro reference] . and in my doxygen generated XML I see: <library-reference id="variadic_macro_data_reference"> <title>Variadic Macro Data Reference </title> <header name="boost/variadic_macro_data/VariadicMacroData.hpp"> <macro name="VMD_DATA_SIZE" kind="functionlike"> etc. but the output shows: This is a test of a macro reference - . Any ideas to get this to work would be appreciated.

12 20

[Thread][Release] Boost.Thread and 1.45 release
by Anthony Williams 29 Oct '10

29 Oct '10

Hi, I've fixed all the outstanding "showstopper" bugs in boost.thread on trunk (including the thread interruption issue, #2330), apart from #3847 (https://svn.boost.org/trac/boost/ticket/3847) - "Unable to statically link thread lib on ia64" I don't know how to fix this, and this platform doesn't appear to be actively tested. Is it OK to merge the other fixes to the release branch? Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

3 8

[constrained_value] Constrained Value review results
by Gordon Woodhull 29 Oct '10

29 Oct '10

Greetings, Substituting for Jeff Garland, I am pleased to present the results from the constrained_value review. The library is available at http://rk.dl.pl/f/constrained_value.zip The documentation is at http://rk.dl.pl/r/constrained_value Enjoy! Gordon 1. History The idea for a constrained value library goes back to at least 2004; Christopher Diggins proposed a mini-library at that time. In 2007 Joe Gottman suggested that Jeff Garland's constrained_value.hpp in date_time could be a top-level library. Concurrently, Robert Kawulak (henceforth RK) was working on his own library for the purpose, which he also started in 2004, unaware of the others. RK announced his library on November 11, 2007. Discussion continued into 2008; on June 19, RK announced his library was ready for review and it was put in the queue. The review began on December 1 2008 and continued until around December 15 (with some trailing discussion of the definition of invariant and why exceptions should not be used to check invariants). Gordon Woodhull reviewed the thread's 260 messages in the summer of 2010 and produced this report, dividing the issues raised between those where there was consensus on a change, those where no resolution was found, and those where the author and requesters (mostly) agreed that no change was needed. 2. Votes Eight people voted for acceptance of the library; there were no "no" votes. However, many people stated conditions on acceptance. Thanks to Chris (indy271828(a)sympatico.ca) Vicente Botet, Zach Laine, John Maddock, Thorsten Ottosen, Stjepan Rajko, Daryle Walker, and Gordon Woodhull for providing reviews. (In addition, Paul Bristow provided a review which looks like a yes but does not explicitly say so.) Thanks also to David Abrahams, Kim Barrett, Neal Becker, Paul Bristow, Edward Diener, Jeff Flinn, Joe Gottman, Mathias Guanard, Mika Heiskanen, Giovanni Pierro Deretta, Thomas Klimpel, Michael Marcin, OvermindDL1, John Phillips, raindog, Ravi (lists_ravi(a)lavabit.com) Johan Råde, Sebastian Redl, Peter Simons, Steven Watanabe, Utku Yaman, and Deane Yang for participating in a very active discussion. 3. Issues to be Addressed Floating point By far the most contentious issue in the review was the statement in the library documentation that floating point is not supported, and a few reviewers made fixing this a condition on acceptance. The issue is that the x87 math instructions (which are the default for 32-bit Intel compiles) utilize 80-bit registers which are then rounded down to 64 bits when a double value is written to memory. This can cause two values which were not equal to become equal later, with fairly unpredictable behavior depending on optimization and what code intervenes between calculating a value and comparing it. One solution is simply not to use the x87 math instructions by enabling the SSE2 math instructions instead. However, users may want the extra precision, and there is no way for a library to control this option. A few reviewers confused this issue with the frequent need for fuzzy comparison with epsilon; it was shown that the bug can still appear with epsilon-based comparisons. Jeff Garland points out that the Boost Numeric Interval library, http://www.boost.org/doc/libs/1_42_0/libs/numeric/interval/doc/interval.htm has also dealt with the x87 and NaN problems. It uses the round-trip-to-memory approach for x87. There is potential to create constraints for constrained_value using numeric::interval, and perhaps any other fixes for floating point belong in that library. Many solutions were proposed; after debate there were four left standing: * Force the new value to be written to memory Kim Barrett suggested the following function, noting that it should not force a memory write unless the value is in a register. inline double exact(double const& x) { return *const_cast<double const volatile*>(&x); } Gordon Woodhull has tested this against example provided by Thomas Klimpel in a message titled "floating point FUD" of January 23, 2010 (http://article.gmane.org/gmane.comp.lib.boost.devel/198817) and it does work. However, many people objected to this solution because of efficiency concerns: it requires a round-trip to memory (or at least to cache) for every assignment. * Only allow >= or <= for floating point types, and make sure the bounds are truncated 80- to 64-bit truncation can cause two values to become equal, but if one of them is already truncated, it cannot cause them to swap order. Since it is likely that the value will be changed much more frequently than the bound, it would suffice to apply truncation just to the bounds when they are set, e.g. with the exact() function above. However it does not seem that this solution can work if the bounds are dynamically calculated; the library supports bounds being returned by an inlined function. Johan Råde also suggested that it might be possible to implement < and > in terms of <= and >= and the std::nextafter function. * Force the processor to use 64-bit precision Johan Råde mentions a floating point control register which could be used in http://article.gmane.org/gmane.comp.lib.boost.devel/183760 There were also mentions of possible assembly code solutions, but none were provided and this was generally unpopular because it requires someone very knowledgeable to maintain it. John Phillips argued that reducing the precision will "lose significance faster than expected". * Another interesting solution was suggested by Stjepan Rajko: that the test might not be the same as the invariant. This is what testing with epsilon would guarantee. If the value passes the test it is guaranteed to satisfy the invariant, but only the test and not the invariant is in code. So some values might be rejected which are okay, but no bad value is accepted. RK felt that any floating point solution should be implemented separately from constrained_value, because he does not have the expertise. But he should be willing to document the scope of the problem better, including the SSE2 compiler flags that avoid the problem altogether. The first solution (truncation of the value) does not seem to require any changes to the library. Truncating the bounds might require some extra customization points. NaN Another problem with floating point is NaN, which compares false with everything. It might be okay if the bounds inclusion test always returned false. But the closed range is implemented as !(x < lower) && !(upper < x). Stjepan Rajko suggested that it should always be compare(lower, x) && compare(x, upper) where compare is < for excluded bounds and <= for included. It seems like this solution would work well for floats but not necessarily for user-defined types, which might only define operator<(). Substitutability with the underlying type A few people requested the ability to set a compiler flag in order to substitute the constrained_value with the underlying type. This is not exactly possible, unless the user is willing to explicitly extract the value using static_cast<T>(cv). The library does provide unconstrained<> which in most cases optimizes away, but the interface is not perfectly compatible with the underlying type. Constraints not copied when operators used The use of operators invokes implicit conversion to the underlying type, which means that in a statement like constrained_value x(10, constraint(...)), y(-x); y ends up with uninitialized constraints. Steven Watanabe suggested that the operators could be overloaded, but RK argued that the behavior would be application-specific: "For some applications returning a constrained value would be OK (but again there is the problem that the constraint may reject the modified value) while for others it's better to return the underlying type." Constrained strings Jeff Garland offered that he has written constrained_string classes for allowing values from a set of strings, and for validation against a regex. RK said he might add a constraint type which validates against set<T>, and affirmed that a regex validator would be nice too. Bounding on only one side Utku Yaman and others requested a way to bound integers on only one side. RK noted that you could set one of the bounds to the maximum or minimum possible integer, but this is verbose. Default arguments would be confusing, and RK thought maybe he would supply lower_saturating_int and upper_saturating_int. Note that there is a more general problem, especially if floating point is allowed. (Also consider e.g. fixed point, rational.) Recoverable error policy - error policy changing the value There were some objections to the error policy taking three parameters - the new value, the member value, and the constraint. Does it really need to change the member value? Yes, RK explained, because this is a recoverable error policy. Vicente Botet asked that the concept be called RecoverableErrorPolicy. Serialization Neal Becker requested support for serialization. RK agreed this is worth looking into and pointed out a couple of difficulties. One, a way to not serialize empty (or static) policies is needed. Two, non-default constructible types such as odd_number might require use of load_construct_data() / save_construct_data() instead of serialize(). Rename bounded_int This class name does not convey the fact that the bounds are specified at compile time. Neal Becker suggested compile_time_bounded or static_bounded. RK says the first name is too long, and the second might imply that the bounds are static members (which is also a legitimate use case). sizeof static constrained types == sizeof underlying type Assuming that the empty base class optimization is being applied correctly, which seems to be the case, if the constraint and the error policy are empty, the size of the constrained value should be the same as the size of the underlying type. However, this was not the case on all platforms, at least at the time of the review. The library should include sizeof tests in its test suite so that potential users know if there is unexpected overhead on their platform. Specify static bounds as open<0>, closed<100> for bounded<> and bounded_int<> Requested by Vicente Botet. If possible, this would reduce the number of template arguments and would be more clear than the current bounds exclusion boolean parameters. Some default constructions may throw If zero does not satisfy the constraint, then a default-constructed constrained value may throw an exception. (There are other examples, like non-empty string.) Many reviewers requested a means to provide a default value, which can be done by wrapping the underlying type, but RK felt a default value class was out of scope. At the very least this should be documented and probably an example given. Examples Vicente Botet requested: * an example showing how to create a constrained class by derivation and/or containment which adds/removes methods from the constrained value interface * a date example where changing the month affects the bounds for the day. * example of static bounding on only one side * example of bounds calculated at runtime by a function ("runtime dynamic bounding") Others: * example of constraints with static members - allows shared mutable constraints with no overhead per instance. Tests! Many reviewers were offended that there were no tests in the review version. RK said he would write some. Documentation * document the concepts and provide tests with concept archetypes. It turns out that these are documented briefly in the doxygen documentation of constrained<> at http://tinyurl.com/39v8o6r, but many reviewers were expecting a section in the main document. * Stjepan Rajko pointed out that the constraint can't depend on mutable members of the underlying type, and wondered if there were other implicit requirements, such as the way copy construction or swapping works. He requested these be documented. * Gordon Woodhull suggests a section on space efficiency and which configurations should allow the size to be optimized to the same size as the underlying type, and spelling out in each example what the cost in space is. * Thorsten Ottosen requested benchmarks of non-checking unconstrained against just using the underlying type. RK offered that he had looked at the generated assembly on some platforms. 4. Unresolved debates Error policy is allowed to change constraint Vicente Botet objected to the "bounded object with memory" example, which tracks extremal values by setting the bounds to include any new values. And Thorsten Ottosen objected to the inefficiency of change_constraint using construct-and-swap: it's not necessary to swap the constraint unless it might be changed by the error policy. This seems to be an example of a monitored value, which RK does not want to write himself, so does it belong in this library? RK argued that it does no harm, so why not allow? Double-checking and disabling assertions A number of people were concerned with the inefficiency of first checking the constraint, and then also asserting that the constraint is satisfied after the assignment has happened or the error handler has been called. But RK argued that it was necessary to check the invariant to make sure that the assignment operator and the error handler are doing their job. Besides, it is possible to disable the asserts with either BOOST_DISABLE_ASSERTS or NDEBUG. There was some discussion of adding an assert policy or a specific macro (with no clear conclusion). Disabling checks There is unconstrained, which offers a way to replace one constrained type with an unconstrained type, but Chris (indy271828(a)sympatico.ca) requested a way to disable all checks with a single macro. It might not be good enough to use a single error policy and select between throwing version and an assign-anyway version, because the compiler won't always optimize this away. More members, less free functions Thorsten Ottosen thought that any functions which change the state of the object should be members, not free functions. In particular, change_constraint might be less efficient than possible because the construct-and-swap requires copying the constraint. This does seem to be partly an ideological debate. Specific classes instead of a general super-template Vicente Botet requested that the interface use specific classes instead of typedefs: currently many of the specializations, like bounded<>, are metafunctions that apply some parameters to the generic constrained_value and return a new type, and then the specific operations are free functions. Instead these could be full classes with member functions. RK argued that this would result in unnecessary duplication. Way to disable the arithmetic operators Vicente Botet requested a solution in code or in documentation for users who don't want the arithmetic operators defined. 5. Ideas not requiring any action Monitored Values Stjepan Rajko suggested (and Vicente Botet expanded on the idea) that constrained value is really a special case of a more general "monitored value" class, in which a monitor policy decides how to handle any assignment. So constrained value would be a monitored value where the monitor policy checks a constraint, possibly calls an error policy, and then asserts the constraint. RK did not want to implement this and resisted suggestions to allow the assertion to be disabled in order to allow this use case, because without an invariant, it's not really a constrained value. But he suggested that monitored value could be implemented by someone else and constrained value could be re-implemented in terms of it. "Monitored value" might not be the best name for the general class, because "monitor" suggests something passive, rather than something which controls the outcome of assignment. A way to run a function on a constrained value Stjepan Rajko requested a way to make a copy of the value, run a function on it, and then reassign back, preferring the syntax call_using_copy(f, x) to x = f(x). But he notes this could be written as a free function. Multiple ranges Edward Diener requested a way to supply multiple ranges, but agreed that the syntax would be unattractive. Assertions instead of exceptions Thorsten Ottosen requested a way to have only assertions and no exceptions, and RK pointed out that this can be done either by specifying an error policy which asserts, or even with an assign-anyway error policy, which leaves the invariant checking in place. Exclude bounds parameter Vicente Botet found it confusing that bounded_int takes false to mean include bounds and true to mean exclude the bounds. RK explained that this is an artifact of the way within_bounds is templated on a type which can be either a compile-time or a runtime value, e.g. mpl::true_ or bool; this technique means there can be no default argument to the constructor and thus the more common option must be false, the default constructed value of bool. Constraints between several variables. Vicente Botet suggested a sort of constrained_tuple where if you set one field it would affect the constraints for the other fields. E.g. a date object where the month and year would affect the valid range for the day. With the current interface you'd have to set the whole date at once. Constrained values as sets of instances Exploring the problem domain, Vicente Botet suggested another possible implementation of constrained value where the constrained value type keeps track of which instances satisfy the constraint. This class would offer a split operation which moves any instances which satisfy a more specific constraint into the new set. Changing the constraint would similarly return the set of instances which are now excluded.

12 49

Boost Threading Shared Memory
by Tanya Gillis 29 Oct '10

29 Oct '10

I have a question regarding Boost threads, and am awaiting acceptance into the Boost Threads forum. I was wondering if anyone can help me. I am creating a multithreaded application using Boost threading, and would like to know how shared memory is implemented by Boost for threading. Each thread creates an object separately, and that object has a private member variable. We are seeing in our application that that member variable is looking the same, as if it was shared among the threads. Is this plausible? How does it work? Thanks.

2 1

Call for interest - BOOST_AUTO_FUNCTION
by Matt Calabrese 28 Oct '10

28 Oct '10

I've been noticing that a lot of times in 0x code I've found it useful to create a very simple "auto function" macro that uses trailing return type syntax with decltype with 1-liner functions that automatically repeats the same expression in both the return type and the return statement. #define AUTO_FUN( name, param_list, expression ) \ auto name param_list -> decltype( expression ) { return expression; } There are two big advantages to this. The first and most obvious one is that it reduces redundancy when you have a 1-line function template which has a difficult to deduce return type that you generally would use decltype on, and the more subtle benefit is that since the exact expression is repeated in the return type you automatically get "perfect-fit" SFINAE. By that I mean it provides a quick way to SFINAE-out potential instantiations before instantiating the implementation. Because of this, even though a return type may be simple to deduce without decltype, the macro is still a valuable tool since it can cause substitution to fail if the body of a function template would fail to instantiate. You get very basic, automatic, syntax-only concept checking for free. It's a simple macro, but I find that it gets lots of use. As an example: http://codepaste.net/iqzbiz The above example is a simple "multi_cast" that chains several static_casts in a row (the example code shows a potential use-case). The subtlety here is that the return type is easily deducible without the need for decltype (the return type would just be "TargetType"). Instead, the macro is used because it causes substitution to fail if the body of the function would fail during instantiation. So when using "multi_cast" here, If someone attempts to do a cast where any of the intermediate types is not a valid conversion, rather than getting a complicated error nested inside of several instantiations, you get a single error message at the top-level call-site stating that there is no match for the function call (well, at least it's a simple to read error in gcc... *cough*). This works because if the body of any of the calls would have an error, substitution would instead fail, meaning substitution would fail for the caller, all the way back up to the top without any bodies being instantiated. In other words, it's SFINAEs all the way down :| I find this type of functionality to be very useful, particularly in libraries. In fact, I find myself using it for just about all 1-line function templates. Do others agree that this would be a worthwhile addition to boost? Documentation should be quick to write up. The macro would of course be renamed to something along the lines of BOOST_AUTO_FUNCTION If anyone thinks multi_cast would be useful, let me know and I'll also spin off a separate thread for that, though I'm tempted to think it's more of a curiosity than something that would get much use. -- -Matt Calabrese

11 54