- Boost - lists.boost.org

[PATCH 1/2] Fixed warning: ignoring return value of 'size_t fread(void*, size_t, size_t, FILE*)'
by Vasyl' 30 Dec '10

30 Dec '10

--- boost/uuid/seed_rng.hpp | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)

2 1

QuickBook question
by Marshall Clow 29 Dec '10

29 Dec '10

I am working one some quickbook docs and they start out like this: > [library The Boost Algorithm Library > [quickbook 1.5] > [id algorithm] > [dirname algorithm] > [purpose Library of useful algorithms] > [category algorithms] > [authors [Clow, Marshall]] > [copyright 2010 Marshall Clow] > [source-mode c++] > [license > Distributed under the Boost Software License, Version 1.0. > (See accompanying file LICENSE_1_0.txt or copy at > [@http://www.boost.org/LICENSE_1_0.txt]) > ] > ] > Later (in the same file), I want to drop a link. So, I write: > [link algorithm.all.none_of_if none_of_if1] (where all is a section, and none_of_if is a heading in that section) but this doesn't work! Some investigation shows that > [link the_boost_algorithm_library.all.none_of_if none_of_if2] does work - even though the documentation says that the first element in the link is the document id, not the document title. Am I misunderstanding something? -- Marshall

2 2

Inspection script not running?
by John Maddock 29 Dec '10

29 Dec '10

Title says it all really, Cheers, John.

2 1

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 28 Dec '10

28 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