- Boost - lists.boost.org

[config] C++0x macros
by Beman Dawes 30 May '08

30 May '08

There was some past discussion of changing the C++0x BOOST_HAS_* macros to BOOST_NO_*. Several participants thought that was better for the long run. Who needs to do what to make this happen? The motivation for asking is that I'm starting to update some Boost code that could benefit from C++0x features and so would like to start using these macros. Also, a C++03 workaround for the lack of the C++0x keyword "constexpr" is to simply omit it. Should we have a BOOST_CONSTEXPR macro defined as "constexpr" for platforms that support constexpr, otherwise as null? --Beman

14 31

[spirit] 'nother patch, (building example5.cpp on gcc4.2), attribute_transform.hpp
by troy d. straszheim 30 May '08

30 May '08

Hi again guys, This one is easier. Having applied the assign_to/construct patch, examples 4 and 6 compile fine, but example5.cpp died on this: example5.cpp:283: instantiated from here ../boost/trunk/boost/spirit/home/support/attribute_transform.hpp:144: error: ambiguous class template instantiation for 'boost::spirit::traits ::strip_single_element_sequence< boost::fusion::vector< boost::variant< unsigned int, string, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_ >, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_ >, mpl_::bool_<false> >' ../boost/trunk/boost/spirit/home/support/attribute_transform.hpp:144: error: invalid use of incomplete type 'boost::spirit::traits ::strip_single_element_sequence< boost::fusion::vector< boost::variant< unsigned int, string, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_ >, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_ >, mpl_::bool_<false> >' ../boost/trunk/boost/spirit/home/support/attribute_transform.hpp:32: error: declaration of 'boost::spirit::traits::strip_single_element_sequence< boost::fusion::vector< boost::variant< unsigned int, string, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_, boost::detail::variant::void_ , boost::detail::variant::void_ >, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_, boost::fusion::void_, boost::fusion::void_ , boost::fusion::void_ >, mpl_::bool_<false> >' You just disambiguate via enable_if to get things building. Works on gcc4.2: --- attribute_transform.hpp (revision 45915) +++ attribute_transform.hpp (working copy) @@ -11,6 +11,7 @@ #include <boost/spirit/home/support/unused.hpp> #include <boost/spirit/home/support/component.hpp> #include <boost/spirit/home/support/attribute_of.hpp> +#include <boost/spirit/home/support/detail/values.hpp> #include <boost/fusion/include/vector.hpp> #include <boost/fusion/include/is_sequence.hpp> #include <boost/variant/variant_fwd.hpp> @@ -25,16 +26,19 @@ namespace traits { + using boost::spirit::detail::not_is_variant; + // Here, we provide policies for stripping single element fusion // sequences. Add more specializations as needed. - template <typename T, typename IsSequence> + template <typename T, typename IsSequence, typename Enable = void> struct strip_single_element_sequence { typedef T type; }; template <typename T> - struct strip_single_element_sequence<fusion::vector<T>, mpl::false_> + struct strip_single_element_sequence<fusion::vector<T>, mpl::false_, + typename boost::enable_if<not_is_variant<T> >::type> { // Strips single element fusion vectors into its 'naked' // form: vector<T> --> T @@ -42,7 +46,8 @@ }; template <typename T> - struct strip_single_element_sequence<fusion::vector<T>, mpl::true_> + struct strip_single_element_sequence<fusion::vector<T>, mpl::true_, + typename boost::enable_if<not_is_variant<T> >::type> { // Strips single element fusion vectors into its 'naked' // form: vector<T> --> T, but does so only if T is not a fusion Let me know if you just want a commit, (also for the other stuff). There are a few more things like this around, I'll get after them. Thanks for a great library (these little gotchas notwithstanding). I'm getting a real kick out of all this, learning a lot... this code is *crazy*. You guys have definitely raised the bar. -t

2 1

[date_time] boost time is lacking a big bang
by Joachim Faulhaber 29 May '08

29 May '08

Hi! My first goal in boostifying my proposed interval template library (ITL http://sourceforge.net/projects/itl) was to provide good examples for interval_sets and interval_maps using boost::date_time objects. This was much harder than I had expected, because incidentally the most important syntactical and semantical requirements that I do rely on for a parameter T of itl::interval<T> are not provided by boost::date_time. The one property of boost::date_time that knocked my socks off was the default constructor that 'is-not-a-date-time'. I paraphrase this as: boost::time is lacking a big bang ;-) Default constructors in nearly all the types that I've seen in my lifetime (I know the realm of my unknown unknowns is vast ;-) are intended to be elements of the type they do construct. Moreover in so many cases including built in types, default ctors serve as *initial elements*. Other elements can be *reached* from T() applying operations of T on them. This applies to all built in types and many std::types, like e.g. string, set, list etc. The most simple instance is unsigned int() with increment operation ++ that resembles the Peano axiomatic operations 0 and successor for natural numbers. This semantics of default ctors, at least in common built in and standard types and also in so many user defined types is so fundamental that I took it as a *semantical invariant* for the construction of my library. In the ITL an empty interval<T> [1,0] for instance, has to be defined generically: [ type<T>::unon(), type<T>::neutron() ] where type<T>::neutron() is implemented via T() : the default ctor and type<T>::unon() is implemented via ++T() : the default ctor incremented exactly once. So, striving to be as generic as possible I tried to set those minimal requirements that I assumed to be common sense: For discrete types T, the existence of an initial value T() and In(De)crementation. Instead of being a big bang of time, boost::date_times default constructors are cannibals. They give birth to a date_time() object that they immediately swallow. Then saying schizophrenic things about themselves like: cout << to_simple_string(ptime()); "not-a-date-time" They are singularities having an infinite gravitational pull on any operators. You can apply as many of them on the constructed black whole and they are never seen again having no effect. In addition to making the expected source of all elements of boost::date_time an awesome creature to be avoided, the universal c++ way of saying the next object within minimal distance '++' has also been taken away from me. May be with the good intension to prevent me from doing silly things like iterating over whole centuries in nanoseconds ;-) Yet all my applications of ++ and -- in my generic code use them only once like in comparing intervals of discrete types (a, b] == [c, d] is true, if(++a==c && b == d) that have different borders. I only have to make sure here that the minimal distance is proceeded only once. To summarize: What I have been relying on in my design, an initial default ctor T() and an increment operator ++ on the least availabel distance unit is exactly not provided by boost::date_time. Now the good news: Both libraries are so well designed that these seemingly contrarian designs can still be coupled with relatively small changes. Specifically, which is crucial for me, I can adapt my libraries code so that I can use all of boost::date_time in it's current form without patching anything (which would also work as I wrote in my last posting). The seemingly most decoupled remedy was, to implement the the missing functions type<T>::neutron() as well as increment ++ and decrement -- operators using the public interface of boost::date_time. This had to be done for every boost::date_time type like e.g. ptime: itl/ptime_adapter.hpp: ------------------------------------------------------------- boost::posix_time::ptime operator ++(boost::posix_time::ptime& x) { return x += boost::posix_time::ptime::time_duration_type::unit(); } boost::posix_time::ptime operator --(boost::posix_time::ptime& x) { return x -= boost::posix_time::ptime::time_duration_type::unit(); } template<> inline boost::posix_time::ptime type<boost::posix_time::ptime>::neutron() { return boost::posix_time::ptime(boost::posix_time::min_date_time); } ------------------------------------------------------------- Drawbacks of this are: (1) Designs are not completely decoupled, for every boost::a_date_time the matching adapterfunctions must be included. This is a complication for the usage. (2) *Every* generic library that relies on the existence of an initial default ctor and incrementation has to provide an adapter. (3) Every adapter has to be maintained, when boost::date_time is changed. (Kind of a distributed responsibility that is error prone) I would suggest, that a type that in it's basic characteristics resembles an intergral numeric type like boosts date_time types, that type should follow the concept Integral. cheers Joachim Interval Template Library download from http://sourceforge.net/projects/itl documentation http://www.herold-faulhaber.de/

5 9

[smart_ptr] trunk version of enable_shared_from_this incompatible with TR1
by Daniel Frey 29 May '08

29 May '08

TR1 states that the dtor of enable_shared_from_this is non-virtual, the trunk version violates this. Regards, Daniel

6 25

[shifted_ptr] Neural networks
by Phil Bouchard 29 May '08

29 May '08

Greetings: I have made some changes into my sandbox and I am happy to say some tests send by Steven a while ago are now working correctly. The interface was previously supporting only allocations made by "new_sh". I was aware of this but now I am adding a solution to make shifted_ptr generic enough. The solution is still a non-portable one but will be corrected shortly; it consists of detecting the stack frame and I am using gcc's __builtin_frame_address(). I also replaced Nedmalloc for Boost.Pool because I temporarily wish to reduce problems I might face. The problem with Boost.Pool is that it doesn't handle arbitrary sized chunks and the complexity goes down to O(n) for array allocations. All in all shifted_ptr behaves differently when a pointer resides either on the: 1. stack & data segment 2. local heap 3. system heap Moreover the test file shifted_ptr_test3.cpp which uses BOOST_TEST macros is crashing on gcc for Windows. The same tests appears in shifted_ptr_test2.cpp and work correctly. Finally yes I definitely need to write documentation about this but I will basically need to write something similar to a book. For now I just want to present a working example and here it is. The ultimate objective of shifted_ptr is to handle neural networks for artificial intelligence testings so feel free using the pointer in your tests to help me finding flaws that might still exist. Regards, -Phil

1 1

[spirit][xpressive][memory] A new regex library: TPL
by shiwei xu 29 May '08

29 May '08

TPL is short for "Text Processing Library". It is a spirit/xpressive like library. I used spirit/xpressive. But the codes based on spirit or xpressive was compiled slowly. Here are some hints of TPL: * It is simple. * It will always be compiled fast. * It is based on Boost-Memory (still is a sandbox library). Here is an example of TPL: #include <stack> #include <tpl/RegExp.h> #include <tpl/ext/Calculator.h> #include <cmath> using namespace tpl; void calculate2() { typedef SimpleImplementation impl; // ---- define rules ---- impl::Allocator alloc; std::stack<double> stk; impl::Grammar::Var rFactor; impl::Grammar rMul( alloc, '*' + rFactor/calc<std::multiplies>(stk) ); impl::Grammar rDiv( alloc, '/' + rFactor/calc<std::divides>(stk) ); impl::Grammar rTerm( alloc, rFactor + *(rMul | rDiv) ); impl::Grammar rAdd( alloc, '+' + rTerm/calc<std::plus>(stk) ); impl::Grammar rSub( alloc, '-' + rTerm/calc<std::minus>(stk) ); impl::Grammar rExpr( alloc, rTerm + *(rAdd | rSub) ); impl::Rule rFun( alloc, "sin"/calc(stk, sin) | "cos"/calc(stk, cos) | "pow"/calc(stk, pow) ); rFactor.assign( alloc, real()/assign(stk) | '-' + rFactor/calc<std::negate>(stk) | '(' + rExpr + ')' | (gr(c_symbol()) + '(' + rExpr % ',' + ')')/(gr(rFun) + '(') | '+' + rFactor ); // ---- do match ---- for (;;) { std::string strExp; std::cout << "input an expression (q to quit): "; if (!std::getline(std::cin, strExp) || strExp == "q") { std::cout << '\n'; break; } try { while ( !stk.empty() ) stk.pop(); if ( !impl::match(strExp.c_str(), rExpr + eos(), skipws(), alloc) ) std::cout << ">>> ERROR: invalid expression!\n"; else std::cout << stk.top() << '\n'; } catch (const std::logic_error& e) { std::cout << ">>> ERROR: " << e.what() << '\n'; } } } // ------------------------------------------------------------------------- If you are interested in TPL, you can check out its source code from SVN: svn checkout http://libtpl.googlecode.com/svn/trunk/

1 0

[vault] polymorphic_function call wrapper
by Daniel Walker 29 May '08

29 May '08

Hello, Following up on several discussion over the last few weeks, I've placed an implementation of a polymorphic call wrapper (and associated utilities) similar to Boost.Function in the file polymorphic_function.zip in the Function Objects directory on vault at http://tinyurl.com/56zvo4. Here's a brief demonstration to give an idea of what's included: // Work with arbitrary callable objects without loss of polymorphism. template<class Signature> void do_division(polymorphic_function<Signature> f) { // Do floating point division. float one = 1, two = 2; assert(f(one, two) == 0.5); if(is_polymorphic_function<Signature>::value) { // Now, drop the remainder using integer division. int one = 1, two = 2; assert(f(one, two) == 0); // And now, use high precision floating point division to // compute the inverse product of a series of integers. int series[3] = { 1, 2, 3 }; double x = std::accumulate(&series[0], &series[3], 1.0, functional_cast<double(double,double)>(f)); assert(0.16666666 < x && x < 0.166666667); } } // A second class builtin function. float builtin_divide(float x, float y) { return x / y; } // A TR1 result_of compatible function object. struct divide { template<class Signature> struct result : argument_of<Signature, 0> { }; template<class T> T operator()(T x, T y) const { return x / y; } }; int main() { // Promote builtin functions to first class. do_division< float(float,float) >( builtin_divide ); // Perform type-erasure. do_division< float(float,float) >( std::divides<float>() ); // Use polymorphic function objects polymorphically. do_division< divide(_1,_1) >( divide() ); } The file polymorphic_function.hpp provides the following components: * signature/call_signature/erase are metafunctions used to describe polymorphic functions. They allow you to do things like erase the callable object type of a boost::result_of compatible signature so it can be used with boost::function. typedef signature<my_function(int)>::type signature_type; typedef result_of<signature_type>::type result_type; typedef function<erase<signature_type>::type> function_object_type; * is_polymorphic_function is a metafunction used to designate function prototypes that may have variable return types according to boost::result_of. These are a subset of the prototypes detected by boost::is_function. More pertinently, is_polymorphic_function distinguishes the boost::function protocol for specifying function signatures - a.k.a. call signatures - from the boost::result_of protocol - a.k.a. polymorphic signatures. * is_incomplete_function is a metafunction used to designate polymorphic functions with variable argument types. These are a subset of the prototypes detected by is_polymorphic_function. They are described using Boost.MPL placeholders as arguments in the signature. * argument_of is a metafunction used to deduce the types of arguments to functions. It's a more general, nary alternative to the C++98 argument_type member. For example, argument_of can be used to detect call-by-reference functions: template<class F> void g(F f) { int x = 0; int& y = f(x); if(is_reference<typename result_of<F(int)>::type>::value && is_reference<typename argument_of<F(int), 0>::type>::value) assert(&x == &y); } int& my_function(int& t) { return t; } int main() { g(my_function); } * polymorphic_function is a call wrapper, which can be used in place of boost::function to allow both builtin functions and function objects to be used interchangeably without the degradation of polymorphism incurred by wrapping polymorphic function objects in boost::function. Essentially, this is achieved by giving the user the option of either erasing the function object's type as one would with boost::function or retaining the function object's type as one would with boost::result_of. * functional_cast is used to change the signature of a call wrapper. It can be used with both std/boost::function and polymorphic_function. For example, by specifying a new signature one may change the arity or argument types of a call wrapper, so long as the underlying callable object can be described by the new signature. Also included is a test set. I tested on gcc 3.4, 4.3 and msvc 9. The code includes some documentation in the form of inline comments. As far as future work and known defects, this is the first time I have seriously played with C++0x forwarding conventions using std::forward and rvalue references. I'm not confident that I got it perfectly right, so any corrections/guidance would be greatly appreciated. In C++98, I use an argument forwarding technique similar to Boost.Bind and Boost.Lambda - arguments are taken as non-const references and forwarded as rvalue conversions of the types requested in the signature. Secondly, type deduction using argument_of could have better support for function objects in C++98 and currently only supports member template operator() in C++0x. Finally, I'm sure more boost::function-like features could be added to polymorphic_function including members for queryng capacity, comparison operators, an allocator template parameter, etc. Thanks for your time and consideration! Cordially, Daniel Walker

2 4

[thread] Are thread ids unique during an applications life time?
by Johan Torp 28 May '08

28 May '08

IIRC, windows thread ids can be re-used. That is, if you stop a thread X and later start a thread Y they might get the same thread id. Is this the case with boost.thread? What about the standard? It states: "An object of type thread::id provides a unique identifier for each thread of execution and a single distinct value for all thread objects that do not represent a thread of execution ([thread.threads.class]). Each thread of execution has a thread::id that is not equal to the thread::id of other threads of execution and that is not equal to the thread::id of std::thread objects that do not represent threads of execution." http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html#thread.t… Which sounds like thread ids are free to be re-used. Johan -- View this message in context: http://www.nabble.com/-thread--Are-thread-ids-unique-during-an-applications… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 8

property tree and default translator_type
by Christian Holmquist 28 May '08

28 May '08

Hi, I've been using property_tree for quite a while now, and I think it's a very useful library, many thanks to the authors for their work! I'm wondering if it's possible to refactor it a bit, so that users can configure it to be more lightweight? In it's current form it pulls in quite a lot dependencies, where many are used only by the default template translator parameter (which is std::stringstream based); If I supply a translator of my own I won't get rid of the includes in ptree.hpp. Wouldn't it be better that users include property_tree/translator.hpp when they need to parse data from the tree? In my experience I often need to manipulate the property_tree, but without doing and type conversion. Such code would compile faster with the translator left out. Pushing it a bit further, I don't think the translator should be a class member template at all, since it has nothing to do with the contents of the tree. Parsing of data is done on a 'use-case' basis, meaning that different code has different requirements on the parser, even if it reads the data from the same tree. With the current design I cannot choose to parse an int (say) using boost.spirit at one location, and the default stringstream parser at another, unless instantiating a new basic_ptree<...> type. I am of course free to not use the translator and instead access data() directly and pass it to the parser of my choice, but then I need to reimplement some parts of the get_value and get_optional which are very useful as they are now (and probably more carefully written than I would come up with). I would prefer the translator to be a template parameter to the get()/get_xxx() functions instead. This would probably give faster code for the end-user too,since they are encouraged to instantiate a translator before parsing values from the tree. The default translator would in this case reuse its internal stringstream object, instead of recreating one for every read. Something like this: property_tree::ptree pt; property_tree::translator t; pt.get_value<int>(t); pt.get_value<float>(t); pt.get_value<int>(my_custom_number_parser()); The above would create only one stringstream, compared to: property_tree::ptree pt; pt.get_value<int>(); // stringstream() pt.get_value<float>(); // stringstream() // I cannot use my_custom_number_parser here at all, unless creating some kind of composite translator type, which isn't easy when dealing with polymorphic function objects. Thoughts on this, anyone? / Christian

2 2

the beginning of a pattern/gesture recognition library
by Stjepan Rajko 28 May '08

28 May '08

Hello, I have started moving some code into a Boost-based open source generic pattern/gesture recognition library (I briefly mentioned it at my Dataflow+Arts talk at BoostCon) . The examples right now show how to do gesture recognition on some pre-segmented video captures of full-body human gestures, as well as pattern recognition in sequences of floating-point numbers. Soon I'll be adding something for recognition of mouse gestures. The library docs and download info is at: http://ame4.hc.asu.edu/amelia/patterns/ The library is currently GPLed but that's open to debate (this is my research program's first venture into open source and GPL was the safest initial choice). As the library matures I'd like to move it to the Boost license and eventually submit it for Boost review. If anyone is interested in using this library or joining the development, please let me know. The few tests/examples have so far been verified to work on GCC4.0.1/darwin and MSVC8. Kind regards, Stjepan

2 2