October 2008 - Boost - lists.preview.boost.org

boost::filesystem request
by Jorge Lodos Vigil 31 Oct '08

31 Oct '08

Hi The Traits classes for basic_path provided in the filesystem library (path_traits and wpath_traits) are good enough to be used as default values for basic_path in most cases. However, since they are independent structs, they can not be used to instantiate a basic_path with a single String template parameter. I would like to write: typedef basic_string<char> string_t; typedef fs::basic_path<string_t, fs::basic_path_traits<string_t> > path_t; Currently we are forced to write in our code something as: template <typename String> struct path_traits {}; template <> struct path_traits<std::string> { typedef boost::filesystem::path_traits traits_t; }; template <> struct path_traits<std::wstring> { typedef boost::filesystem::wpath_traits traits_t; }; typedef std::basic_string<CharT> string_t; typedef boost::filesystem::basic_path<string_t, typename path_traits<string_t>::traits_t > path_t; I underestand it is important to emphasize that Traits classes have nothing to do with String classes in path instantiations, so my question is: Is it reasonable to ask that path traits classes provided in the library would be implemented as template specializations instead of separate classes? Thanks in advance. Best regards Jorge

4 9

[range_ex] warning when using index operator on the element of a transformed range of a transformed range of a fusion sequence
by Stjepan Rajko 30 Oct '08

30 Oct '08

Hello, I apologize in advance for the long explanation about a small problem... I tried to trim it down as much as I could right now. If it is still too much info, I can try to trim it down more... I am working in a context where I have Ranges of Ranges of fusion Sequences, and need to access different "slices" of said contraption. By that I mean, if I have a: std::vector<std::vector<fusion::vector<int, double> > > RoRoS, I would like to access a Range of Range of ints (consisting of the first elements of the fusion vector), and a Range of Range of doubles (consisting of the second elements). I wrote a little utility that allows me to do that (using RangeEx `transformed` adaptors) in the context of a for_each iteration (see attached "for_each_element_and_slice.hpp"). The purpose of this one is, given say a fusion::vector<foo,bar> S0; for_each_element_and_slice<1>(S0, RoRoS, some_fn) will call: some_fn (the foo element of S0, the Range of Range of ints) some_fn (the bar element of S0, the Range of Range of doubles) 1 specifies the "depth" - 1 means the second parameter is a Range of Range of Sequence, 0 would mean Range of Sequence, 2 would mean Range of Range of Range of Sequence. Anyway, in doing this I ran into a weird warning. If some_fn is as follows: struct weird_warning { template<typename Element, typename Slice> void operator()(Element &element, const Slice &slice) const { *boost::begin(slice[0]); // no warning slice[0][0]; // warning: operator[](outer) returning reference to temporary } }; ...I get warnings as indicated by the above comments. That is, *boost::begin(slice[0]) works just fine, but slice[0][0] issues a warning about the outer operator[] returning a reference to a temporary. I would be inclined to think that both of these should be legal operations (with no warnings being issued) - is that correct? If so, is there a problem in my use of range_ex, or is there a problem with range_ex? (the test file test_for_each_element_and_slice.hpp attached - the bits relevant to this warning are outlined by: //------------------------------------------------------------ //------------------------------------------------------------ ...relevant bits... //------------------------------------------------------------ //------------------------------------------------------------ ) I am using what I believe is the latest RangeEx from the vault (thanks for this great utility!) against boost trunk. Any help appreciated! Thanks, Stjepan

1 0

Re: [boost] [Boost.Msm] On the necessity of state-boundary-crossingtransitions
by Christophe Henry 30 Oct '08

30 Oct '08

Hi Andreas, I am not sure what is the point of such a challenge considering that I already explained that entry and exit pseudo states are not supported yet but will probably be in the future. Their absence is not by design as you seem to think but simply a decision of when to bring a version 1.0 and what should be inside. Anyway, as you offered me this challenge, I offer a solution which you will find in the vault ( http://www.boostpro.com/vault/index.php?direction=0&order=&directory=Msm&) I think this solution is a good example of what you can do with Msm and will hopefully make it clear how sub machines can make life easier. I want to thank you for the chance you give me to improve Msm (a few bugs were corrected on the way) and for your reaction to my opinion, which made it clear I need to more clearly draw a line between what I personally think and what users are used to and expect to find in Msm. Again, although I think no good of entry and exit pseudo states and consider them more than doubtful practice (please have a look at the doc for an explanation), a future version of Msm will offer them in some form with corresponding warnings. Regards, Christophe

2 1

How to find: best integer type for processor
by Daryle Walker 30 Oct '08

30 Oct '08

Is there a macro and/or typedef that will tell me bit-length used for a processor and/or the best integer type for said processor? The "int" type is supposed to be that type, and it was in the 16- and 32- bit eras. (I learned C programming with the former in the... early 1990s!) However, the powers-that-be decided, for "backwards compatibility," to freeze "int" and "long" at 32 bits and use a new type, "long long," for 64 bits, which should be the optimized integer type for 64-bit processors. (If they kept to the plan, "int" would be 64 bits, "long" either 64 or 128, "short" up to 32, and the new type will be "short short" at 16.) I want to know the best type so, when I build multi-integer arrays for various purposes, I don't pick an element type that causes a slow down, whether to focus on a fraction of a register (if the chosen type is too small) to handle two registers at once (if the chosen type is too large). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

7 9

[parameter] some extensions to Boost.Parameter
by Stjepan Rajko 30 Oct '08

30 Oct '08

Hello, I've played with some extensions to Boost.Parameter and would like to know if there is any interest to have any of them polished / rolled back into the library. I have found these extensions useful when using ArgumentPacks directly rather than using Boost.Parameter macros like BOOST_PARAMETER_FUNCTION, BOOST_PARAMETER_CONSTRUCTOR,... (I am using the library in this particular way because of reduced compile times and (IMO) cleaner library code (although user-side code takes a slight hit)). Here are brief descriptions of the extensions: *1* Keywords/Tags with fixed types These are intended for keywords/tags that are always associated with a certain type of argument. operator= of a fixed-type keyword always return a tagged argument whose value_type is the fixed type. This has the benefit of moving any type conversions to the call site, which allows *3* Implementing this involved splitting the keyword class into typed_keyword and untyped_keyword, with the commonalities extracted into a keyword_base class. It also introduces a corresponding new macro, BOOST_PARAMETER_TYPED_NAME. *2* Default-default arguments When a keyword always has the same default value, I found it useful to put the default value into the Tag definition (in the form of a static member function that returns that default value). The definition is made using a macro - this is an example use case: BOOST_PARAMETER_TYPED_NAME_WDEFAULT(label,const std::string,"") If a ArgumentPack args does not contain an explicit value for _label, args[_label] will return std::string(""). I'm not sure what the right response to e.g., args[label|"something"] should be. *3* Make ArgumentPacks constructible from other ArgumentPacks. I basically added a constructor to arg_list that does allows something like the following: // this will return an appropriate arg_list type, containing four tagged_args // the four tags are all typed (*1*) and with default default values(*2*) typedef argument_pack<tag::label, tag::size, tag::position, tag::background>::type argument_pack_type; window(const argument_pack_type &args); In the above case, e.g., window(( _label="label", _size=size_type(100,100) )) would call window with default-default values for position and background. The benefit here is that the implementation of window doesn't need to be templated (which is helpful in some cases), and you don't need to write any forwarding functions (or use BOOST_PARAMETER_FUN). *4* Overloading operator() for typed keywords Instead of writing, e.g.: window (( _size=size_type(100,100), _position=position_type(0,0) )) , we can write window (( _size(100,100), _position(0,0) )) I accomplished this by adding a delayed_constructor class which holds references to the arguments (e.g., 100, 100) and is convertible to the Tag's value_type (e.g. size_type). The 'conversion' is done constructing an instance of the value_type using the arguments. The delayed_constructor is then stored in a tagged_argument object instead of the usual reference to the value_type. I had to hack tagged_argument and arg_list to work with delayed_constructor, which was in some ways similar to how tagged_argument and arg_list are made to work with the `maybe` class. This leads me to believe that tagged_argument and arg_list would benefit from having a specified extension interface into which things like `maybe` and `delayed_constructor` could hook into, rather than being so tightly coupled. The proof-of-concept implementation for all these things can be found at: http://svn.boost.org/svn/boost/sandbox/guigl/boost/parameter/ To avoid clashing with Boost.Parameter, I made the above extensions in renamed classes (e.g., typed_arg_list and typed_tagged_argument). Please let me know if there is any interest. Kind regards, Stjepan

3 10

Review Request: Polynomial
by Paweł Kieliszczyk 30 Oct '08

30 Oct '08

Hi, I'd like to request a review of my polynomial library which I wrote during Google Summer of Code project this year. The zip file is in Boost Vault (called polynomial.zip). It includes the library, tests and documentation. The same files (not compressed) are also available in sandbox: http://svn.boost.org/svn/boost/sandbox/SOC/2008/polynomial/ Thanks -- Pawel Kieliszczyk

3 5

tie alternative?
by David Abrahams 30 Oct '08

30 Oct '08

OK, BOOST_FOREACH aside, iterating over a range returned as a pair of iterators can be painful and ugly: vertex_iterator pv, ve; tie(pv, ve) = vertices(g); // unpack the pair returned by vertices for (; pv != pe; ++pv) { ... } However, we can make it much nicer, e.g.: for (vertex_iterator pv,ve = xxx(pv,vertices(g)); pv != ve; ++pv) { ... } My only problem is how to spell xxx. The attached proof-of-concept uses operator%, but I don't feel particularly good about that choice either. Ideas? --- -- Dave Abrahams BoostPro Computing http://www.boostpro.com

13 21

[function] support for overloaded function
by Oliver Kowalke 30 Oct '08

30 Oct '08

Hello, how can I support the return type of bind as well as function as function argument in following code. regards, Oliver #include <iostream> #include <cstdlib> #include <stdexcept> #include <boost/bind.hpp> #include <boost/function.hpp> struct X {}; struct Y { template< typename R > void f( boost::function< R() > const& fn) {} template< typename R > void f( boost::function< R( X &) > const& fn) {} }; struct Z { int u( int i) { return i; } int v( X & x, int i) { return i; } }; int main( int argc, char *argv[]) { try { Y y; X x; Z z; // does not compile y.f( boost::bind( & Z::u, z, 1) ); boost::function< int() > fn1( boost::bind( & Z::u, z, 1) ); y.f( fn1); // does not compile y.f( boost::bind( & Z::v, z, _1, 1) ); boost::function< int( X &) > fn2( boost::bind( & Z::v, z, _1, 1) ); y.f( fn2); return EXIT_SUCCESS; } catch ( std::exception const& e) { std::cerr << e.what() << std::endl; } catch ( ... ) { std::cerr << "unhandled" << std::endl; } return EXIT_FAILURE; } -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

2 1

patch to serialize mersenne_twister
by Neal Becker 30 Oct '08

30 Oct '08

Please consider adding this patch to add serialization to mersenne_twister. Since it is only active if BOOST_SERIALIZE_TWISTER is defined, it is completely harmless to those who don't use it.

3 6

[1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92
by Hartmut Kaiser 30 Oct '08

30 Oct '08

Anything I can do about this? What does this assertion mean? My setup: Linux 64Bit, gcc 4.2.4, serialization is used for polymorphic objects loaded from different shared libraries, shared libraries are loaded with dlopen(RTLD_GLOBAL|RTLD_LAZY). Assertion (extended_type_info.cpp:92) occurs during program termination (after main returned), during dlclose(). If anything else isn't possible, would it be appropriate to change the related code (before the release!) from: assert(start != end); // remove entry in map which corresponds to this type do{ if(this == *start) x.erase(start++); else ++start; }while(start != end); To: assert(start != end); // remove entry in map which corresponds to this type while(start != end) { if(this == *start) x.erase(start++); else ++start; } Which wouldn't remove the problem, but at least avoids hanging the program if assertions are off... Regards Hartmut

5 5