June 2006 - Boost - lists.preview.boost.org

TR2 and C++0x heads up
by Beman Dawes 23 Sep '06

23 Sep '06

The C++ standards committee's Library Working Group has proposed a schedule for library changes and extensions: * October 2005: cutoff date for C++0x major library proposals * October 2006: cutoff date for library TR2 proposals * April 2007: cutoff date for C++0x library clean-up papers The usual rule-of-thumb is that new library components go in TR2, while changes to existing components go in C++0x. The LWG will consider exceptions to the rule on a case-by-case basis. The LWG is planning to issue a "Call for Proposals" with details, but in the meantime Boost developers might want to start thinking about which Boost libraries they want to propose to the LWG. Because most proposals go through one or more revisions before being accepted, it helps a proposal's chances if it reaches the committee as many meetings as possible before the final cut-off. So far there are plans to propose Boost.Threads, Boost.Filesystem, and Boost.Signals. As well as proposals for some of the more major libraries, I personally hope someone will do a sweep through Boost looking at some of the smaller utilities and helpers for a possible "Small Additions" proposal. --Beman

36 149

[shared_Ptr] [1.34] URGENT: Outstanding HP-UX / itanium bug
by John Maddock 12 Sep '06

12 Sep '06

Folks we still haven't solved the outstanding issue summarised here: http://lists.boost.org/boost-users/2005/12/15692.php Defining BOOST_SP_USE_PTHREADS is at least a workaround. Should I apply this to Boost.Config or should the sp_counted_base.hpp logic be altered (to keep everything in one place)? Or does anyone believe they have a fix for the assembly code in time for 1.34? Thanks, John.

7 21

boost::scoped_array::release?
by Ralf W. Grosse-Kunstleve 30 Aug '06

30 Aug '06

Does this patch for boost/scoped_array.hpp look useful? < T * release() // never throws < { < T * result = ptr; < ptr = 0; < return result; < } < It allows me to use boost::scoped_array almost like an auto_ptr: int* foo(size) { boost::scoped_array<int> result(new int[size]); // do something to result // if an exception is thrown result will be cleaned up return result.release(); } void bar() { boost::scoped_array<int> foo_result(foo(1000)); // code is still exception safe } I wouldn't need this if - we had std::auto_array (don't think it exists) - std::vector<int>(size) wouldn't do the default construction of all elements and I didn't care about having two pointers instead of just one (sometimes I actually do care) - boost::scoped_array::ptr was protected instead of private so that I could inherit and add release() Are there arguments for not adding release()? Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

11 21

Boost regression notification (2005-10-26 [RC_1_33_0])
by Douglas Gregor 23 Aug '06

23 Aug '06

Boost regression test failures ------------------------------ Report time: 2005-10-26T14:54:08Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 82 failures in 3 libraries: parameter (1) range (3) serialization (78) |parameter| tutorial: gcc-2.95.3-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_binary_archive_dll: borland-5_6_4 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_archive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_archive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_warchive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos vc-7_0 test_class_info_load_text_warchive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-7_0 test_class_info_load_xml_archive: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_xml_archive_dll: borland-5_6_4 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_xml_warchive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos vc-6_5 vc-7_0 test_class_info_load_xml_warchive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-6_5 vc-7_0 test_demo_xml_load: borland-5_6_4 gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-8_1 mingw-3_4_2 test_demo_xml_load_dll: borland-5_6_4 gcc-3_4_3-sunos gcc-4_0-darwin mingw-3_4_2 test_shared_ptr_132_text_warchive: intel-win32-8_1

7 11

bind/lambda/phoenix and result_of
by David Abrahams 02 Aug '06

02 Aug '06

One happy day, we'll have auto and decltype... Until then, we have no reasonable way to declare the type of bind expressions. So I got to thinking, maybe something like this could be made to work: result_of<bind_(std::minus<int>, int, _1_)>::type f = bind(std::minus<int>(), 3, _1); For lambda, I guess we could do something like this: result_of<minus_(int, _1_)>::type f = 3 - _1; Does this direction make sense? -- Dave Abrahams Boost Consulting www.boost-consulting.com

6 25

Low-level precision timer proposal
by Silex 25 Jul '06

25 Jul '06

Hello, Currently there's boost::timer which is a timer based on std::clock(). While this might be sufficient for many people, some want low-level resolution timers. I made a QueryPerformanceCounter() / gettimeofday() wrapper that allows portable millisecond resolution. You'll find attached a basic sample of my trivial work. I tried to make it so inclusion in boost is straight-forward. To see it in action : -Copy the precise_timer* hpp files into the boost directory. -Compile main.cpp & execute it. Would boost be interested by including this class in boost::timer ? I'm all ear for your suggestions / bugs / whatever fits it :) This is the 1st time I propose something to boost so there's probably things to be said on the implementation details (files structure, #ifdef strategy etc) so don't hesitate to tell what should be changed. I also can make that if on windows QueryPerformanceCounter() fails because there's no low-level resolution timer available it uses timeGetTime() instead. But that'd require linking to winmm.lib which could be a problem ( and I never saw a win32 machine where QueryPerformanceCounter() didn't work ). I just thought that I could also rename it to lowres_timer instead of precise_timer, it's more accurate, what do you think ? Regards, Philippe Vaucher

17 84

Naming integer, real and either template types
by Paul A Bristow 23 Jul '06

23 Jul '06

I am writing template math functions. Some can take integral types (only) Some can take real (both built-in floating-point - float, double.. AND User Defined real types) And some can take either integral OR real. Real : Floating-point types Integer : Integral types Arithmetic : Either Integral OR Floating-point types Arithmetic is a bit long - other ideas? So to write a function something like template <class RealType> RealType students_t(ArithmeticType degrees_of_freedom, RealType t) { ... } Using just T is not an option because there are three (at least) possibles. What names should I use for the types? RealType, real_type, RealT, or RT, or ??? IntType, int_type, IntT, IT, or ??? ArithmeticType, arithmetic_type, ArithType, arith_type, AT ??? Suggestions for names please. Rationales? Prior art? Precedents? Standards? Thanks Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com

3 3

Release procedures
by Fernando Cacciola 19 Jul '06

19 Jul '06

Hi, I must be doing something wrong or I'm expecting something I shouldn't: (1) I updated from the trunk (HEAD) (2) Fixed a couple of things (3) Commited to the trunk (4) Updated from RC_1_34 (over the same working folder) (5) Merged "merged_from_RC_1_34" and "HEAD" into working folder. For step 5 I'm using ToroiseCVS 1.8.26 using the merge dialog as follow: Start: merged_from_RC_1_34 End: HEAD After that I get lots of updated, and even conflicted, files, way beside those which are mine. Is that expected? I figured I would get only my files merged. If it is, is it OK to just commit my files and not the others? What about the tag? TIA Fernando Cacciola

8 14

[system] system_error first draft
by Beman Dawes 19 Jul '06

19 Jul '06

The filesystem proposal accepted by the LWG for TR2 also includes a <system_error> header with a bit of error reporting machinery. In particular, class error_code to encapsulate error codes from the operating system and class system_error to be thrown by exceptions. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1975.html#Diagnost… The plan is to use these classes uniformly in TR2. Presumably we will want Boost implementations, and use them in other Boost libraries besides Boost.Filesystem. Because there are likely to be other small operating system dependent components in the future, I'm suggesting that they go in a separate Boost.System library. I'm about to post a CPU timer component that would also fit nicely into Boost.System IMO. There is an early version of Boost.System stuff in the vault. Go to the System directory at http://boost-consulting.com/vault/ for system-0.1.zip. The preliminary error_code/system_error docs can be viewed online at http://mysite.verizon.net/beman/system_error.html Note some changes from the TR2 version: * Use of the unspecified-bool-type idom to test an error_code object to see if there is a non-zero error code. * Name changes. The problem with naming is that there are functions whose most obvious name is "errno", given the long C, C++, and POSIX tradition. But 17.4.1.2 of the C++ standard specifically says that errno shall be a macro! Boo. Hiss. So that name is out. I'm very curious to hear if people think the newer names are an improvement over the TR2 versions. And any other comments are welcome! --Beman

7 17

[variant] wish list
by Yuval Ronen 18 Jul '06

18 Jul '06

Hi Eric! It's good to see that you've got back to the list. For a long time now, there was no one to answer users' questions and comments, So I'm taking this (rare :-) ) opportunity to present my wish list for Boost.Variant. First of all, I'd like to say that I think it's a great library. I've become addicted to it... However, there are some things I think are missing. 1. add operator != There's operator==, and adding operator!= would be both easy and useful. 2. apply_visitor should accept the visitor by value std algorithms (such as for_each) accept their functors by value, not by [const] reference. I think that visitors should be considered as variant's equivalent to std functors, and thus be passed by value. This will allow me to pass temporary visitor objects, which is a very common use case, just as with std functors. It will also allow you to delete the two versions of apply_visitor (one taking a reference, one taking a const reference), and leave only one. 3. add support for non-copyable types, a-la Boost.Optional's in-place factory I found myself needing a variant of non-copyable types, and had to resort to dynamic allocation to solve it. Luckily for me, it wasn't a performance-critical code, so I could live with it. But of course it's not optimal... 4. add more flavours of get() Currently the get<T>() function has the semantics of "return current value only if it is of type implicitly convertible to T". But there are other usages, even more useful than this (and if there are other get()s, the name of the original get() should be changed to, for example, get_implicit). One of them is "return current value only if it is exactly of type T (using type_info)". The function will not compile if T is not any of the variant's types. A possible name for it could be get_exact(), but of course there might be better names. Another usage I found useful is when all of the variant's types are implicitly convertible to a common T (e.g, they all inherit from T). This function will not compile if any of the variant's types can't be implicitly convertible to T, but if it does compile, then it ensures it can't fail in run-time (in contrast to get_implicit and get_exact, which can fail in run-time). A possible name is get_common(). I've attached a file containing my implementation of get_exact and get_common, in case you're interested. All the preprocessor magic there is beyond my understanding, I just copied it from your code, and hope I didn't make any mistakes... 5. support for reference types I don't know if Boost.Variant currently supports reference types, nor am I certain it should, but it's a possibility... There was a debate about Boost.Optional's support for reference types, which reached no clear conclusion. Maybe you're familiar with the details, but if not, in short, the problem is with code such as int a = ...; int b = ...; optional<int &> x; // x in initialized to 'empty' x = a; // x is binded to a's reference x = b; // is x rebinded to b's reference, or is a assigned the value in b? The reason I bring it up here, is because I think it's relevant to Boost.Variant as well. Variant of reference types will raise the exact same questions, which should probably get the exact same answers. IOW, both the question of whether to support reference types, and the question of how to support them, should apply to both Boost.Optional and Boost.Variant uniformly. It's an open issue. 6. propose it for TR2 For the benefit of all of us... Thanks again for a great library, Yuval #ifndef VariantGet_h #define VariantGet_h #include <Utils/Variant.h> #include <boost/mpl/assert.hpp> #include <boost/mpl/contains.hpp> namespace boost { template <typename T> struct get_common_visitor : public static_visitor<T> { T operator()(T t) { return t; } }; template <typename T, typename Variant> typename add_reference<T>::type get_common(Variant &v) { get_common_visitor<typename add_reference<T>::type> visitor; return v.apply_visitor(visitor); } template <typename T, typename Variant> typename add_reference<const T>::type get_common(const Variant &v) { get_common_visitor<typename add_reference<const T>::type> visitor; return v.apply_visitor(visitor); } template <typename T, typename Variant> void assert_variant_has_type(const Variant &) { BOOST_MPL_ASSERT((mpl::contains<typename Variant::types, T>)); } template <typename T> struct get_exact_visitor : public static_visitor<T> { T operator()(T t) { return t; } }; template <typename U, BOOST_VARIANT_ENUM_PARAMS(typename T) > inline typename add_pointer::type get_exact( boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) >* operand BOOST_VARIANT_AUX_GET_EXPLICIT_TEMPLATE_TYPE(U)) { assert_variant_has_type(*operand); typedef typename add_pointer::type U_ptr; if (!operand) return static_cast<U_ptr>(0); if (operand->type() != typeid(U)) return static_cast<U_ptr>(0); detail::variant::get_visitor v; return operand->apply_visitor(v); } template <typename U, BOOST_VARIANT_ENUM_PARAMS(typename T) > inline typename add_pointer<const U>::type get_exact( const boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) >* operand BOOST_VARIANT_AUX_GET_EXPLICIT_TEMPLATE_TYPE(U)) { assert_variant_has_type(*operand); typedef typename add_pointer<const U>::type U_ptr; if (!operand) return static_cast<U_ptr>(0); if (operand->type() != typeid(U)) return static_cast<U_ptr>(0); detail::variant::get_visitor<const U> v; return operand->apply_visitor(v); } template <typename U, BOOST_VARIANT_ENUM_PARAMS(typename T) > inline typename add_reference::type get_exact( boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) >& operand BOOST_VARIANT_AUX_GET_EXPLICIT_TEMPLATE_TYPE(U)) { typedef typename add_pointer::type U_ptr; U_ptr result = get_exact(&operand); if (!result) throw bad_get(); return *result; } template <typename U, BOOST_VARIANT_ENUM_PARAMS(typename T) > inline typename add_reference<const U>::type get_exact( const boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) >& operand BOOST_VARIANT_AUX_GET_EXPLICIT_TEMPLATE_TYPE(U)) { typedef typename add_pointer<const U>::type U_ptr; U_ptr result = get_exact<const U>(&operand); if (!result) throw bad_get(); return *result; } } // namespace #endif /* ! defined VariantGet_h */

6 13