- Boost - lists.boost.org

[date_time] Major commit in trunk
by Andrey Semashev 01 Nov '08

01 Nov '08

I have committed my changes to the DateTime library in trunk (revision 49506). If anyone starts experiencing problems with it, please, let me know.

2 1

Re: [boost] [Boost-commit] svn:boost r49504 - trunk/tools/build/v2/tools
by Juergen Hunold 01 Nov '08

01 Nov '08

HI Volodya ! Are you sure that removing gcc flavour was intended ? On Saturday 01 November 2008 09:21:57 ghost(a)cs.msu.su wrote: > Modified: trunk/tools/build/v2/tools/gcc.jam > =========================================================================== >=== --- trunk/tools/build/v2/tools/gcc.jam (original) > +++ trunk/tools/build/v2/tools/gcc.jam 2008-11-01 04:21:56 EDT (Sat, 01 > Nov 2008) @@ -34,6 +34,7 @@ > > > feature.extend toolset : gcc ; > +# feature.subfeature toolset gcc : flavor : : optional ; > > toolset.inherit-generators gcc : unix : unix.link unix.link.dll ; > toolset.inherit-flags gcc : unix ; > @@ -130,6 +131,7 @@ > condition = [ common.check-init-parameters gcc > : version $(version) > ] ; > + condition = $(condition) ; #/<toolset-gcc:flavor> ; > } > Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

1 0

Style Guideline
by Robert Jones 31 Oct '08

31 Oct '08

Writing the kind of code that you see in the Boost libraries is something of a step change from the day-to-day production code that I write, and I suspect most of us write (Joel, Eric, Dave, Peter and others excepted of course! :-) ), and writing it, I find, is a rather different matter from reading it and broadly understanding it! So,....enable_if.... Is enable_if intended only to include or exclude complementary instantiations of different templates from the possible set, or also to control whether a particular instantiation is available at all? Say I have a class which I want to be able to instantiate only for vectors. Is it sensible to create an is_vector<> template and then use enable_if, or should I simply allow instantiation to fail when the code uses some aspect of vectors which is specific to vectors? Does the situation change if it is vectors or lists that are permissible? Or if it's anything with begin() & end() defined? Or am I making a complete hash of this, and ought to be thinking in a different paradigm? Thanks in advance. - Rob.

2 1

[Timer] Inconsistent behaviour
by Jordans, R. 31 Oct '08

31 Oct '08

Hey all, I was looking at Boost.Timer and I noticed that it shows different results when it's used in a threaded program on Windows or Unix machines. A closer inspection revealed that it uses clock() to do it's timings. Digging a bit deeper I found that clock() is specified differently on Windows than it is in my Linux man-page. On windows it counts 'wall clock' time, basically what I'd expect from a class named timer but on Linux it counts CPU time. Thus it will give the result for completely different concepts of time elapsed depending on my system. Two questions; 1) is there a good way to solve this, 2) if not, could it at least be noted in the documentation. Thanks, Roel

6 6

first Visual Studio 2010 CTP is out, c++0x
by Cory Nelson 31 Oct '08

31 Oct '08

In case anyone missed it, a VS10 CTP is out with partial 0x support (lambda, rvalue, static assert, and "auto"), better intellisense, and a modern c++ parallel library. http://www.microsoft.com/downloads/details.aspx?familyid=922b4655-93d0-4476… -- Cory Nelson

10 16

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