- Boost-users - lists.boost.org

[regex] problem with pattern match in 1.33.0
by Richard Hadsell 29 Jan '07

29 Jan '07

I am having a problem with a regex_match in Boost 1.33.0. Perhaps I am missing something; perhaps it is a bug that has been fixed. The pattern "[+-]?(\\d+(\\.\\d*)?|\\.\\d+)([Ee][+-]?\\d+)?" should match only floating-point numbers that can be read by sscanf. (Extra escape characters are for C++, of course.) Yet regex_match returns true for "3.6.5". I guessed that the problem might be in the '(...)?' expression just before the alternative operator '|', so I tried this: "[+-]?(\\d+|\\d+\\.\\d*|\\.\\d+)([Ee][+-]?\\d+)?". With this pattern regex_match returns false for "3.6.5". I am using it, but I consider it a workaround. Can someone explain what I have missed or whether this is a bug? -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

2 3

[Review] Review of the Accumulator library begins today, Jan. 29
by John Phillips 29 Jan '07

29 Jan '07

The formal review of the Boost.Accumulators library, submitted by Eric Neibler begins today and ends on Wednesday, February 7. The library is available from http://boost-consulting.com/vault/index.php?directory=Math%20-%20Numerics From the documentation: Boost.Accumulators is both a library for incremental statistical computation as well as an extensible framework for incremental calculation in general. The library deals primarily with the concept of an accumulator, which is a primitive computational entity that accepts data one sample at a time and maintains some internal state. These accumulators may offload some of their computations on other accumulators, on which they depend. Accumulators are grouped within an accumulator set. Boost.Accumulators resolves the inter-dependencies between accumulators in a set and ensures that accumulators are processed in the proper order. Your comments may be brief or lengthy. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: • What is your evaluation of the design? • What is your evaluation of the implementation? • What is your evaluation of the documentation? • What is your evaluation of the potential usefulness of the library? • Did you try to use the library? With what compiler? Did you have any problems? • How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? • Are you knowledgeable about the problem domain? And finally, every review should answer this question: • Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. All interested parties are encouraged to submit a review. These can be sent to the developer list, the user list, or if you don't want to share your review with the general public it can be sent directly to me. Thanks to all for the work you will do on this review. John Phillips Review Manager

1 0

[program_options] Allowing Unknown Options
by Imre Palik 29 Jan '07

29 Jan '07

Hi, I try to use the same configuration file with several programs. For this I hope, I can somehow allow unknown options for config files. The method described in the documentation only works for the command line, and skimming through the code didn't help either. Is there any other way to do it, than patching the common_config_file_iterator? If no, then what are the submission rules for patches? Thx ImRe

1 0

Re: [Boost-users] Euclidean MST using CGAL and Boost
by miles mccoo 29 Jan '07

29 Jan '07

> > > Hi, > > > I patched together code for Euclidean MST based on CGAL and Boost. I > posted in on Wikipedia because I couldn't think of a more appropriate place. > > > http://en.wikipedia.org/wiki/Sample_Code_for_Euclidean_MST_using_Boost_and_… > > > > I would love to receive feedback on it. I hope someone finds it's useful. > > > > Miles >

2 1

Work-around for linker removed BOOST_AUTO_TEST_CASE code
by daniel.hawson＠virgin.net 29 Jan '07

29 Jan '07

I'd encountered a problem with a particular way I'd set up a test application where some BOOST_AUTO_TEST_CASE functions would be executed while others wouldn't. I suspect this may be Visual Studio (2005) specific. I've got a work-around, which I thought might help others in the same situation. The scenario is this - Main test application: testapp.cpp - #define BOOST_AUTO_TEST_MAIN "TestApp for some Lib" #include <boost/test/auto_unit_test.hpp> BOOST_AUTO_TEST_CASE(IGetExecutedByTestFramework) { BOOST_CHECK(false); } External library, containing: somemodule_tests.cpp - #include "somemodule.h" #include <boost/test/auto_unit_test.hpp> //Test functionality provided by somemodule.h //... BOOST_AUTO_TEST_CASE(IDontGetExecuted) { BOOST_CHECK(false); } My Visual Studio solution contains two projects - - mylibtestapp: A console executable to run all test cases in mylib Contains only testapp.cpp - mylib: A statically linked lib containing a bunch of .cpp/.h files and, so far, just one ..._tests.cpp file. The solution is set up so that mylibtestapp depends on mylib. It also explicitly links with the boost 'unit_test_framework.lib'. It compiles and links fine. When running, only the 'IGetExecutedByTestFramework' gets executed. I manually expanded the BOOST_AUTO_TEST_CASE macro for 'IDontGetExecuted' and the debugger wouldn't step into any of the test registrar object constructor code, so I assume the linker decided to strip out the code for some reason. As soon as I added the following to somemodule_tests.cpp - int g_fiddle; and change testapp.cpp to 'extern int g_fiddle;' and manually insert the 'init_unit_test_suite(int argc, char* argv[])' with some trivial use of 'g_fiddle' (using it in a printf), then both test cases get executed. After poking around with the linker options little further, I've found that all unit tests will run as originally intended, without having to use any extern frigs, so long as the mylibtestapp's 'Configuration Properties'>Linker>General>'Use Library Dependency Inputs' is set to 'Yes'. The difference being that the linker command-line now contains mylib.lib instead of the individual .o files of mylib. Weird. -- Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.12/655 - Release Date: 28/01/2007 13:12

1 0

std::string to std::wstring
by John Christopher 29 Jan '07

29 Jan '07

Hello, Does Boost contain facilities to convert std::string into std::wstring and the other way around? Thanks in advance

5 7

[mpl] Problem comparing iterators
by Küppers, Ben 29 Jan '07

29 Jan '07

Gents, For illustration purposes I created the following code that iterates through a sequence and accumulates the distances between the current iterator and the beginning of the sequence. Somehow this code works for normal ranges (range1 and range2) but fails to compile for joint_view range3 (80-plus errors). Changing the call to distance to compare between begin and end or between _2 and _2 (self) works. I am at a loss here. Can someone point out what I am doing wrong? Thanks Ben #include <iostream> #include <boost/mpl/arithmetic.hpp> #include <boost/mpl/begin.hpp> #include <boost/mpl/distance.hpp> #include <boost/mpl/for_each.hpp> #include <boost/mpl/iter_fold.hpp> #include <boost/mpl/joint_view.hpp> #include <boost/mpl/plus.hpp> #include <boost/mpl/push_back.hpp> #include <boost/mpl/range_c.hpp> #include <boost/mpl/vector_c.hpp> namespace mpl = boost::mpl; template< class _Sequence > struct distances { typedef typename mpl::iter_fold< _Sequence, mpl::long_< 0 >, mpl::plus< mpl::_1, mpl::distance< typename mpl::begin< _Sequence >::type, // typename mpl::end< _Sequence >::type // mpl::_2, mpl::_2 > > >::type type; }; int main( int argc, char* argv[] ) { typedef mpl::range_c< char, 'a', 'd' >::type range1; typedef mpl::range_c< char, 'm', 'q' >::type range2; typedef mpl::joint_view< range1, range2 >::type range3; typedef distances< range3 >::type type1; std::cout << type1(); std::cout << std::endl; return 0; } This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

2 1

'is_pointer_like' or 'is_smart_pointer' or similar, again
by Gottlob Frege 29 Jan '07

29 Jan '07

A while back there was discussion of detecting smart pointers. The discussion started with Ovanes Markarian Date: Thu, 22 Jun 2006 19:19:07 +0200 (CEST) From: "Ovanes Markarian" <om_boost(a)keywallet.com> Subject: [Boost-users] inspecting templates and boost::is_pointer To: boost-users(a)lists.boost.org Message-ID: <41230.194.138.18.132.115099674 > > 7.squirrel(a)www.keywallet.com> > Content-Type: text/plain;charset=iso-8859-1 > > Hello all, > > I am trying to specialize boost::is_pointer so, that it can determine if a > type is a pointer > wrapper (shared_ptr, auto_ptr, weak_ptr). ..... And, first off, yes, we now know that expanding is_pointer would be bad. So, instead we want 'is_pointer_like' or something like that. There were suggestions regarding detecting operator->() and/or unary operator *(). What ever came of this? I am asking, of course, because I could really use an 'is_pointer_like<>' or 'is_smart_ptr' right now. And if it is still unsolved, I've got 2 more suggestions: detecting that boost::get_pointer() (for boost::bind) has been defined, and/or just looking for some common internals of the smart_ptrs (hack!) - or adding some common internal typedef/value - ie T::is_smart_pointer. Thanks, Tony

4 6

[Boost-build]/[bjam] Problem compiling CVS bjam from sources
by D Garvey 29 Jan '07

29 Jan '07

As far as I'm aware I'm using pretty much a default ubuntu installation with gcc 4.1.2. After compiling bjam from sources, using these<http://boost.org/boost-build2/doc/html/jam/building.html>instructions, and running the tests, I get the following failures: root@---------:/usr/local/src/boost/tools/jam/test# sh test.sh > --- Testing SHELL builtin... > --- Testing W32_GETREGNAMES builtin... > --- Testing var expansion... > --- Testing var on target semantics... > --- Testing var expansion... > var_expand.jam:14: error: [FAILED] (==) '' > var_expand.jam:17: error: [FAILED] (==) '' > --- Complete: PASSED(21) *FAILED(2)* > The output from the compilation is below (it seems to work, even with the lists of warnings): root@hallah:/usr/local/src/boost/tools/jam# cd src | sh ./build_dist.sh > ../../../Jamfile.v2:335: in load-aux > rule path.glob-tree unknown in module Jamfile</usr/local/src/boost>. > /usr/share/boost-build/build/project.jam:318: in load-jamfile > /usr/share/boost-build/build/project.jam:68: in load > /usr/share/boost-build/build/project.jam:120: in load-parent > /usr/share/boost-build/build/project.jam:447: in initialize > /usr/share/boost-build/build/project.jam:301: in load-jamfile > /usr/share/boost-build/build/project.jam:68: in load > /usr/share/boost-build/build/project.jam:120: in load-parent > /usr/share/boost-build/build/project.jam:447: in initialize > /usr/share/boost-build/build/project.jam:301: in load-jamfile > /usr/share/boost-build/build/project.jam:68: in load > /usr/share/boost-build/build/project.jam:170: in project.find > /usr/share/boost-build/build-system.jam:148: in load > /usr/share/boost-build/kernel/modules.jam:261: in import > /usr/share/boost-build/kernel/bootstrap.jam:132: in boost-build > /usr/local/src/boost/boost-build.jam:9: in module scope > cp: cannot stat `html/*': No such file or directory > ### > ### Using 'gcc' toolset. > ### > rm -rf bootstrap > mkdir bootstrap > gcc -o bootstrap/jam0 command.c compile.c debug.c execunix.c expand.c > fileunix.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c > lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c > regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c > strings.c filesys.c builtins.c pwd.c class.c native.c w32_getreg.c > modules/set.c modules/path.c modules/regex.c modules/property-set.cmodules/sequence.c modules/order.c > execnt.c filent.c > compile.c: In function 'compile_set': > compile.c:1151: warning: passing argument 2 of 'assign_var_mode' from > incompatible pointer type > compile.c: In function 'compile_settings': > compile.c:1244: warning: passing argument 2 of 'assign_var_mode' from > incompatible pointer type > ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= clean > ...found 1 target... > ...updating 1 target... > ...updated 1 target... > ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= > ...found 46 targets... > ...updating 2 targets... > [MKDIR] bin.linuxx86 > [COMPILE] bin.linuxx86/bjam > compile.c: In function 'compile_set': > compile.c:1151: warning: passing argument 2 of 'assign_var_mode' from > incompatible pointer type > compile.c: In function 'compile_settings': > compile.c:1244: warning: passing argument 2 of 'assign_var_mode' from > incompatible pointer type > hash.c: In function 'hash_search': > hash.c:126: warning: pointer targets in passing argument 1 of 'strlen' > differ in signedness > hash.c:126: warning: pointer targets in passing argument 2 of > '__builtin_strcmp' differ in signedness > hash.c:126: warning: pointer targets in passing argument 2 of > '__builtin_strcmp' differ in signedness > hash.c:126: warning: pointer targets in passing argument 1 of 'strlen' > differ in signedness > hash.c:126: warning: pointer targets in passing argument 2 of > '__builtin_strcmp' differ in signedness > hash.c:126: warning: pointer targets in passing argument 2 of > '__builtin_strcmp' differ in signedness > ...updated 2 targets... > Note that the first 10 or so lines of the output above keep coming up when I'm trying to build other boost libraries. What am I doing wrong? --- Darren Garvey

2 2

BoostCon 2007 Program Committee progress report
by Beman Dawes 28 Jan '07

28 Jan '07

We've got interesting proposals from experienced presenters, have accepted a bunch, and have started to put together a tentative schedule for the week. We should finish accepting proposals in the next week or so and be able to go public with the schedule real soon after that. The people we have sessions proposals from are listed below. If you sent in a proposal and are not on the list, please contact me right away! Dave Abrahams Beman Dawes Jeff Garland Doug Gregor Mat Marcus Scott Meyers Eric Niebler Kevlin Henney Howard Hinnant Harmut Kaiser / Joel de Guzman Sean Parent Gennadiy Rozental Timothy Shead Jeremy Siek Matthias Troyer The conference dates (May 14-16) are firm, and other arrangements are moving forward. See http://www.boost.org/more/BoostCon07.html Thanks to Dave Abrahams and Boost-Consulting for providing the wiki we are using to coordinate conference planning. It is invaluable. --Beman Dawes, BoostCon 2007 Program Committee chair

4 3