January 2007 - Boost - lists.preview.boost.org

Re: [boost] Regressions in your Boost libraries as of 2007-01-12 [RC_1_34_0]
by Jeremy Siek 12 Jan '07

12 Jan '07

Hi Doug, Are there any OSL machines with the below compilers installed that I could use to resolve these issues? Best regards, Jeremy On Jan 12, 2007, at 10:00 AM, Douglas Gregor wrote: > You are receiving this report because one or more of the libraries you > maintain has regression test failures that are not accounted for. > A full version of the report is sent to the Boost developer's mailing > list. > > Detailed report: > http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/ > developer/issues.html > > There are failures in these libraries you maintain: > concept_check (15) > > |concept_check| > class_concept_fail_expected: borland-5.6.4 borland-5.8.2 > borland-5.8.2 msvc-6.5 msvc-6.5 msvc-7.0 > stl_concept_covering: borland-5.8.2 borland-5.8.2 gcc-3.3.6 > gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux > gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc ______________________________________ Jeremy Siek <jeremy.siek(a)colorado.edu> http://www.cs.colorado.edu/~siek/ Visiting Assistant Professor Department of Computer Science University of Colorado at Boulder

1 0

[Report] 20 regressions on RC_1_34_0
by Douglas Gregor 12 Jan '07

12 Jan '07

Boost Regression test failures Report time: 2007-01-12T11:01:01Z 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… 20 failures in 5 libraries concept_check (15) date_time (1) regex (1) test (2) utility (1) |concept_check| class_concept_fail_expected: borland-5.6.4 borland-5.8.2 borland-5.8.2 msvc-6.5 msvc-6.5 msvc-7.0 stl_concept_covering: borland-5.8.2 borland-5.8.2 gcc-3.3.6 gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc |date_time| testgenerators: qcc-3.3.5_gpp |regex| regex_regress_threaded: msvc-6.5 |test| prg_exec_fail2: darwin-4.0.1 prg_exec_fail3: cw-9.4 |utility| operators_test: gcc-3.4.5_linux_x86_64

1 0

Boost.Build does not recognize .v2 less Jamfile s
by Roland Schwarz 12 Jan '07

12 Jan '07

I might have missed something in the Discussion, but isn't the v2 expected to work on Jamfile _and_ Jamfile.v2 ? If I actually rename the file Jamfile.v2 to Jamfile the build from boost root does not work anymore. Maybe a hint: the library does not show up in bjam --show-libraries. Thank you for attention, Roland

2 4

[DateTime] New US DST Rules & Timezones In General
by Caleb Epstein 12 Jan '07

12 Jan '07

I'm in the process of testing/fixing applications in light of the new DST rules that begin this year in the US (see http://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005#Change_to_daylight_s…) In the process of doing this, I found a hard-coded posix_time_zone specification in one of my libraries that I've had to correct for these new rules. As a result of this exercise, I'm once again struck by what seems to me like an overly rigid treatment of timezones in Boost.DateTime. The deficiencies I see in the out-of-the-box implementation are as follows: * No built-in support for multiple DST rules within a single zone. Ideally one should be able to calculate the localtime equivalent of any datetime in history with the appropriate rules that were in effect *at that time*. I've updated my version of the Eastern Standard/Daylight Time for the new 2007 rules, but if I use this new set of rules for historic datetimes, I will get incorrect results when converting to/from UTC. * Does not make use of system time facilities for localtime conversions. I'm not sure how Windows deals with timezone concepts, but most C libraries on UNIX make use of "tzfile(5)" data files (See http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=tzfile) to drive the "gmtime" and "localtime" functions. Oversimplifying, these files store a series of time_t values with associated UTC offsets. If you inspect one, you'll see all of the past and projected future daylight savings switch-overs recorded. When DST rules change, it is a relatively simple matter to update these data files, and no application code needs to change. * Current DST traits classes (us_dst_trait) and examples are incorrect for new 2007 DST rules. But fixing these for 2007 makes them wrong for historic dates. Catch-22-y. I realize it is possible to implement a custom time_zone that uses the system library facilities, but I'd really like to see something like this available out-of-the-box. Unfortunately, I don't think the time_zone_base interface meshes very well with the C library localtime/gmtime facilities. For example implementing "dst_local_start_time(year)" and "dst_local_end_time(year)" might require some care given the C library interfaces. Without implementing a custom time_zone, users are left with one and only one rule they can use, and this means that fixing their timezone specifications for 2007 breaks them for historic dates. I'm not sure if this is concerning for others, but I find it extremely troublesome. -- Caleb Epstein

3 3

[range] as_array broken
by Eric Niebler 12 Jan '07

12 Jan '07

Consider the output of the following program: #include <iostream> #include <algorithm> #include <boost/range.hpp> #include <boost/range/as_array.hpp> #include <boost/range/as_literal.hpp> void print_char(char ch) { std::cout << ch << '\t' << (int)ch << '\n'; } template<typename Range> void print_range(Range const &rng) { std::for_each(boost::begin(rng), boost::end(rng), print_char); } int main() { print_range(boost::as_literal("hello")); std::cout << '\n'; print_range(boost::as_array("hello")); std::cout << '\n'; return 0; } It prints the following: h 104 e 101 l 108 l 108 o 111 h 104 e 101 l 108 l 108 o 111 There is no difference between treating a string literal as an array or as a null-terminated string. There should be. When treated as an array, the null-terminator should be treated as any other element in the array. The problem comes from range/detail/implementation_help.hpp: template< class T, std::size_t sz > inline T* array_end( T BOOST_RANGE_ARRAY_REF()[sz], char_or_wchar_t_array_tag ) { return boost_range_array + sz - 1; } It seems Boost.Range is still treating arrays of char and wchar_t specially. IIRC, we decided long ago that it shouldn't. This is on HEAD, BTW. -- Eric Niebler Boost Consulting www.boost-consulting.com

3 7

[python] patch for python.jam for HP-UX (setting proper file suffix)
by Boris Gubenko 12 Jan '07

12 Jan '07

On HP-UX, different versions of Python interpreter expect shared libraries to have different suffix: for example, Python 2.4.3 expects .sl suffix while Python 2.5 expects .so suffix. Attached patch makes sure that on HP-UX, boost python library tests create python extension files with the suffix appropriate for the version of Python interpreter used by the test system. I tested it on HP-UX with Python 2.4.3 and with Python 2.5. I also tested it on Tru64 to make sure that it does not affect other platforms. Please, apply it to CVS HEAD and the RC branch. Thanks, Boris

2 3

[typeof] please make "*_native" tests expected failures on HP-UX
by Boris Gubenko 12 Jan '07

12 Jan '07

Like many other compilers, aCC6 on HP-UX does not support typeof extension (to be precise, it supports it in GNU C++ dialect compatibility mode -- -Ag++ -- but not in the default mode). In explicit-failures-markup.xml, there is a group of toolsets making "*_native" typeof library tests expected failures, with the remark: "Native mode is not supported for this compiler.". Please, add "acc" toolset to this group, in both HEAD and the RC branch. I don't think that a patch is needed for such a simple change, but if you need/want a patch, I can provide one. Thanks, Boris

1 0

[bind/lambda] a functor holding a shared_ptr
by Yuval Ronen 11 Jan '07

11 Jan '07

In the following code: struct A { void func(); } int main() { shared_ptr<A> a(new A); boost::bind(&A::func, a); } the bind() call returns a function object which holds the shared_ptr by value (it's one of the shared owners). This is an important feature I'm using, because sometimes the functor is the last owner left standing, and I want to keep A alive until the functor's destructor (actually, I don't really like this design, but I'm talking about legacy code here). Replacing boost::bind with lambda::bind doesn't compile. Is this feature not supported by lambda::bind? If not supported now, is it planned to be supported in the future? Can I in the mean time implement this feature in my code with relative ease? Thanks, Yuval

2 1

[Boost-bugs] [ boost-Patches-1633503 ] support for weak_ptr binding
by SourceForge.net 11 Jan '07

11 Jan '07

Patches item #1633503, was opened at 2007-01-11 11:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1633503&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: support for weak_ptr binding Initial Comment: Hello, recently i faced with problem - i was not able to pass weak_ptr to bind() function. I started to study why and found there is no support for this in boost. As result, me and my friend wrote "get_pointer" version which accepts weak_ptr. At actual call moment, implementation uses weak_ptr::lock() to get shared_ptr. If retrieved shared_ptr is invalid, then exception of type "disposed_exception" thrown. This code was tested on Windows XP SP2 with following compilers: VC6, VC7, VC7.1, VC8, g++ 3.2.3 (MinGW), g++ 3.4.4 (Cygwin). If you find this code is useful for someone else me, please add to boost (it's actually not a library, this is why i'm poosting it to "patches"). You can find sources + test app in attachment. Thank you, Dmytro Gokun ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1633503&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[sp_counted_base] Why does sp_counted_base.hpp not use atomic_count for gcc environments?
by Jerry Lawson 11 Jan '07

11 Jan '07

On sparc/gcc environment, boost/detail/sp_counted_base.hpp will use sp_counted_base_pt.hpp, which of course implements counter protection via pthread_mutex operations. Other gcc-environments (x86, x64, ia64, ppc) have the concept of using asm directives for atomic increment & decrement, which obviously is more efficient than the mutex operations. The boost/detail/atomic_count_gcc.hpp implementation seems like a more efficient mechanism for incrementing/decrementing the shared_ptr reference counters. In fact, the shared_ptr_nmt.hpp implementation does use boost::detail::atomic_count for the reference count (albeit directly, rather than through the shared_count template). I am using atomic_count as the basis for my internal reference counting for my intrusive_ptr-based objects and am happy with this. So I'm curious as to why sp_counted_base.hpp does not use the atomic increment/decrement model for sparc/gcc that it does for other gcc environments?

2 3