May 2007 - Boost - lists.boost.org

[Report] 0 regressions on RC_1_34_0 (2007-05-02)
by Douglas Gregor 02 May '07

02 May '07

Boost Regression test failures Report time: 2007-05-02T02:41:18Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… No failures! Yay!

1 0

[date_time] Problem compiling is_leap_year
by Richard Hadsell 02 May '07

02 May '07

Using g++ 3.4.4 (on 64-bit Linux) my source won't compile gregorian_calendar_base<>::is_leap_year. The problem stems from the '%' operator with mixed types. My code includes (unfortunately) a class that has arithmetic operators with most of the integer and floating-point types on the left, constructors from those types, and conversion operators to those types. The compiler finds the ambiguity and can't decide between the built-in operator%(int, int) and all the other possibilities with my nasty class's '%' operators. I fixed the problem in gregorian_calendar.ipp by casting 'year' to 'int' in 'is_leap_year'. This is the diff: diff -u -r1.1.1.1 gregorian_calendar.ipp --- boost/date_time/gregorian_calendar.ipp 27 Apr 2007 17:10:19 -0000 1.1.1.1 +++ boost/date_time/gregorian_calendar.ipp 2 May 2007 13:59:31 -0000 @@ -164,7 +164,7 @@ gregorian_calendar_base<ymd_type_,date_int_type_>::is_leap_year(year_type year) { //divisible by 4, not if divisible by 100, but true if divisible by 400 - return (!(year % 4)) && ((year % 100) || (!(year % 400))); + return (!(static_cast<int>(year) % 4)) && ((static_cast<int>(year) % 100) || (!(static_cast<int>(year) % 400))); } //! Calculate the last day of the month We have had this problem since starting to use the date_time library in 1.32.0. The user was not interested in reporting it, and I hoped someone else would report it. However, that has not happened, so here it is. It would be nice to see it get into the next release. BTW, we had some other similar problems, which we fixed by changing a few casts, but they have not reproduced themselves in 1.34.0 beta. Perhaps they were only problems for some other compiler, which we are no longer using. -- 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

1 0

[1.34.0][StringAlgo] was: Re: Boost 1.34.0 Beta released
by Thomas Witt 02 May '07

02 May '07

In article <f0rmmp$mu4$1(a)sea.gmane.org> Joe Gottman <jgottman(a)carolina.rr.com> wrote: > Thomas Witt wrote: >> The first beta of what will become version 1.34.0 is now >> available from http://www.boost.org. >> >> * String Algorithm Library: >> o lexicographical_compare >> o join >> o New comparison predicates is_less, is_not_greater. >> o Negative indexes support (like Perl) in various >> algorihtms (*_head/tail, *_nth). > We seem to be missing some documentation for the string algorithm > library. For instance, the library front page, > file:///C:/boost_1_34_0_beta/boost_1_34_0/doc/html/string_algo.html > does not mention the new join() algorithm and the release notes, > file:///C:/boost_1_34_0_beta/boost_1_34_0/doc/html/string_algo/release_ > notes.html don't mention what's new for version 1.34. We need a fix for this. Volunteers? Anybody? Thomas

3 5

configure (Was: Building Boost 1.34.0 libraries with bjam)
by Vladimir Prus 02 May '07

02 May '07

Richard Hadsell wrote: [moving from boost-users] > I have made several attempts to persuade bjam to use > /opt/gcc344/bin/g++344, and I finally discovered a solution for this > part of the problem. I followed the Boost.Config doc the describes > setting environment variables and running the configure script: > > setenv CXX /opt/gcc344/bin/g++344 > setenv CXXFLAGS "-m64 -fPIC" > setenv LDFLAGS "-m64 -fPIC" > configure > > Then I looked at the resulting Makefile and user-config.jam. > > First, the environment variables seemed to have no effect on the > user-config.jam. When I ran bjam afterward, it still used the default > installed g++ on my system. So in user-config.jam I changed 'using gcc > ;' to 'using gcc : 3.4.4 : /opt/gcc344/bin/g++344 ;'. (This was similar > to a 'using' statement that I saw in a comment in > tools/build/v2/user-config.jam.) I'm starting to wonder if "configure" script being shipped with Boost is a good idea. The idea is to make standard "./configure && make" work, however, as above posting shows, "configure" is associated with various expected behaviour, and unless we want to duplicate all such behaviour, we can end up confusing users. - Volodya

5 5

Trying to build release, debug, profile variants into same stage directory
by Richard Hadsell 02 May '07

02 May '07

Having discovered the profile variant (maybe it's new with 1.34.0), I tried to build all 3 variants that I want and stage them to a common directory. Unfortunately, the profile variant doesn't add its own suffix to the output library, the way the debug version does. The profiling library has the same name as the optimized (release) version. I figured that I could workaround the problem by putting the profile variant into its own stage directory, but that is not what I really want. This is what happened with the current 1.34.0 beta build: 810% bjam --user-config=user-config.LINUX_AMDFC3 threading=multi instruction-set=opteron address-model=64 cxxflags=-fPIC variant=release,debug,profile --stagedir=stageFC3 stage Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). <...>/boost_1_34_0_beta/tools/build/v2/build/virtual-target.jam:996: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstageFC3/lib>libboost_date_time-gcc34-mt-1_34.so.1.34.0 error: previous virtual target { common%common.copy-libboost_date_time-gcc34-mt-1_34.so.1.34.0.SHARED_LIB { gcc%gcc.link.dll-libboost_date_time-gcc34-mt-1_34.so.1.34.0.SHARED_LIB { gcc%gcc.compile.c++-greg_month.o.OBJ { gregorian/greg_month.cpp.CPP } } { gcc%gcc.compile.c++-greg_weekday.o.OBJ { gregorian/greg_weekday.cpp.CPP } } { gcc%gcc.compile.c++-date_generators.o.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./stage-proper error: another virtual target { common%common.copy-libboost_date_time-gcc34-mt-1_34.so.1.34.0.SHARED_LIB { gcc%gcc.link.dll-libboost_date_time-gcc34-mt-1_34.so.1.34.0.SHARED_LIB { gcc%gcc.compile.c++-greg_month.o.OBJ { gregorian/greg_month.cpp.CPP } } { gcc%gcc.compile.c++-greg_weekday.o.OBJ { gregorian/greg_weekday.cpp.CPP } } { gcc%gcc.compile.c++-date_generators.o.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./stage-proper error: added properties: <debug-symbols>on <profiling>on <variant>profile error: removed properties: <debug-symbols>off <profiling>off <variant>release <...>/boost_1_34_0_beta/tools/build/v2/build/virtual-target.jam:459: in actualize-no-scanner from module object(file-target)@4418 <...>/boost_1_34_0_beta/tools/build/v2/build/virtual-target.jam:111: in object(file-target)(a)4418.actualize from module object(file-target)@4418 <...>/boost_1_34_0_beta/tools/build/v2/build-system.jam:476: in load from module build-system <...>/boost_1_34_0_beta/tools/build/v2/kernel/modules.jam:261: in import from module modules <...>/boost_1_34_0_beta/tools/build/v2/kernel/bootstrap.jam:132: in boost-build from module <...>/boost_1_34_0_beta/boost-build.jam:9: in module scope from module The messages provided enough info to show that the conflict was between release and profile variants. I came up with a fix that you developers might like to consider. I added a line to common.jam to give the profile variant a "runtime-tag". Of course, 'p' is the appropriate tag, but stlport has already used 'p' for itself. I don't know why anyone would want to build both with and without stlport, but I certainly don't, so the conflict doesn't bother me. But you might change it to something like 'sp'. The resulting diff: diff -u -r1.1.1.1 common.jam --- tools/build/v2/tools/common.jam 27 Apr 2007 17:12:56 -0000 1.1.1.1 +++ tools/build/v2/tools/common.jam 1 May 2007 17:04:37 -0000 @@ -792,7 +792,8 @@ if <python-debugging>on in $(properties) { tag += y ; } if <variant>debug in $(properties) { tag += d ; } - if <stdlib>stlport in $(properties) { tag += p ; } + if <variant>profile in $(properties) { tag += p ; } + if <stdlib>stlport in $(properties) { tag += sp ; } if <stdlib-stlport:iostream>hostios in $(properties) { tag += n ; } return $(tag:J=) ; -- 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

3 2

[Review] The review of the Boost.Guid library starts today (April 30th)
by Hartmut Kaiser 02 May '07

02 May '07

Hi all, The review of the proposed Boost Guid library written by Andy Tompkins starts today (April 30th, 2007) and ends May 10th, 2007. You can download the library here: http://www.boost-consulting.com/vault/ (file guid_v7.zip). --------------------------------------------------- About the library: Guid is a library providing an implementation of Globally Unique Identifiers. Guid's are used in many facets of programming, including databases, networks, remote procedures, serializations, transactions, identifying documents, and identifying classes. This library is efficient and is able to create name-based and random-based guids. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - 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? Regards Hartmut Review Manager

6 6

[RC_1_34_0] Bind warnings
by Jared McIntyre 02 May '07

02 May '07

I just started testing the boost 1.34 (RC_1_34_0) cvs branch in our main code line. We're getting a lot of warnings with bind. I'm using Visual Studio 8 SP1. This is a test case that reproduces the warning: #include <boost/bind.hpp> #include <string> class WarningTest { public: WarningTest(void) { boost::bind(&WarningTest::Function, this); } std::string Function() { } }; The warning I get is: WarningTest.cpp c:\msc\ThirdParty\boost_cvs\boost\boost/bind.hpp(1575) : warning C4180: qualifier applied to function type has no meaning; ignored c:\msc\ThirdParty\boost_cvs\boost\boost/bind.hpp(1609) : see reference to class template instantiation 'boost::_bi::add_cref<Pm,I>' being compiled with [ Pm=std::basic_string<char,std::char_traits<char>,std::allocator<char>> (__thiscall WarningTest::* )(void), I=1 ] c:\msc\renal\deliverables source\properties\WarningTest.h(11) : see reference to class template instantiation 'boost::_bi::dm_result<Pm,A1>' being compiled with [ Pm=std::string (__thiscall WarningTest::* )(void), A1=WarningTest * ] I'm not getting these warnings with 1.33. Jared

2 6

[1_34_0][typeof]can I fix the doc?
by Arkadiy Vertleyb 02 May '07

02 May '07

Thomas, I just checked in the following into the main branch (it fixes one broken link and one spelling error): Index: typeof.qbk =================================================================== RCS file: /cvsroot/boost/boost/libs/typeof/doc/typeof.qbk,v retrieving revision 1.5.2.5 diff -r1.5.2.5 typeof.qbk 12c12 < [last-revision $Date: 2007/02/06 01:50:40 $] --- > [last-revision $Date: 2007/05/02 02:38:56 $] 83,84c83,84 < [@http://www.osl.iu.edu/~jajarvi/publications/papers/decltype_n1478.pdf < http://www.osl.iu.edu/~jajarvi/publications/papers/decltype_n1478.pdf] --- > [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf] 847c847 < [section:ackn Acknoledgements] --- > [section:ackn Acknowledgements] Can I merge it into 1_34_0? Thanks, Arkadiy

1 0

inter-thread signals
by Vadim Lebedev 01 May '07

01 May '07

Hello, I'm working on a project using QT and boost and we have a requirements that certains signals should be handled inside main QT thread but raised in another thread. So i'm trying approach in the attached file. Basically i've created a SlotFuction which derives from boost::function and does inter-thread magic when needed. I'm not really (yet) boost guru so i would like to have some feedback. It is evident that this approach suffer of one problem: the event handler registration/invocation is not really thread safe, but i think this can be handled automatically by recent thread_safe_signals library. Thanks Vadim

3 4

[1_34_0] [python] gcc strict-aliasing warnings in release mode
by Kim Barrett 01 May '07

01 May '07

I'm trying out the boost 1.34.0 beta, and there are some warnings of interest. I'm using gcc 4.1 x86/32 (on SuSE 10.1), building boost with "variant=release". There are several occurrences of "dereferencing type-punned pointer will break strict aliasing rules" with locations listed below. libs/iostreams/src/zlib.cpp:108 libs/iostreams/src/zlib.cpp:109 libs/python/src/list.cpp:16 libs/python/src/long.cpp:12 libs/python/src/long.cpp:19 libs/python/src/long.cpp:26 libs/python/src/dict.cpp:32 libs/python/src/tuple.cpp:12 libs/python/src/str.cpp:13 libs/python/src/class.cpp:571 libs/python/src/class.cpp:581 This build of boost is being compiled against Python 2.5. Note that Python 2.5 on this platform builds with gcc's -fno-strict-aliasing option. My personal experiences with strict-aliasing problems with gcc, as well as anectdotal information, leads me to strongly suggest that Boost.Python should also be built with that compiler flag (at least when building in release mode), and that possibly any client wrapper code should do so as well. This is because the Python headers that Boost.Python (and client code) depend on may not be strict-aliasing correct. The result of not being strict-aliasing correct when gcc's strict-aliasing option is enabled (which it is by default for gcc versions starting with 4.0?) is that the compiler may generate code which is (often quite subtly) broken. (A couple of weeks ago I ran afoul of this problem with a different library, where gcc's warnings were a false negative (i.e. no warning) and just silently generated non-working code if strict-aliasing was enabled. I'm presently looking at diffs in the generated assembly code (not fun) because I haven't been able to find the problem by looking at the source.)

2 3