- Boost - lists.boost.org

no access to http://svn.boost.org/trac/boost/browser
by Frédéric Bron 29 Dec '10

29 Dec '10

Is http://svn.boost.org/trac/boost/browser down? I get: Error: Not Found No handler matched request to /browser Frédéric

5 5

Boost::Regex get URLs
by Tim Hsu 29 Dec '10

29 Dec '10

Hello guys, How do i using Boost::Regex or standard C++ to get all the URLs from a given string.... For example... i want to write a function that is.... But this code doesnt work.... I am not sure how to use Boost::Regex to solve it.... size_t GetUrlsFromString(std::string const& str, std::vector<std::string>& urls) { boost::regex re("<a\\s+href=\"([\\-:\\w\\d\\.\\/]+)\">"); boost::sregex_token_iterator p(str.begin(), str.end(), re, 1); boost::sregex_token_iterator end; while (p != end) { std::string surl(p->first, p->second); urls.push_back(surl); ++p; } return urls.size(); } Thank you!!!! Tim

2 1

[filesystem] what happened to default_name_check()?
by John Maddock 29 Dec '10

29 Dec '10

I'm in the process of porting bcp to Filesystem V3, as the change of default to V3 has broken bcp in Trunk. One thing that has come up is default_name_check() which has been removed. bcp set that to a "do nothing" check since it deals only with files that already exist, so it really does not want to be told that a file name isn't portable! :-) The tests seem to pass OK without this, but should I be worried about this? I couldn't find a rationale for the change in the docs... Cheers, John.

2 1

range adaptors
by barend 29 Dec '10

29 Dec '10

hi, First of all I like the new range adaptors, thanks for creating them. As much of Boost.Geometry is range-based, we like to support them. So I recently created a small integration, enabling things as: int n = boost::geometry::num_points(my_line | filtered(not_two())); where it filters out the points having a coordinate with 2 (just for testing). It works great, and most the adaptors, like strided, sliced, uniqued, reversed, seem very useful to me in this context. To enable this use I needed to specialize one of our structures to match boost range adaptors, like this: template<typename Filter, typename Geometry> struct tag<boost::range_detail::filter_range<Filter, Geometry> > { typedef typename geometry::tag<Geometry>::type type; }; This was all that was necessary to enable range adaptors. I now discover that their names are recently changed, from filter_range to filtered_range, etc (to match the adaptors, understandable). Of course library developers may do these things in a namespace called range_detail, but I've some questions: - do you encourage or support or discourage using filtered_range etc. in library code? Namespace range_detail is normally not used by library users, but there is no other way for us to adapt them: the filtered function returns a range_detail::filtered_range struct, and we have to specialize on that specific struct... - if this is a generic need, would it not be better to move them out of namespace *detail? - I noticed that sliced and copied are not in namespace range_detail but in adaptors, for me that sounds OK, but it is expected that for consistancy it might move namespace in any future - are there more changes on the way? Regards, Barend

3 2

[MSM] constructor arguments for sub state/machines
by Richard Szabo 29 Dec '10

29 Dec '10

Hi all I have tried out the new feature of msm : using constructor arguments for substate/machines : namely : player p( back::states_ << Playing(back::states_ << Song1(some_Song1_data)) , boost::ref(data),3); see doc : http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s05.html#d0e2320 I have some problem with it :(. this case state Playing and Song1 will be constructed first with default constructor in back end constructor than the internally constructed Playing and Song1 will be assigned to the newly construed Playing / Song1 copy which got copied by value. The only reason to use this feature is to able to use reference members in the substates but for that reference members must be initialised in the member initialisation list of the constructor of the substates in order to provide the references constructor arguments must be used. Since subsates must provide default constructors it is not possible to always initialise reference members from outside. Furthermore substate must be copyable and must implement assignment which brings more harm than good :(. Is there a way to resolve these problems ? PS: Looking to the test: http://svn.boost.org/svn/boost/trunk/libs/msm/test/Constructor.cpp I think there is a bug : at with line : fsm.context_ = 20; according my understanding the compiler will create a SomeExternalContext object on the stack of the context of on_entry(Event const&,FSM& fsm) function and will replace the fsm.context_ reference to the reference of the newly constructed object one the stack so when the on_entry function exits the SomeExternalContext object will be removed from the stack so the fsm.context_ reference becomes invalid so code p.context_.bla == 20 actually should crash because it uses invalid reference. I think it is just working by chance ? p.start(); // after this p.context_ will be invalid BOOST_CHECK_MESSAGE(p.context_.bla == 20,"error with fsm entry behavior"); // accessing invalid reference Br. Richie

1 0

Re: [boost] Packaging in cross-compiling environment
by Vladimir Prus 28 Dec '10

28 Dec '10

On Tuesday, December 28, 2010 00:18:11 Ben Gamari wrote: > On Mon, 27 Dec 2010 23:13:29 +0300, Vladimir Prus <vladimir(a)codesourcery.com> wrote: > > The includes are supposed to be added by this code in libs/python/build/Jamfile.v2: > > [ cond [ python.configured ] : > > <library>/python//python_for_extensions ] > > > > where 'cond' is basically C's ?: operator. From your log, I suspect that > > python.configured is not set, because python.jam is unable to run python > > to check it's version. > > > > Could you try the below patch? > > That did the trick. I get into the python build at this point (although > things still fail with "LONG_BIT definition appears wrong for platform > (bad gcc/glibc config?)." errors, but that another matter). Good to know. > > Perhaps this would be a cleaner patch? Yes, it's cleaner. However, I have to figure what the code is trying to do in the first place. I'll take a look at this between Jan 1 and Jan 11. Thanks, Volodya

1 0

Packaging in cross-compiling environment
by Ben Gamari 27 Dec '10

27 Dec '10

Hey all, A few days ago I got around to updating an embedded Linux image (cross-compiled with openembedded[1]). Unfortunately, I soon hit a some realized that the latest Boost version in OpenEmbedded is 1.41. I initially thought it was quite strange that such a well-used library could be so out-of-date and thought I might try my hand at getting 1.45 running. I quickly found that the reason OE's package is so old is because they are using the Boost CMake fork, which hasn't been updated for some time. At first I found it strange that the packagers would use an alternative build system like this, but this is before I met bJam. Unfortunately, bJam has made what should have been a straightforward version bump one of the most unpleasant packaging experiences I have ever had. After much pain, I finally have a user-config.jam[2] capable of starting the build, but it quickly fails with a variety of compile errors. The first is related to icu, the test program for which fails during linking, gcc.link bin.v2/libs/regex/build/gcc-target/debug/has_icu bin.v2/libs/regex/build/gcc-target/debug/has_icu_test.o: In function `main': /home/bgamari/OE/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/boost-1.45.0-r9.1/boost_1_45_0/libs/regex/bu ild/has_icu_test.cpp:24: undefined reference to `u_charFromName_4_2' collect2: ld returned 1 exit status "arm-angstrom-linux-gnueabi-g++" "-march=armv7-a" "-mtune=cortex-a8" "-mfpu=neon" "-mfloat-abi=softfp" "- L/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-rpath-link,/home/bgamari/O E/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-O1" "-Wl,--hash-style=gnu" "-mthumb-interw ork" "-mno-thumb" -L"/usr/lib" -Wl,-R -Wl,"/usr/bin" -Wl,-R -Wl,"/usr/lib" -Wl,-rpath-link -Wl,"/usr/lib" -o "b in.v2/libs/regex/build/gcc-target/debug/has_icu" -Wl,--start-group "bin.v2/libs/regex/build/gcc-target/debug/ha s_icu_test.o" -Wl,-Bstatic -Wl,-Bdynamic -licuuc -licui18n -licudata -Wl,--end-group -g -L/home/bgamari/OE/an gstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib This appears to due to the build having used the icu 4.2 headers from /usr which is given as --includedir (which should be the install directory, according to the documentation) yet for is for some reason added to the include path list, "arm-angstrom-linux-gnueabi-g++" "-march=armv7-a" "-mtune=cortex-a8" "-mfpu=neon" "-mfloat-abi=softfp" "-L/home/bgamari/OE/angstrom-dev/sysroots/armv7a-a ngstrom-linux-gnueabi/usr/lib" "-Wl,-rpath-link,/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-O1" "-Wl,--hash-style=gnu" "-mthumb-interwork" "-mno-thumb" -ftemplate-depth-128 -isystem/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include -O0 -fno-inline -Wall -pedantic -g -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_HAS_ICU=1 -I"." -I"/usr/include" -c -o "bin.v2/libs/regex/build/gcc-target/debug/has_icu_test.o" "libs /regex/build/has_icu_test.cpp" This causes the system's icu headers to override the cross-compile environment's, wrecking havoc when it comes to link time. Does anyone know why bJam is doing this? The second pertains to Python. I have specified a python configuration listing the correct include and library paths in my user-config.jam yet it appears that bjam ignores it "arm-angstrom-linux-gnueabi-g++" "-march=armv7-a" "-mtune=cortex-a8" "-mfpu=neon" "-mfloat-abi=softfp" "- L/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-rpath-link,/home/bgamari/O E/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib" "-Wl,-O1" "-Wl,--hash-style=gnu" "-mthumb-interw ork" "-mno-thumb" -ftemplate-depth-128 -isystem/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gn ueabi/usr/include -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_ SOURCE -DNDEBUG -I"." -c -o "bin.v2/libs/python/build/gcc-target/release/threading-multi/numeric.o" "libs/pyth on/src/numeric.cpp" ...failed gcc.compile.c++ bin.v2/libs/python/build/gcc-target/release/threading-multi/numeric.o... gcc.compile.c++ bin.v2/libs/math/build/gcc-target/release/threading-multi/sph_neumannf.o gcc.compile.c++ bin.v2/libs/python/build/gcc-target/release/threading-multi/list.o In file included from ./boost/python/detail/prefix.hpp:13:0, from ./boost/python/list.hpp:8, from libs/python/src/list.cpp:5: ./boost/python/detail/wrap_python.hpp:50:23: fatal error: pyconfig.h: No such file or directory compilation terminated. As indicated in the documentation, I have tried passing target-os=linux/python=2.6 to bjam but this does not appear to change bjam's behavior at all. When the build process begins, bjam produces this cryptic hint, error: No best alternative for /python_for_extensions next alternative: required properties: <python>2.6 <target-os>linux matched next alternative: required properties: <python>2.6 <target-os>linux matched error: No best alternative for /python_for_extensions next alternative: required properties: <python>2.6 <target-os>linux matched next alternative: required properties: <python>2.6 <target-os>linux matched Does anyone know what might be going on here? I seriously hope that the Boost project will consider dropping this seriously deficient, clunky, and user-unfriendly build system. When it works people will largely overlook its flaws, but most everyone I've heard who have actually worked with it seem to agree: stay away at all costs. I now completely understand why OpenEmbedded used the CMake fork. Cheers, - Ben [1] http://www.openembedded.org/ [2] user-config.jam using gcc : host : : <cxxflags> <linkflags> ; using gcc : target : arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=soft fp -L/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-rpath-link,/home/bgamar i/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-O1 -Wl,--hash-style=gnu -mthumb-interwork -mno-thumb : <cxxflags>-isystem/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/includ e -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb2 -isystem/home/bgamari/OE/angstro m-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -frename-registers -fomit-fr ame-pointer -O2 -ggdb2 -fpermissive -fvisibility-inlines-hidden <linkflags>-L/home/bgamari/OE/angstrom-dev/sysr oots/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-rpath-link,/home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstr om-linux-gnueabi/usr/lib -Wl,-O1 -Wl,--hash-style=gnu ; using python : 2.6 : python2.6 : /home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/python2.6 : /home/bgamari/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib ;

3 9

Phoenix3 Status update.
by Thomas Heller 27 Dec '10

27 Dec '10

Hi, some of you might have noticed that the version of phoenix3 located at https://svn.boost.org/trac/boost/browser/sandbox/SOC/2010/phoenix3 didn't compile from time time to. I just wanted to inform you that this is over now! Phoenix3 is in a stable state once again! All tests from boost.bind are passing! Placeholder unification is in place! Now ... up to documentation writing and checking for BLL compatibility ... The compilers i tested are: clang 2.8 gcc 4.5.1 gcc 4.2 (this only works with a patch for proto attached to this mail) I appreciate any feedback! I guess we can schedule the review now. Hartmut, does your offer still stand? Regards, Thomas

6 16

[dynamic_bitset] Append byte to the less significant end
by Romain CHANU 27 Dec '10

27 Dec '10

Hi, Here is my problem: i am using boost::dynamic_bitset and I would like to append a byte to the bitset. The idea is the following: 1) read a byte (represented as an unsigned char) 2) append the byte to the bitset 3) repeat these steps until there is no more data to read The current "append" in the API appends a byte to the most significant end. I would like to actually append the byte to the less significant end. The only solution that I have found so far is to concatenate two bitsets: http://pastebin.com/cguqaMgS I am not sure this is a very efficient way. Do you have any other suggestions? Thank you for your help and Merry Christmas. Romain

2 2

[range][stride] broken?
by Maxim Yanchenko 27 Dec '10

27 Dec '10

Consider the following test: std::vector<int> v; boost::push_back( v, boost::irange(0, 30) ); boost::copy( v, std::ostream_iterator<int>(std::cout, " ")); std::cout << std::endl << std::endl; for ( int i = 1; i <= 30; i++ ) { std::cout << std::setw(2) << i << ": "; boost::copy( v | boost::adaptors::strided(i), std::ostream_iterator<int>(std::cout, " ")); std::cout << std::endl; //std::cout << std::setw(2) << "" << ": "; //BOOST_FOREACH( int x, v | boost::adaptors::strided(i) ) // std::cout << x << ' '; //std::cout << std::endl; } Here is the output: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 1: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 2: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 3: 0 3 6 9 12 15 18 21 24 27 4: 0 4 8 12 16 20 24 ///< where is 28? 5: 0 5 10 15 20 25 6: 0 6 12 18 24 7: 0 7 14 21 ///< where is 28? 8: 0 8 16 ///< where is 24? 9: 0 9 18 ///< where is 27? 10: 0 10 20 11: 0 11 ///< where is 22? ... 16: 0 ///< where is 16? etc If you uncomment the BOOST_FOREACH code, it crashes at stride=4 (prints 28 and then crashes): 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 1: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 : 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 2: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 : 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 3: 0 3 6 9 12 15 18 21 24 27 : 0 3 6 9 12 15 18 21 24 27 4: 0 4 8 12 16 20 24 /usr/include/stlport-5.2.1/stlport/stl/debug/_iterator.h(170): STL assertion failure : _Incrementable(*this, __n, _Iterator_category()) : 0 4 8 12 16 20 24 28 unknown location:0: fatal error in "test": signal: SIGABRT (application abort requested) Nothing changes if I replace "v | boost::adaptors::strided(i)" with "boost::adaptors::stride(v,i)". It's Boost 1.45.0 on STLPort 5.2.1, gcc 4.4. IF I switch from std::vector to boost::array, BOOST_FOREACH just doesn't stop and keeps printing memory until crash, so I don't think it's an STLPort problem. Am I doing anything wrong, or range::stride is broken? Thanks, Maxim

3 10