March 2010 - Boost - lists.preview.boost.org

[mpl] Basic mpl sequence question
by Michael Robinson 04 Mar '10

04 Mar '10

Hi, I'm a newbie with mpl and I'm trying to execute some example code from the book "C++ Template Metaprogramming", by Abrahams and Gurtovoy: >From section 5.2, p. 78, Sequences and Algorithms: I wrote this code: // // mpltest.C // #include<boost/mpl/vector.hpp> using namespace boost; typedef mpl::vector<char,short,int,long,float,double> types; typedef mpl::find<types,long>::type long_pos; int main() { } And I get this compiler error on the mpl::find line: $ g++ mpltest.C -ompltest mpltest.C:10: error: expected initializer before ‘<’ token Can you tell me what I'm doing wrong? Thank you, Mike FYI/IYC: $ g++ --version g++ (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2) Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ____________________________________________________________ Get Free Email with Video Mail & Video Chat! http://www.netzero.net/freeemail?refcd=NZTAGOUT1FREM0210

2 1

[Filesystem V3] Filesystem Version 3 beta 1 available for download and comment
by Beman Dawes 03 Mar '10

03 Mar '10

The first beta release of Boost.Filesystem Version 3 is now available. The documentation can be viewed at http://mysite.verizon.net/beman/v3/index.htm Important differences from the prior version: http://mysite.verizon.net/beman/v3/v3.html The beta can be downloaded from the Boost vault. See http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Files… Installing the beta is described at http://mysite.verizon.net/beman/v3/install_distro.html I'm concerned about breaking existing code. While some workarounds have been provided already, I'd open to further suggestions as to how to mitigate code breakage. The tentative plan for integrating V3 into the boost release cycle involves several steps: * For the first boost release cycle, ship V2 as the default, but V3 is present and can be activated by users. * For an additional boost release cycle, ship V3 as the default, but V2 is present (but deprecated) and can be activated by users. * For the following boost release cycle, V2 is removed and no longer supported. The plan is to go through as many beta cycles as needed to reach stability. Although quite a bit of testing has already been done, this is definitely beta software that isn't ready yet for production use. Any comments appreciated. --Beman

10 23

[range] resulting range type
by Andrey Torba 03 Mar '10

03 Mar '10

Hi All, When i implement range based algorithms i always have to write `boost::iterator_range<typename boost::range_iterator<R>::type>'. It is pretty annoying. i.e.: template<class R> boost::iterator_range<typename boost::range_iterator<R>::type> Algo(R& r); I would like to have special metafunction in Boost.Range for such cases to make code more cleaner: template<class R> typename boost::make_range<R>::type Algo(R& r); What do you think? -- Regards, Andrey

3 3

[graph] gcc 3.4 & 4.0 currently broken
by Ralf W. Grosse-Kunstleve 03 Mar '10

03 Mar '10

boost svn trunk rev 60079 broke our gcc 3.4 and 4.0 builds (various platforms). The problem is line 52 in boost/graph/two_bit_color_map.hpp BOOST_STATIC_ASSERT(elements_per_char > 0); It fails with (gcc 3.4 in this case): % g++ -o boost/libs/python/src/object/inheritance.o -c -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_BOOL_INT_STRICT -fPIC -fno-strict-aliasing -w -DNDEBUG -O3 -ffast-math -ftrapping-math -DBOOST_ALL_NO_LIB -DBOOST_DISABLE_THREADS -I/net/chevy/raid1/rwgk/hot/boost -I/usr/include/python2.3 /net/chevy/raid1/rwgk/hot/boost/libs/python/src/object/inheritance.cpp In file included from /net/chevy/raid1/rwgk/hot/boost/boost/graph/breadth_first_search.hpp:26, from /net/chevy/raid1/rwgk/hot/boost/libs/python/src/object/inheritance.cpp:7: /net/chevy/raid1/rwgk/hot/boost/boost/graph/two_bit_color_map.hpp:52: error: non-constant `(((int)boost::two_bit_color_map<IndexMap>::elements_per_char) > 0)' cannot be used as template argument /net/chevy/raid1/rwgk/hot/boost/boost/graph/two_bit_color_map.hpp:52: error: `value' is not a member of `<declaration error>' Commenting out line 52 resolves the error. I printed the value of elements_per_char and it appears to be correct (4). There is no problem with gcc 3.2 and gcc 4.1 through 4.4. Maybe a BOOST_WORKAROUND to disable the static assert for 3.4 and 4.0? Ralf

2 3

[uuid] basic_random_generator doesn't produce a fully randomized uuid when sizeof(unsigned long) == 4
by Sylvester-Bradley, Gareth 03 Mar '10

03 Mar '10

Hi Andy, I wonder if the following is a flaw in basic_random_generator<> (boost/uuid/uuid_generators.hpp, line 366-374)? On many platforms sizeof(unsigned long) == 4. This means that the first 8 bytes of the uuid are populated with random data, but in my tests the remaining 8 bytes are populated with repeated data, and then only by relying on the undefined behaviour of >> when its "right operand is greater than or equal to the length in bits of the promoted left operand." For example, try the following test program with a Win32 build by Visual C++ 9.0 - #include <iostreams> #include <boost/uuid/uuid_generators.hpp> #include <boost/uuid/uuid_io.hpp> int main( int, char*[] ) { std::cout << boost::uuids::random_generator()() << std::endl; return 0; } This produced for me: f1633d75-ee94-47b9-ae94-37b9ee9437b9 Or wrapped to show the problem: f1633d75- ee94-47b9- ae94-37b9 ee94 37b9 Is 8 bytes of randomness enough, or is this a mistake? Best regards, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

4 4

Boost.Log formal review upcoming
by Vladimir Prus 03 Mar '10

03 Mar '10

Boosters, the formal review of the Boost.Log library, written by Andrey Semashev, will start in a week from now, on March 8, 2010 and will run through March 17, 2010. The documentation for the current version is available at: http://boost-log.sourceforge.net The downloads at at: http://sourceforge.net/projects/boost-log Because the library is relatively big and important, you might want to take a look in advance, without waiting for the formal review. Please note that reports of real-world usage will be particularly appreciated -- even if you don't have the time to to do everything formal review checklist requires please still report your experiences. To clarify timelines, the formal reviews are accepted from 23:59, March 7, PST = 2:59, March 8, EST = 7:59 March 8, GMT = 10:59, March 8 MSK until 23:59, March 17, PST = 2:59, March 18, EST = 7:59 March 18, GMT = 10:59, March 18 MSK Reviews submitted outside of this frame are not guaranteed to be processed. Thanks, Volodya

9 21

Boost.Coroutine
by Daniel Larimer 03 Mar '10

03 Mar '10

I am attempting to use boost.coroutine; however, it is not behaving for me. Perhaps someone could shed some light? Here is what happens: 1 start coroutine A 2 do some work.... 3 my_wait_for_value() 4 future<R> f(self); 5 callback = make_callback(f); 6 r = do_wait( f ) 7 boost::coroutines::wait( f ) // blocks and the coroutine exits , goto A 8 return *f; 9 print( "here" ) 10 return r; 11 do some more work A start coroutine B B do some work C callback_from_coroutine_A ( R ) // goto line 8 D .... back to line 8 8 r = *f; // got the right future value 9 print("here") 10 return r; 11 ????? After returning r on line 10, I should end up back on line 11, but instead end up on line D. I clearly setup the future, waited, started another coroutine, set the value of the future, returned 2 levels of the stack, but the 3rd level dumped me off back in a different coroutine. Running on Mac OS X 10.6. Single threaded code. Dan

1 1

the best possible c++ properties (implementation).
by Germán Diago 02 Mar '10

02 Mar '10

Hello. I've been trying hard to implement the best possible properties sytem in c++ (version 0x). For now, I'm quite satisfied with the result, but it can be improved a little. The properties are implemented in a header called (surprisingly!) Property.hpp Classes: template TROProperty and TRWProperty for trivial properties, which are those which you can use very straightforward without defining setters or getters and it stores the property value inside. templates RWProperty and ROProperty, for which you need to define a storage (if needed) and getters and setters. FEATURES: - You can define a getter as a function that returns *ANYTHING* and it will deduce parameters, constness and everything it needs. - You can define a setter as a function that returns void and takes one parameter. The deduction machinery will do the rest. So, for trivial properties there is little to explain: class Person { public: TROProperty<unsigned int> Age; Person(int age) : Age(age) {} }; int main(int argc, char * argv[]) { Person p(26); cout << p.Age << endl; } For elaborated properties, you have freedom in defining the get and set functions, as long as the get function gets just one parameter and the set function sets one parameter and returns void. The usage of elaborated properties is done through a macro: class Agenda { typedef Agenda ClassName; //Needed for elaborated properties. vector<Person> persons_; Person * getCurrentPerson() { return persons_[Position]; } public: TrivialProperty<int> Position; PROP_ROPROPERTY(CurrentPerson); .... Agenda() : PROP_PROPERTY_INIT(CurrentPerson) {}; }; And now it's ready to be used. For now the features are: -Implicit conversion to the underlying type. -Operator overloading (just a sample of the possible operators, just implemented operator++ and some others) -Comparison operators... -Construction assignment, etc from any other property that has a convertible type or from a data type that makes sense. - Move and copy construction where it makes sense. - Compare, for example, a Property<int> to an int or another property with a convertible value to a Property<int>. If it makes sense, it must work. The same for any other operator. - You can obtain the underlying type for a property through operator(), which makes sense in some contexts. For example, suppose you have a class Person with properties Name, SurName and Age and a class Agenda with a property CurrentPerson which returns a pointer to a Person. You can do like this: string name = agenda.CurrentPerson().Name; you can assign Name to a string or any other property that accepts a string (untested but you could). But you don't need operator() when implicit conversion takes place. personsbyage_[aperson.Age] //No need for operator(), implicit conversion Caveats: ROProperty TROProperty I cannot enforce a private operator= because for that I need a workaround I don't know of or extended friend declarations, which are part of c++0x. So for now, these properties are exactly the same as their writeable counterparts without read-only enforcement. In the implementation part, for elaborated properties I have a template like this: template <class Getter, class Setter> class RWProperty; The same goes for ROProperty. Just with that and the macro to ease the writing of properties, you can get a property. These properties must be constructed with the this pointer AND the pointer to member functions. I'm experimenting (but I can't find a way to do it) with something like this: template <class Getter, class Setter, Getter, Setter> class RWProperty; so that the construction of properties wouldn't need the pointers, because they would be passed as template parameters. But inside the template I have an ambiguity problem. Getter and Setter are pointer to member function types and Getter and Setter parameters are the addresses. For now I've found the properties very usable. The only caveats are the enforcement of operator= and the passing of pointer to members as part of initialization. If I can solve those, we can get a good properties implementation of properties and the initialization of elaborated properties would be just with the this pointer (and a value if you want to initialize with a value). This is a work in progress. For now I've used c++0x, but I think I can use BOOST_TYPEOF (maybe) and some other things in order to translate it to current c++. The code is attached. It's an (unfinished) miniapplication of an Agenda made in gtkmm compiled under g++ 4.5 svn. Take a look at the Property.hpp and the application and tell me what you think. I would like to be able to pass pointer to member functions as template arguments in order to avoid initialization of pointers as parameters. compile with: g++ -std=c++0x `pkg-config gtkmm-2.4 --libs --cflags` Person.cpp Agenda.cpp Window.cpp main.cpp -o Agenda You can just add people with "Añadir" Button and traverse with < and > button. It does not do anything special, it's just to test properties.

9 14

Boost
by Enrique Nieloud 02 Mar '10

02 Mar '10

Hi, I just wanted to report that the following two links are broken: boost/gil/extension/numeric/sampler.hpp boost/gil/extension/numeric/resample.hpp In the file: http://www.boost.org/doc/libs/1_42_0/libs/gil/example/resize.cpp thanks, - Enrique

3 2

[iostreams][patch] position_to_offset() is broken for Microsoft Visual C++/Dinkumware
by Sylvester-Bradley, Gareth 02 Mar '10

02 Mar '10

The recent work on Boost.Iostreams by Richard Smith and Daniel James has really improved this library. Thanks guys; this kind of maintenance is really appreciated. I have found a bug in position_to_offset() on Microsoft Visual C++/Dinkumware demonstrated by the following test app - #include <iostream> #include <boost/iostreams/positioning.hpp> int main( int, char*[] ) { const boost::int64_t twoGB = 2 << 30; std::streampos pos = boost::iostreams::offset_to_position( twoGB ); pos -= 2; if ( twoGB - 2 != boost::iostreams::position_to_offset( pos ) ) { std::cout << "Failed!" << std::endl; return -1; } return 0; } This has the potential to affect many parts of Boost.Iostreams but in particular it means the "small seeks optimization" in indirect_streambuf.hpp is broken. I believe this is resolved by the following patch to boost/iostreams/positioning.hpp. 105,106c105,106 < static_cast<stream_offset>(static_cast<std::streamoff>(pos)) - < static_cast<stream_offset>(_FPOSOFF(streampos_to_fpos_t(pos))); --- > static_cast<stream_offset>(static_cast<std::streamoff>(pos) - > _FPOSOFF(streampos_to_fpos_t(pos))); Raised on Trac: https://svn.boost.org/trac/boost/ticket/3969 Best regards, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

1 0

Boost_Test: Initialize fixture only once
by Dmytro Ovdiienko 02 Mar '10

02 Mar '10

Hello All, I have a question about boost test. Please help. I have set of test_suites. Every test_suite consists of a bunch of test_cases. Every test case should be initialized before execution. So, I created Fixture for every test_suite. The problem is Fixture initialization takes a lot of time and boost creates it for every test_case (not for every test_suite) How to solve this? Best regards. Dima

3 5

[iostreams] array and gzip_decompressor
by Nikolay Mladenov 01 Mar '10

01 Mar '10

Recently I came back to a source written some time ago, that was running then but it is not compiling now. the failing snippet is: typedef boost::iostreams::composite<boost::iostreams::gzip_decompressor, boost::iostreams::array_source> array_gzip_decompressor; boost::iostreams::gzip_decompressor filter; boost::iostreams::array_source source(&_storage[0], _storage.size()); array_gzip_decompressor dev(filter,source); boost::iostreams::stream_buffer<array_gzip_decompressor> ibuf(dev); the error is: > boost\iostreams\read.hpp(191) : error C2039: 'putback' : is not a member of 'boost::iostreams::detail::direct_adapter<Direct>' > with [ Direct=boost::iostreams::array_source ] It seems to me that gzip_decompressor requires peekable source, but array_source is not peekable. Is there another way I should be creating gzipped stream into memory? Or maybe the arrays could be made peekable? Thanks in advance, Nikolay Mladenov

3 5

boost::optional<void>
by Daniel Larimer 01 Mar '10

01 Mar '10

I am writing some generic code and would like to handle "all values" the same way; however, I keep running into the problem of return void return types that need "special treatment". There is nothing I can do about it most of the time except template specialization. That said, it would be helpful if boost::optional<void> could have some sensible default implementation where it acts more or less like a boolean. As it is, I will probably provide my own specialization of boost::optional to simplify my templates. Any thoughts on this? Dan

4 4

[ITL][Review] A late mini review
by Thomas Klimpel 01 Mar '10

01 Mar '10

> Please always state in your review, whether you think the > library should be accepted as a Boost library. ITL should be accepted as a Boost library. > - What is your evaluation of the design? I haven't spend sufficient time reviewing the library to be able to judge the design. At least, I haven't seen any obvious flaws during my short review. > - What is your evaluation of the implementation? I took a cursory look at all source (header) files, and they look nicely written. I took a cursory look at the directory structure, to verify that it follows boost conventions. It does so in general, but I was surprised to find a "libs/itl/build" folder, since I "know" that ITL is a headers only library. The content of the build folder also didn't make me happy (it's extremely "unportable"), but this is a completely different topic that has nothing to do with this specific library. The template meta programming in boost/itl/type_traits/* could follow MPL conventions more closely. > - What is your evaluation of the documentation? The documentation is nicely written. However, please don't invent new words like "aggrovering" or "unon". Please also try to avoid changing the meaning of existing words like "neutron". > - What is your evaluation of the potential usefulness of the library? The need to work with "interval sets" arises sufficiently frequently in "time based" and "geometry based" problem domains to warrant a library dedicated especially to this problem domain. (In my review of Boost.Polygon, I pointed out that interval set concepts were missing.) I have to admit that I haven't spend sufficient time evaluating ITL to be able to judge whether ITL is able to handle all these needs. > - Did you try to use the library? With what compiler? Did you have any problems? No, I didn't try to use the library. > - How much effort did you put into your evaluation? > A glance? A quick reading? In-depth study? Some month ago, I read through the documentation just for the pleasure it gave me, pondered a bit about the concept and looked at the BoostCon2009 slide show. I was certainly planning to do a proper review during the review period, but I was (and still am) occupied with other things. What I've done now while writing this review was just a glance. > - Are you knowledgeable about the problem domain? This is not important in this case, since I haven't spend enough time for the review anyway. Regards, Thomas P.S.: As I guessed from recent experience, the review period has just been extended. However, I decided to submit this mini review nevertheless. I may have a look at "I have to admit that I haven't spend sufficient time evaluating ITL to be able to judge whether ITL is able to handle all these needs." with respect to the issue raised by Phil Endecott in http://lists.boost.org/Archives/boost/2010/02/162198.php (and write about it in case I can make up my own opinion), because this seems to be an interesting question. Even so I want to thank Phil Endecott for his courage to bring up this issue, and I guess that he is right (in a certain sense), I think it is wiser to base my review only on my personal experiences and not on my judgment of whether Phil is right or wrong with respect to this issue.

2 1

[numeric][intervall] msvc_rounding_control.hpp broken in 64 bit build.
by Juergen Hunold 01 Mar '10

01 Mar '10

Hi ! boost/numeric/interval/detail/msvc_rounding_control.hpp does not compile in x64 (64bit) build with (at least) msvc-9 The offending commit is: ------------------------------------------------------------------------ r59350 | marshall | 2010-01-29 19:01:34 +0100 (Fri, 29 Jan 2010) | 1 line Applied patches to fix #2512 and #2513 ------------------------------------------------------------------------ This does not show up in regression test because we don't have a test runner running a 64bit version of msvc. The compiler bails out on the x86 inline assembler introduced in that commit when running in 64bit mode. The simple patch is to fall back to the old behaviour using "rint" for target "x64": Index: msvc_rounding_control.hpp =================================================================== --- msvc_rounding_control.hpp (revision 59697) +++ msvc_rounding_control.hpp (working copy) @@ -25,7 +25,7 @@ namespace interval_lib { namespace detail { -#if BOOST_MSVC < 1400 +#if BOOST_MSVC < 1400 || defined(WIN64) extern "C" { double rint(double); } #else inline double rint(double x) I can apply this if necessary. Tested with msvc-9.0 I have not looked into the referenced tickets. Any (better) ideas ? 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 !

2 1

ptr_container move support
by Zachary Turner 01 Mar '10

01 Mar '10

The collections in ptr_container don't seem to support move constructors. All the recent compilers support r-value refs, has there been any discussion of adding support for this? Zach

2 1

[Serialization] extended_type_info.hpp
by fab 01 Mar '10

01 Mar '10

Hi, With boost 1.42.0, when I use BOOST_CLASS_EXPORT, I always need to include extended_type_info.hpp to resolve this error : xxx.hpp:153: error: 'guid_defined' is not a template xxx.hpp:153: error: explicit specialization of non-template 'boost::serialization::guid_defined' xxx.hpp:153: error: expected initializer before '<' token xxx.hpp:153: warning: 'boost::archive::detail::<unnamed>::init_guid<MyClass>::g' defined but not used Maybe extended_type_info.hpp can be included in export.hpp ? Fabien Castan

4 5